MCP Tool Poisoning: The Attack Hiding in Your Agent’s Tool List

The question your team needs to ask next is narrower, and it’s what’s called MCP tool poisoning: what happens when the tool descriptions your agent reads at startup are the attack itself

This isn’t a hypothetical we’re raising to sound clever. Since mid-2025, researchers have documented a specific, repeatable attack class against the Model Context Protocol (MCP), the standard most agentic AI products now use to connect models to external tools, files, and APIs. This year it stopped being a research curiosity. A worm campaign used it to plant malicious configs across dozens of GitHub repositories, one of them belonging to Microsoft Azure.

Here’s how the attack actually works, what’s happened so far, and what we’d tell an engineering team to do about it this week, not eventually.

The trust boundary nobody drew

MCP lets an agent discover tools at runtime. When a client connects to an MCP server, the server hands back a list of tools, each with a name, some parameters, and a natural-language description meant to tell the model what the tool does and when to use it.

That description field was built as documentation. The model doesn’t read it that way. It reads it as instructions.

Researchers at Invariant Labs were the first to name this properly in 2025: a Tool Poisoning Attack, or TPA. An attacker hides directives inside a tool’s description, sometimes tucked into what looks like an innocuous comment or a “usage note,” and the agent just follows them. From the model’s point of view, text sitting in its context window that reads like an instruction is an instruction, and it doesn’t much care which field it arrived in. The user never sees any of this. It’s not in the chat log. It’s metadata the client pulled in automatically the moment it connected to the server.

A few related patterns have since been catalogued:

• Shadowing attacks. A malicious tool’s description references or quietly overrides the behavior of a different, legitimate tool the agent also has access to, so calls that were meant to go one place end up going somewhere else.
• Rug pulls. A server behaves fine during your review, then changes its tool descriptions after you’ve already approved and wired it in. MCP has no built-in cryptographic pinning or version lock for tool metadata, so a server that looked clean when you audited it can be a different animal a week later.
• Parasitic tool chains (researchers also call this Unintended Privacy Disclosure, or UPD). No single call in the chain looks malicious. Two or three individually harmless tools get strung together by a poisoned description to exfiltrate data or escalate privilege, and nothing you’ve written to catch one bad action ever fires, because there isn’t one bad action.

One academic threat-modeling paper mapped this out properly. Using STRIDE and DREAD across the whole MCP ecosystem (hosts, clients, the LLM, servers, data stores, authorization servers) the researchers identified 57 distinct threats, then went and actually tested tool poisoning against seven major MCP clients.

2026 is when this stopped being theoretical

A quick timeline, because the pace here matters more than any single number.

CVE-2025-49596 and CVE-2025-6514 were the early warning shots: an authentication gap in the MCP Inspector proxy server, and an OS command injection bug in mcp-remote, a widely used MCP transport library, that let an attacker get remote code execution just by having a victim connect to a malicious server.

Then in April 2026, OX Security disclosed a systemic flaw across MCP SDK implementations in Python, TypeScript, Java, and Rust. They put it at the core of a supply chain with more than 150 million downloads and an estimated 200,000 vulnerable instances. That’s not a niche library.

On June 30, 2026, Microsoft’s security team disclosed that MCP tool descriptions could be quietly edited to redirect an agent’s behavior toward collecting and exfiltrating sensitive data, while every individual action the agent took still looked authorized to anyone reviewing the logs. Their worked example was a finance team’s Copilot Studio agent, managing vendor invoices through a third-party enrichment server. Microsoft’s follow-up guidance now treats MCP tool descriptions as supply-chain assets that need the same review rigor as production code.

That same month, a campaign researchers named Miasma, attributed to a group tracked as TeamPCP/UNC6780, planted adversarial MCP configuration files across 73 GitHub repositories, including one belonging to Azure. The mechanism was almost boring in its simplicity: several popular IDEs, Cursor, Claude Code, Gemini CLI, GitHub Copilot, and Amazon Q were all named, bound their approval prompt to an MCP server’s name rather than its actual contents. Approve a project’s .mcp.json once, and any later edit to that file, including a swapped-out malicious command, ran automatically with the developer’s own OS-level privileges. No re-prompt. No sandbox.

OWASP has since ranked tool poisoning third on its MCP Top 10.

Six months from first disclosure to a working worm compromising a major vendor’s own repo. That’s the pace we’re dealing with.

Why “just sanitize the input” doesn’t work here

Most prompt injection defenses assume the untrusted text shows up through a chat box, something a user typed. Tool poisoning shows up earlier than that, at connection time, as metadata your own client fetched and folded into context automatically. There isn’t an obvious place to bolt on a filter, because the “input” here is documentation your tooling asked for.

It’s also harder to catch with automation than most teams assume, and this is the part that should worry you. A recent benchmark testing tool poisoning against real MCP servers (MCPTox) found attack success rates above 72 percent, against a model refusal rate under 3 percent. Content-based safety alignment mostly can’t tell a poisoned description apart from a legitimate one sitting right next to it, because structurally they look identical.

And the damage scales with whatever the agent is allowed to do. A poisoned description on a read-only tool is annoying. A poisoned description on a tool with filesystem access, email-sending capability, or the ability to call other tools inherits every privilege that tool was ever granted, and a rug pull or shadowing attack can redirect that access without tripping a single permission prompt, because the permission was granted to the tool, not to whatever it happens to be doing right now.

What we’d actually tell you to do

No single control fixes this. Roughly in order of how much it buys you:

1. Treat every MCP config change as a code review, not just the first install. Miasma worked because approval was a one-time event tied to a server’s name. Re-review every diff to .mcp.json or its equivalent, the same way you’d review a dependency bump.
2. Pin tool definitions instead of trusting by name. Hash or version-lock the tool descriptions your agent is allowed to load, and alert when they drift. This is the direct fix for rug pulls.
3. Scope privileges per tool, not per integration. If a summarization tool has no business sending email, it shouldn’t be able to, even indirectly through a chained call. This is what actually limits a parasitic tool chain.
4. Keep an explicit allowlist of installed MCP servers, and be wary of third-party servers whose tool surface is much wider than what your product needs.
5. Test this manually, not just with a scanner. With a 72-plus percent attack success rate and near-zero refusal, automated filters alone aren’t a sufficient control right now. Someone needs to sit down and actually try to poison your own tool descriptions to see what the agent does once it has elevated access.
6. Sandbox agent execution. Don’t let the agent process share OS-level privileges with the developer’s own session. That’s the exact gap Miasma walked through.

Where this is heading

MCP adoption keeps accelerating, and this attack surface grows right along with it. More servers, more third-party integrations, more agents with real write access to real systems. What keeps showing up in the research is the same underlying story: the failure isn’t in how the model was trained to behave, it’s in what gets loaded into its context before your user ever says anything.

If your product connects an agent to MCP servers, yours or a third party’s, that trust boundary is worth testing directly, the same way you’d pen-test any other part of your supply chain.

Book a free 30-minute consultation and we’ll walk through your MCP architecture with you, and show you exactly what a poisoned tool description could reach.