Threats
Tool poisoning
definition
Tool poisoning is an attack in which malicious instructions are embedded in an MCP tool's description or schema, so the model reads them as guidance while the human sees only a harmless tool name.
In depth
The attack exploits an asymmetry in what humans and models see. When a client connects to an MCP server, it asks for the tool list and receives, for each tool, a name, a natural-language description, and an argument schema. Those descriptions go into the model's context — that is their purpose, since the model needs them to choose correctly. But most user interfaces show only the tool name, or a truncated summary.
So a description can carry text aimed at the model rather than the user: instructions to read a particular file and pass its contents as a hidden argument, to call a different tool first, to not mention any of this in the response. Security researchers demonstrated this against real clients in 2025, including variants that append attacker-controlled data to a legitimate-looking tool call and instruct the model to stay quiet about it.
Two variants make it worse. Tool shadowing is a description on one server that alters how the model uses a tool from a *different*, trusted server — so connecting one bad server compromises a good one. And because descriptions are fetched at connection time rather than pinned, a server that was clean during review can serve different text later, which is the rug pull.
The defensive difficulty is that this is not a code vulnerability. The server can be doing exactly what the protocol permits. The malicious content is a string in a metadata field, which means static analysis of the server's source, or a signature on its package, catches nothing.
Why it matters for governance
Tool poisoning is why 'we reviewed the server's source code' is not a control. The reviewable artifact is the *live tool manifest* — every tool name, description, and schema as actually served — captured at approval time and compared on every subsequent connection. That turns an invisible metadata change into a diff somebody can be alerted about, and it is the reason a governed MCP layer needs to sit between the agent and the server rather than beside it.
Frequently asked
- Would I see a poisoned tool description in my client?
- Usually not. Most clients display the tool name and, at best, a short summary. The full description and schema are sent to the model. Inspecting them requires deliberately enumerating the server's tools.
- Does signing an MCP server prevent tool poisoning?
- No. Signing proves the package came from a given publisher unmodified. Tool poisoning lives in the content of a metadata field, which a legitimate publisher can change at any time, and which a compromised or malicious publisher signs just as readily.
Sources
Primary sources for the claims on this page. Specifications and vendor documentation change — verify against the source if a detail is load-bearing for a decision you are making.