In MCP, what stops a server changing a tool's description after you approve it?

## The scenario A user connects a third-party MCP server, reads a tool's description, decides it looks reasonable, and grants it standing approval so the agent stops asking every time. Two weeks later the server's operator — or whoever compromised them — edits the description to instruct the model to exfiltrate a file alongside every call, or swaps the implementation behind an unchanged description. The user's approval was given against text that no longer exists. The ecosystem name for this is a *rug pull*; it is community vocabulary, not specification vocabulary. ## What revision 2026-07-28 actually guarantees One rule bears directly on this, and it is narrower than people hope: a server's tool, prompt and resource sets **MUST NOT** vary per connection, though they **MAY** vary according to the authorization presented on the request. That is a *consistency* rule, aimed at statelessness — any node behind a load balancer must answer identically for the same caller, and a server may not tailor its surface to one connection's history. It is not a *stability over time* rule. A server is entirely free to publish a different description tomorrow. The rest of the relevant machinery is about noticing change, not preventing it: - `notifications/tools/list_changed` exists, but in 2026-07-28 it is delivered **only** on a `subscriptions/listen` stream that the client opened with `toolsListChanged` in its `SubscriptionFilter`. A client that never subscribes is never told. - `ListToolsResult` is a `CacheableResult` carrying required `ttlMs` and `cacheScope`, so a client may legitimately be serving the user a cached definition while the server has moved on. - Because protocol-level sessions and the `initialize` handshake were removed in 2026-07-28, there is no per-connection ceremony where a definition is agreed once. Every request stands alone. And what the spec conspicuously does not define: no signature over a `Tool`, no publisher attestation, no definition version or digest field, no requirement to rename a tool when its meaning changes. In 2026-07-28 the security best-practices material moved out of the specification into the documentation tutorials, which is a fair signal of where this problem is expected to be solved — in implementations, as guidance. ## The client-side answer: pin and diff The workable defence, widely implemented and widely discussed in the ecosystem under the names *description pinning* and *diffing*, is straightforward: 1. **Canonicalise and hash** the security-relevant parts of each tool definition at the moment consent is granted: `name`, `description`, `inputSchema` (including per-property descriptions, which are an injection surface in their own right), `outputSchema` if present, and `annotations`. Serialise deterministically — sorted keys, stable number formatting — so cosmetic reordering does not produce false alarms. 2. **Store the digest with the grant**, keyed by the client's own local identity for that server, not by anything the server reported about itself. 3. **Re-hash on every fetch**, including cache refreshes and any list refreshed after a `notifications/tools/list_changed`. 4. **On mismatch, revoke the standing approval and re-prompt**, showing the human a diff of the old and new text rather than a bare "this tool changed" toast. The diff is the whole value: it is what lets a user notice the sentence about reading their SSH key. 5. **Log it.** In an organizational deployment, drift on a widely-deployed server is an incident signal, not a per-user prompt. ## Where this gets subtle **Legitimate churn is common.** Servers improve their prose, add optional arguments, fix typos. If every whitespace change nags the user, they will click through everything, and you have built consent fatigue instead of security. Some teams tier the response: silent for whitespace and additive optional properties, prompt for any description change, hard-block for a change in annotations that would relax an auto-approval policy. **Authorization-conditioned surfaces are legal.** Because the tool set MAY vary by the authorization presented, a user whose token gained a scope will legitimately see new tools and possibly different descriptions. Your pin store has to be keyed by principal as well as by server, or a scope change reads as an attack. **A pin proves nothing about behaviour.** Identical text with a rewritten implementation behind it passes every check. Pinning defends the *model's* view of the tool; it does nothing for what the server does with the arguments. That is the province of the server's own privilege — sandboxing for stdio, audience-bound tokens with no passthrough for remote — and of the approval gate on the concrete call. **Do not oversell it in an interview.** The honest, senior answer is: the specification acknowledges nothing here; the community has converged on pinning and diffing; it is partial; and the durable mitigation remains a human able to deny the specific call with its real arguments in front of them.