Tool Registration Conflict Detection Prompt

This prompt is for platform engineers and agent infrastructure developers who manage concurrent tool registration in multi-agent systems. Use it when an incoming tool registration request must be validated against an existing registry to detect conflicts before the tool becomes available to agents. The prompt identifies three conflict categories: schema incompatibilities where parameter types or required fields clash, version mismatches where a different version of the same logical tool already exists, and ownership collisions where two teams or vendors register tools with overlapping capabilities under different names.

Run this prompt as a synchronous validation gate in your tool registration pipeline, not as a background audit. It assumes you have structured representations of both the incoming tool manifest and the current registry state. The prompt expects a JSON-formatted [INCOMING_TOOL_MANIFEST] containing at minimum a tool name, version, parameter schema, and owner identifier, alongside a [REGISTRY_STATE] snapshot of all currently registered tools with the same required fields. The output is a structured conflict report with a pass/fail decision, specific conflict types, and remediation instructions. Wire this into your CI/CD pipeline or registration API so that no tool enters the registry without passing this gate.

Do not use this prompt for runtime tool selection or capability discovery; it is a registration-time conflict detector, not a planning or orchestration prompt. Avoid running it against incomplete manifests—missing required fields will produce false negatives. If your registry contains tools with sparse or inconsistent metadata, run the Tool Manifest Validation Prompt first to normalize inputs. For high-stakes production registries where a conflict could break active agent workflows, always pair this prompt with a human approval step before the registration is committed.

This prompt template is designed to be integrated into a tool registration gateway or an agent's pre-registration validation step. It compares a proposed tool definition against the current state of the registry to identify schema incompatibilities, version mismatches, and ownership collisions. The prompt is structured to produce a machine-readable JSON output that your application can use to automatically accept, reject, or flag a registration for human review.

textCopy
You are a tool registry conflict detector for a multi-agent platform. Your task is to compare an incoming tool registration request against the existing tool registry and identify any conflicts.

# EXISTING TOOL REGISTRY
[REGISTRY_STATE]

# INCOMING TOOL REGISTRATION
[INCOMING_TOOL_DEFINITION]

# CONFLICT DETECTION RULES
1. **Schema Incompatibility**: If a tool with the same `name` exists but has a different `input_schema` or `output_schema`, flag it as a schema conflict. Note the specific differing fields.
2. **Version Mismatch**: If the incoming tool has a `version` field that is older than or equal to the existing tool's version, flag it as a version conflict.
3. **Ownership Collision**: If a tool with the same `name` exists but has a different `owner` or `namespace` field, flag it as an ownership collision.
4. **Duplicate Registration**: If the incoming tool is identical in name, schema, version, and owner to an existing tool, flag it as a duplicate.
5. **No Conflict**: If the tool name is entirely new, or if the incoming tool is a newer version from the same owner with a backward-compatible schema change, classify it as no conflict.

# OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "conflict_detected": boolean,
  "conflict_type": "schema_incompatibility" | "version_mismatch" | "ownership_collision" | "duplicate" | "none",
  "conflict_details": {
    "existing_tool_name": string,
    "incoming_tool_name": string,
    "conflicting_fields": [string],
    "existing_version": string | null,
    "incoming_version": string | null,
    "existing_owner": string | null,
    "incoming_owner": string | null,
    "description": string
  },
  "recommended_action": "accept" | "reject" | "review",
  "action_reason": string
}

# CONSTRAINTS
- Do not invent tools or capabilities not present in the input.
- If the incoming tool definition is malformed or missing required fields (name, input_schema), flag it for review with a clear description of the missing data.
- For schema comparisons, treat a field as conflicting if its type, description, or required status differs.

To adapt this template, replace [REGISTRY_STATE] with a serialized JSON array of all currently registered tool objects. Replace [INCOMING_TOOL_DEFINITION] with the full JSON object of the tool being registered. In production, you should validate the model's output against the OUTPUT_SCHEMA before acting on the recommended_action. For high-stakes registrations where a conflict could break active agent workflows, always route review actions to a human operator and log the full conflict_details payload for audit purposes.

The conflict detection prompt is not a standalone utility; it is a gating step inside a tool registration pipeline. When a new tool manifest arrives—whether from an MCP server, an OpenAPI spec import, or a manual registration—the pipeline must pause, extract the candidate tool's schema and metadata, and invoke this prompt against the current registry snapshot before any write occurs. The prompt's output determines whether the registration proceeds automatically, requires human review, or is rejected outright. This means the harness must supply two structured inputs: the candidate tool definition and the relevant slice of the existing registry, both normalized to a consistent schema format before the prompt sees them.

Build the harness around a strict JSON contract. The prompt expects [CANDIDATE_TOOL] as a single tool object with fields for name, version, input schema, output schema, and ownership metadata, and [REGISTRY_SNAPSHOT] as an array of existing tool objects in the same shape. Before calling the model, validate both inputs against a JSON Schema that enforces required fields and type correctness. After the model responds, validate the output against a conflict report schema that includes a conflict_detected boolean, a conflict_type enum (schema_incompatibility, version_mismatch, ownership_collision, namespace_collision, none), a severity enum (blocking, warning, info), and a recommendation field. If the output fails schema validation, retry once with the validation error injected into the prompt as additional context. If it fails twice, route to a human operator with both the candidate tool and the raw model output attached.

Log every invocation with the candidate tool ID, registry version, model used, conflict verdict, and the full prompt and response payloads. This audit trail is essential for debugging false positives and for governance reviews when a blocked registration is later contested. For high-throughput registries, consider caching the registry snapshot used in each invocation and tagging it with a version hash so that conflict reports remain reproducible. If the registry is large, do not send the entire registry to the prompt; instead, pre-filter to tools in the same namespace, tools with overlapping capability descriptions, or tools whose schemas share parameter names with the candidate. A lightweight pre-filter reduces token cost and improves the prompt's focus on genuine collision candidates.

The human review gate is the most important integration point. When the prompt returns severity: blocking or conflict_type: ownership_collision, the harness must not silently reject the registration. Instead, it should create a review ticket with the conflict report, the candidate tool, the conflicting existing tool, and a link to the full prompt trace. The reviewer can approve the registration with an override, reject it, or merge the tools with a namespace prefix. The harness should accept an override decision and write it back to the registry with an audit note. Without this gate, a false-positive conflict detection can block legitimate tool registrations and erode trust in the automation. The prompt is the detector; the harness is the decision framework.