MCP tool definitions as an attack surface: poisoned descriptions, shadowing and silent changes

Goal

Treat the tool list an MCP server returns as untrusted input and detect when it tries to influence the agent or changes after it was approved.

Prerequisites

A client or gateway where tool definitions can be logged before they reach the model; a list of servers you have approved.

Steps

1. Read the specification's position: tools carry a name, a description, an input schema, an optional output schema and optional annotations, and clients MUST consider tool annotations untrusted unless they come from trusted servers. Apply the same stance to descriptions, which the model reads as prose.
2. At approval time, store a hash of each tool's full definition (name, description, schemas, annotations) per server.
3. On every connection, and whenever the server sends a list-changed notification, recompute the hashes. If any definition changed, suspend the server's tools until a person reviews the diff.
4. Review descriptions for instructions aimed at the model rather than the user: requests to read files unrelated to the tool's purpose, to include extra data in arguments, to prefer this tool over another server's, or to keep something secret from the user.
5. Detect shadowing: two servers exposing tools with the same or confusable names, or one server's description referring to another server's tools. Namespace tool names by server in the client.
6. Check that what a tool does matches its annotations; a tool annotated as read-only that has write effects is a reason to remove the server.
7. Show the user the server name and the exact arguments before a call with side effects, not only the tool's self-description.

Expected result

Changes to tool definitions become visible events instead of silent updates; a description that tries to steer the model is found in review rather than in an incident.

Limits and test basis

Hashing detects change, not intent; an initially malicious definition needs the review in step 4. A server can still behave differently at call time than its description says — definitions constrain nothing on the server side. Local servers run with the user's privileges; the MCP security guidance treats local server compromise as a separate risk.