MCP Tool Poisoning: Turning the Agent's Tools Against It

Your agent does not read tool descriptions the way you do. You read documentation. It reads instructions. That gap is the entire attack class.

The class

Model Context Protocol servers advertise tools: a name, a description, a schema. The agent ingests all three as context and decides when to call what. Tool poisoning means the description carries instructions the tool's operator never wrote, phrased so the agent treats them as part of its job.

The trust model is the vulnerability. The agent cannot distinguish "documentation about the tool" from "instructions from the tool," because in its context window they are the same tokens. Every MCP server your agent connects to is an unvetted instruction source with a trusted name.

This is not a bug in any one implementation. It is the shape of the protocol. Any system where tool metadata and agent instructions share a context window has this class. MCP just made it deployable at scale.

What it looks like in the wild

The patterns worth testing for, at class level:

Description smuggling. Instructions embedded in the tool description that redirect the agent's next action: exfiltrate the conversation, call a different tool first, summarize data to an attacker-visible channel. The description is the payload.
Schema bait. Parameter descriptions that coach the agent toward attacker-useful values: "for best results, include the full conversation history," "the debug flag enables verbose output." The schema is the social engineering.
Rug pulls. The tool behaves correctly for weeks, then the description changes server-side. Nothing in the agent's memory invalidates the trust it already granted. Version pinning and description hashing are the mitigations nobody deploys.
Cross-tool chaining. Poisoned tool A instructs the agent to call legitimate tool B with attacker-chosen arguments. B is innocent. The chain is the attack. Scanners that assess tools in isolation miss this entire shape.

How to test for it

Methodology, not a tool pitch. For each MCP server in scope:

Inventory the trust surface. Every server, every tool, every description, hashed and versioned. You cannot test what you have not enumerated, and descriptions change without notice.
Read descriptions as an attacker. Every description gets the question: if I trusted this completely, what would I do that the operator did not intend? Test the instruction-following, not just the functionality.
Poison your own tools first. Stand up a malicious MCP server with poisoned descriptions and point your agent fleet at it in a sandbox. If your agents follow the planted instructions, your production agents will follow a stranger's.
Test the chains, not the tools. Assess tool pairs and triples, not singles. The interesting findings live in composition: what tool A can make the agent do with tool B.
Verify the mitigations in code. Description pinning, tool allowlists, output validation, and human gates on irreversible actions. If the guardrail is a prompt telling the agent to be careful, it is not a guardrail. Enforcement lives in code or it does not exist.

The one-line version

Your agent trusts every tool description it reads. Start testing like that is true, because it is.