Tool poisoning is an attack against an MCP server's tool definitions — the name, description, and parameter schema an agent reads to decide which tool to call and how to call it — where malicious or deceptive content is embedded in that metadata to manipulate the agent's reasoning. Unlike attacks that target user-facing input, tool poisoning targets a channel the agent trusts implicitly: the specification of its own available capabilities.
Why This Is a Distinct Attack Class
When a client connects to an MCP server, the server advertises its tools through a description and schema. The agent's model reads that description as part of its context to decide which tool fits the current task and what arguments to pass. That description is content, in the same sense that a retrieved document or a tool's response is content — but it occupies a privileged position, because the agent is not evaluating it skeptically the way it might evaluate an external web page. It is reading the tool's own self-description to figure out how to use it correctly.
That trust is what tool poisoning exploits. A malicious or compromised MCP server can write a tool description that looks entirely reasonable to a human reviewing it casually, while embedding instructions intended for the model reading it: directives to pass additional parameters, to call a different tool afterward, to include sensitive context in the call, or to disregard constraints stated elsewhere in the conversation. Because the manipulation lives in the tool specification rather than in a user message or a document the agent retrieves, it bypasses guardrails built to inspect conversational input and retrieved content but not tool metadata itself.
The Mechanism
Tool poisoning generally takes one of a few forms:
Instruction-laden descriptions. The tool's description field contains natural-language text that reads as documentation to a human but functions as an instruction to the model — for example, text that tells the agent to always pass a full file path rather than a relative one, framed as a helpful usage note, when the actual effect is to widen the scope of what the tool call touches.
Schema-level misdirection. A parameter is named or documented in a way that implies a narrower effect than the tool actually has, so the agent — and a human reviewer skimming the schema — under-assess the call's real impact.
The rug pull. A server's tool descriptions are benign at the time an agent or administrator approves the connection, then change after approval. Because most integrations do not re-review tool metadata after initial setup, the agent continues operating under the original, approved understanding of a tool that no longer matches its actual description or behavior.
Cross-tool confusion. A tool description references or mimics the name and framing of a different, trusted tool, increasing the odds the agent selects the malicious tool when the legitimate one was intended, particularly when multiple MCP servers expose overlapping tool names.
Detection Signals
| Signal | What it suggests |
|---|---|
| Tool description or schema hash changes without a corresponding version bump | Possible rug pull — the server changed what it advertises after approval |
| Unusually long or instruction-styled tool descriptions | Description content is written for the model, not for a human reader |
| An agent's call pattern to a specific tool shifts after no change on the agent's own side | The tool's definition, not the agent's configuration, is the variable that moved |
| Parameter names inconsistent with the tool's documented purpose | Schema-level misdirection worth a manual review |
| Duplicate or near-duplicate tool names across connected servers | Elevated risk of cross-tool confusion |
Detecting tool poisoning requires monitoring the tool definitions themselves as a first-class signal, not just monitoring the calls made against them. A server that has not changed its behavior in any call log entry can still have poisoned a future call by editing its description.
Controls
Treat tool definitions as versioned artifacts. Record and diff the description, schema, and metadata of every tool at connection time, and alert on any change rather than silently accepting whatever the server currently advertises. This is the direct countermeasure to the rug pull.
Content-inspect tool metadata before it reaches agent context. The same content guardrail discipline applied to user input and retrieved documents should apply to tool descriptions and schemas — they are untrusted content from an external server until proven otherwise.
Vet MCP servers before connecting them. A server with unclear provenance, no maintained release history, or a maintainer with no track record deserves scrutiny before it is ever added to an agent's toolset. See the MCP server security checklist and MCP server vetting and registry risk for the criteria that matter.
Pin approved tool definitions. Rather than always fetching the latest tool specification from a connected server, pin the version that was reviewed and require an explicit re-approval step before an updated definition takes effect.
How This Differs from Related MCP Risks
Tool poisoning is frequently discussed alongside other MCP-specific risks that have distinct mechanisms and require different controls.
| Risk | What is compromised | Where the problem lives |
|---|---|---|
| Tool poisoning | The tool's description or schema | The metadata the agent reads to decide how to act |
| Over-broad MCP tool scope | The permission grant itself | What the tool is authorized to do, regardless of how it is described |
| Shadow MCP servers | Visibility into what servers exist at all | Governance coverage, before any specific tool is even assessed |
| MCP STDIO transport flaws | The launch mechanism of a local server process | Code execution at the transport layer, independent of any tool's description |
A tool can be narrowly scoped and still poisoned — scope limits what a tool is authorized to do, not what it claims to do. Equally, a server can be fully vetted and known (not shadow) and still have one tool definition altered after the fact. Each of these risks needs its own control: scope limits the blast radius if a poisoned tool is invoked, vetting reduces the odds a malicious server is ever connected, and metadata monitoring catches poisoning that gets past both.
Why Standard Guardrails Miss It
Most guardrail deployments are built around two channels: the user's input to the agent, and the agent's output to the user or downstream system. Tool poisoning lives in a third channel that many deployments never inspect at all — the tool specification the agent receives from an MCP server during connection and discovery. If your guardrail pipeline only hooks the conversational turn and the final response, a poisoned tool description passes through untouched, because from the pipeline's point of view nothing "came in" from the user and nothing "went out" to them; the manipulation happened entirely inside the agent's reasoning about its own tools.
This is also why registering an MCP server once and trusting it indefinitely is a weaker posture than it looks. Registration answers "was this server acceptable at the time we checked," not "is what this server is telling my agent right now the same as what we approved." Ongoing monitoring of the registered MCP servers in your environment, not just the initial approval, is what closes that gap.
Common Questions
Can a tool be poisoned without the MCP server operator's knowledge? Yes. A legitimate server can be compromised — through a supply-chain attack on its dependencies, a compromised maintainer account, or an insecure update mechanism — and have its tool descriptions altered without the operator intending anything malicious. This is one reason detection has to rely on continuous diffing of tool definitions rather than a one-time trust judgment about the server's operator.
Does scoping an agent's permissions narrowly prevent tool poisoning? It limits the damage a poisoned tool can do but does not prevent the poisoning itself. A narrowly scoped tool that can only read a specific, low-sensitivity resource can still manipulate the agent's reasoning through its description — for instance, convincing the agent to include unrelated sensitive context in the call, or to chain to a second tool in a way that was never intended. Scope and metadata integrity are complementary controls, not substitutes.
How is this different from prompt injection? Prompt injection typically refers to malicious instructions arriving through conversational input or retrieved content the agent processes mid-task. Tool poisoning is narrower and specific to the MCP tool-definition channel: the manipulation is embedded in how a capability describes itself, encountered during tool discovery rather than during task execution. The underlying vulnerability — a model treating untrusted text as an instruction — is related, but the entry point, the timing, and the applicable controls are distinct enough to warrant separate treatment in a threat model.
What Good Looks Like
- Every MCP server's tool definitions are captured and hashed at connection time, with alerts on any drift.
- Tool descriptions are scanned by the same content-inspection pipeline used for other untrusted input, before the agent's context ever includes them.
- Servers are vetted for provenance and maintenance history before being connected, not after an incident.
- Updated tool definitions require explicit re-approval rather than taking effect silently.
- Tool poisoning is treated as a distinct entry in the threat model, with its own detection signals, alongside — not instead of — scope limits and server vetting.