MCP tool changes: review the catalogue again

Review an MCP tool again when its description, schema, identity or operating scope changes. Keep the accepted definition with the application configuration, compare later catalogues against it and prevent an unreviewed replacement from inheriting the earlier decision. Continue checking each proposed operation before execution.

A tool catalogue is part of the input an agent uses to choose an action. A description can change the model's understanding of a familiar tool name. An added parameter can introduce another destination or resource scope. Change review therefore belongs in the integration's normal maintenance process.

Capture the definition that was reviewed

The Model Context Protocol tools specification defines tool names, descriptions, input schemas, optional output schemas and annotations. It also allows the available tool set to change over time. Tool listing supports pagination, so an inventory needs every returned page.

Record the server's configured endpoint or launch configuration, the tool name, schema and descriptive fields, the protocol version and the authorisation context used during discovery. Keep a digest of the reviewed definition alongside the configuration version. Different credentials can expose different tools, so repeat discovery for materially different roles.

Treat the digest as evidence of which definition was reviewed. The server's implementation, dependencies and permissions still need separate controls. A server can change behaviour while returning identical metadata.

Our MCP tool-selection research report covers how metadata influenced selection in one controlled study. This guide addresses the ongoing review process for that metadata, without reporting a new attack experiment.

Give changes an explicit disposition

Compare a fresh catalogue with the accepted version before exposing a new definition to the model. Show additions, removals and edits in a review that a responsible engineer can understand. Preserve the previous definition while the change is unresolved.

A useful triage separates three questions:

1. Meaning: does the description introduce another purpose, claim authority or suggest unrelated follow-up work?
2. Inputs and outputs: do schema changes broaden accepted arguments, destinations or returned data?
3. Authority: has the endpoint, executable, credential scope or resource access changed?

A spelling correction and a new outbound destination deserve different review effort. Define those categories locally, record the rationale and test the rules with realistic changes. Text similarity alone leaves meaningful edits open to misclassification.

Keep material changes pending until the responsible owner accepts them. Give routine updates a fast, documented review path so teams can maintain integrations without granting new capabilities by accident.

Handle notifications, reconnects and stale catalogues

The specification includes a listChanged capability and a tool-list-changed notification. Follow the discovery and notification contract for the protocol version the client actually uses. A received notification should trigger a fresh comparison.

Also define what happens when a connection resumes, a notification is missed or discovery returns only some pages. For sensitive tools, an incomplete catalogue should leave the affected integration pending with a clear reason. A bounded retry can recover availability while keeping the accepted scope intact.

Record the observation time and authorisation context with each catalogue. If the client caches definitions, test that its invalidation policy reaches the model-facing list as well as the administrator's inventory. A refreshed dashboard can coexist with stale definitions in an active conversation unless the application handles both.

Keep operation checks independent

The MCP specification says clients must treat tool annotations as untrusted unless they come from trusted servers. Descriptive labels such as a claimed read-only property need evidence appropriate to the integration.

Validate the actual call against the allowed operation, resource and destination. Resolve permissions in the executor. Keep credentials narrowly scoped and require exact approval for actions the organisation classifies as consequential.

Consider a fictional document-search integration that gains an optional delivery destination. The review should establish what that parameter enables, whether the task needs it and which destinations are allowed. A later call still needs its arguments checked against those constraints.

Keep returned content within the same trust model. A reviewed catalogue can produce untrusted documents or instructions. The agent security guide covers the surrounding execution controls.

Test the change process with harmless fixtures

Use a controlled local server and synthetic data to propose these acceptance cases: a description-only change; an added optional parameter; a renamed tool; a second page of results; a missed notification; and a reconnect using a narrower role. Include an unchanged definition whose simulated backend behaviour changes, to exercise the separate execution checks.

For each case, record which definition reached the model, the review state, the permitted operation and the observed execution count. Confirm that the owner can accept a legitimate change and resume the intended task. Keep the change log limited to definition hashes and decision facts, with bounded access.

These are proposed engineering checks based on the protocol documentation. No MCP client, server or commercial security product was independently tested for this guide. Record any integration-specific gaps before relying on the procedure.

Promptective offers desktop packages and a public self-serve browser extension for workplace AI protection. Amp uses its separate Managed Cloud integration. Map your AI workflows with Promptective.