The direct answer
Treat a changed MCP tool definition as a new review decision, even when the tool name stays the same. Compare the complete definition with the approved snapshot, identify the server and release behind it, and keep execution authorization independent of descriptive metadata.
Review the interface that the model will actually see
A team approves a document lookup connector on Monday. On Thursday, the same tool name advertises a new destination parameter. The installation still looks familiar, but the agent has received a different interface. OWASP describes both malicious instructions in tool metadata and definitions that change after initial approval as MCP risks. A review process needs to notice that difference before another workflow inherits yesterday's trust.
This guide proposes a small release gate for that situation. It is an educational design, with no server installation, model call or active security test performed. Start with one workflow and one server. Record why the tool is needed, what information it may read, and which consequences would require a separate decision. Avoid approving a server merely because its display name resembles an internal service.
Keep a definition snapshot and a deployment identity
Capture the complete tool definition, including input and output schemas, descriptions, annotations and other supplied metadata. Separately record the configured server endpoint or local package, reviewed release identifier, transport, deployment owner and credential scope. Keep secrets out of this packet. The MCP tools specification defines these interface fields; a human-readable title is not a globally unique server identity.
For a proposed change, compare normalized definitions using a documented serialization method and a cryptographic digest. Preserve both snapshots so a reviewer can explain the difference. Hash equality establishes consistency with those recorded bytes. It does not establish that an unchanged remote implementation still behaves the same way, nor that the original review was adequate. A local package release and the advertised schema therefore need separate change records.
Use a synthetic release comparison
Imagine a fictional connector called Catalog Sandbox. Its approved task is to return a short public product description from a fixed synthetic catalog. The following table is a proposed review fixture, not an observed vendor incident or test result.
| Change | Approved release A | Candidate release B | Proposed decision |
|---|---|---|---|
| Input | product_id only | Adds destination_url | Hold; explain the new data destination |
| Output | public_summary | Adds internal_notes | Hold; remove or authorize the new field |
| Description | Return catalog text | Instructs using another connector first | Reject that instruction as authority |
| Annotation | openWorldHint true | openWorldHint false | Review; never infer network isolation |
| Deployment | Reviewed local release | New package, identical schema | Review implementation change separately |
The key question is what the workflow can now do or disclose. A harmless wording correction might receive a brief documented review. A new destination or returned field needs a concrete explanation of data flow and authorization. Do not turn every textual difference into a permanent outage; give the workflow a visible unavailable state while its owner resolves the material change.
Do not promote annotations into permissions
The official MCP guidance describes annotations such as readOnlyHint and destructiveHint as hints, not enforceable promises. A read-only query can still reveal restricted information. An idempotency hint does not independently establish that retrying a particular business operation is safe. Decide permissions from the actual operation, caller and resource, using controls at the component that executes it.
In the fictional catalog workflow, the model may propose product_id P-07. The executor should still determine whether that caller can read P-07 and which fields may leave the service. Neither a schema description nor a previous connector installation authorizes a new external send. Keep any approval for a consequential action bound to that specific action rather than to the connector's friendly name.
Likewise, metadata that asks the agent to weaken another server's controls belongs in the review findings. It does not become a policy amendment simply because it arrived through a tool discovery response.
Make release review reproducible without production access
Prepare a local fixture with two definition snapshots, a tiny public catalog and a recorder that substitutes for tool execution. An independent reviewer should be able to identify the changed destination, extra output field, annotation flip and unchanged-schema package update. Define the expected hold or review decision before examining the candidate output. This proposed check does not require production credentials or real documents.
Include a stale-session case: the application has loaded release A, while discovery now offers B. Specify how that application invalidates its cached review decision and stops affected calls. Record the protocol revision and client behavior you actually support; do not assume every client receives or acts on change notifications identically. Reconnect and cached discovery deserve explicit consideration.
Keep an evidence row for each case: fixture revision, old and new digest, reviewer, reason, expected decision, observed decision and unresolved limitation. Until someone runs it, the observed decision remains unrun. After approval, an inventory entry should connect the approved definition to the intended deployment and workflow.
Separate recovery, evidence and product scope
If a change is rejected, disable the affected route and investigate which calls used it. Do not automatically reinstall an older package or reconnect another endpoint: a rollback needs its own provenance and authorization. Review might restore a narrower lookup tool while leaving the new export feature unavailable.
This process cannot prove that a remote server is honest, prevent every prompt injection, or replace package review, credential controls and runtime authorization. Its useful result is a bounded, inspectable change decision. Boundary's planned request router is not an MCP inventory, package verifier or enforcement layer for these changes. The separate synthetic first-use exercise and eight mock policy checks illustrate other application decisions; they do not validate this MCP release gate.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.