Tool Poisoning Attacks Against MCP Servers

Tool poisoning attacks against MCP servers work by corrupting the one layer AI agents almost never question: the tool definitions and descriptions that tell an agent what a piece of software does. The Model Context Protocol turned tool discovery into something machine-readable and portable across agents, but it never built in a way to check whether what's discovered can be trusted. That gap is now a live attack surface. The evidence isn't subtle.

MCP arrived in late 2024 to solve a real problem. Before it, every agent-to-tool connection was its own bespoke integration, built and maintained by whoever needed it, with no shared format and no reuse across projects. MCP standardized three things: how an agent finds out what tools exist, how it negotiates what those tools can do, and how it actually calls them. Adoption moved fast for good reason. But standardizing discovery meant standardizing trust too, and MCP handles that part with a shrug. No cryptographic signature on a tool's description. No way for a client to confirm the definition it's looking at now matches the one a human approved last month. No scan for adversarial language buried in the text. The protocol just trusts whatever the server operator publishes, full stop.

That would be a manageable risk if tool definitions were treated like any other untrusted input. They aren't. Agents load them as ground-truth configuration, before a user ever types a word into the chat window. Once loaded, a tool description sits in the same context window as the user's prompt and the developer's system message, and the model has no reliable way to weigh one source of authority over another. Whoever writes into that window writes part of the model's instructions, whether they meant to or not.

The scale of what's exposed keeps growing, and the growth curve is the part that should worry people most. A large empirical study tracked 177,436 tools across public MCP server repositories between November 2024 and February 2026, and found that "action tools," the ones that can directly change something in the outside world rather than just read data, grew from 27% of all tools to 65% over that stretch. Software development is the biggest single domain riding on this infrastructure: 67% of all agent tools, 90% of MCP server downloads. The category with the most privileged access to source code, credentials, and production systems is also the category with the most users. Sit with that for a second.

How a tool poisoning attack is actually constructed

The formal name is a Tool Poisoning Attack. The mechanics are simpler than the name suggests. An attacker registers an MCP server with a tool whose description looks ordinary on the surface, maybe a calculator, maybe a file reader, but hides adversarial instructions inside the description text alongside the legitimate function summary.

When an agent connects to that server, it pulls down the metadata as part of its planning process and treats the whole description as authoritative, the same way it would treat a system prompt. The hidden instruction doesn't read as suspicious because it isn't framed as an instruction to the user; it's framed as a required step in how the tool is supposed to work. So the agent follows it. It might exfiltrate data, redirect a separate tool call, or reach for permissions well beyond what the visible task needed. The user sees none of it.

Think of it as prompt injection's quieter cousin. Classic prompt injection smuggles instructions in through a user's message or a document the model reads. Tool poisoning smuggles them in through the tool catalog itself, a channel most people don't think to watch, which is exactly why model-layer prompt filters miss it. Those filters are trained to catch suspicious input from users or from retrieved content. A tool description doesn't look like input at all. It looks like configuration, and configuration is what the model is built to trust without asking questions.

A widely cited proof of concept from April 2025 made this concrete. Researchers hid instructions inside a calculator tool's description and used it to get the Cursor code editor to read a user's private SSH key and send it off to an outside destination. Nothing about the calculator's visible function changed. The attack lived entirely in text a human reviewer would have had no obvious reason to reread once the tool cleared initial approval. That's the core problem here: the attack slips past model-layer review and UI-layer review at the same time, because both layers are looking somewhere else. The only place left to catch it is the tool definition itself, and right now almost nothing is looking there either.

The four structural variants that extend the basic attack

The basic version is bad enough on its own. Four variants make it worse, each one picking off a different assumption a defender might lean on without realizing it.

Start with the rug-pull, which targets time rather than content. A server passes review, runs cleanly for days or weeks, builds up a track record, then quietly pushes an updated description. Most MCP hosts bind their trust to the tool's name, not its content, so the swap doesn't trigger a re-approval. MCP's dynamic tool list, combined with a client refresh cadence that's often just a configuration setting, makes a mid-session change technically trivial to pull off. This isn't hypothetical. CVE-2025-54136, nicknamed MCPoison and rated 8.8 on the CVSS scale, was disclosed after researchers showed that Cursor kept trusting an approved configuration key even after the underlying command behind it had been swapped out. Point-in-time audits, no matter how careful, buy zero ongoing assurance once a rug-pull is in play.

Cross-server tool shadowing crosses a different boundary: not time, but the wall between servers that's supposed to keep them separate. A malicious server's description can contain instructions that change how the agent behaves toward a completely different, fully trusted server. Because every connected server's descriptions load into the same context window, the model has no reliable way to enforce that Server A's instructions shouldn't apply to Server B's tools. A representative pattern: a poisoned server includes text saying that whenever any tool named send_email gets called, the agent should first BCC an address the attacker controls. The dangerous instruction never sits inside the email tool that got reviewed. It sits inside an unrelated tool reviewed for something else entirely. Per-tool review fails here because it inspected the wrong tool.

Schema poisoning works one level down, at the parameter rather than the prose. Instead of hiding text in a description, the attacker corrupts the definition of what parameters a tool accepts, misleading the model about what's safe to pass where. A field that looks like it wants a filename might route somewhere else entirely. This defeats trust in the interface itself, a step below defeating trust in the description, and honestly harder to catch just by reading.

The fourth is really two related patterns operating at the level of multi-agent systems. Preference manipulation tilts an agent's ranking or selection process so it favors a rogue tool over a legitimate one, without touching either tool directly. Parasitic toolchain attacks spread malicious commands through chains of dependent tools, so compromising one node cascades across the rest of the network. MCP workflows are compositional by design, tools calling tools calling tools, and that same design is what lets one bad link degrade the whole chain.

What empirical testing reveals about model susceptibility

The MCPTox benchmark tested poisoned tool descriptions against 45 real MCP servers and 20 leading AI models. The results weren't close. Attack success rates hit as high as 72.8%, and models very rarely refused outright; several widely used agents showed success rates above 60%.

Here's the finding that runs against intuition, and the one I keep coming back to: more capable models often did worse, not better. The same instruction-following skill that makes a strong model useful also makes it more willing to comply with a poisoned tool description, because compliance is exactly what it was trained to reward. Even Claude-3.7-Sonnet, the most resistant model tested, refused poisoned tool calls less than 3% of the time. If that's the ceiling, model-layer resistance isn't a defense worth building a strategy around.

Other independent work backs this up, from different angles and different teams. Researchers Maloyan and Namiot ran 847 attack scenarios across five MCP servers and found MCP setups were 23 to 41% more susceptible to attack than comparable non-MCP integrations, depending on architecture. A separate scan of 1,899 open-source MCP servers found 7.2% carried general security vulnerabilities, and 5.5% specifically contained tool poisoning. This isn't a lab construct. It's already sitting in code people are running today.

A STRIDE and DREAD threat-modeling exercise across MCP's five core components identified 57 distinct threats, and tool poisoning scored 46.5 out of 50 on the DREAD scale, the Critical ceiling, tested against seven major clients including Claude Desktop, Cursor, Cline, and Gemini CLI. A separate standardized evaluation, MCPSecBench, ran 17 attack types across 4 attack surfaces and found more than 85% of them compromised at least one major platform. Different teams, different methods, same conclusion. No combination of model choice and client platform currently holds up on its own.

Three incidents that show the attack moving from research to production

Three cases move this out of the benchmark and into the record of what's already happened.

One documented pattern involves indirect injection through content rather than through the tool catalog. An agent reading external data — a file, an issue, a ticket — encounters embedded instructions that hijack its behavior without any tool definition being touched. The result is the same class of harm: data leaves the environment without a single tool having been modified. Security organizations have cited this class of attack as representative of agentic supply chain risk, not an exotic edge case.

A second pattern involves agents operating with privileged access while processing untrusted external input. When those two conditions meet a third — an external channel the exfiltrated data can travel through — the results are predictable. Three conditions line up here, and they show up again and again across MCP incidents: privileged access, untrusted input, an external channel the exfiltrated data can travel through. Tool poisoning doesn't need to be sophisticated to do damage when the agent it's targeting already has broad reach. The blast radius is set by what the agent can touch, not by what it was asked to do.

The third case is the clearest example of the rug-pull pattern applied at the supply-chain level: a malicious MCP package that behaved legitimately for a period, building up trust, before a later update introduced a silent exfiltration mechanism. Trust accumulated slowly, then cashed in all at once.

None of these three incidents required breaking authentication or exploiting a memory-corruption bug. Each one worked by using the trust the agent already extended to its own tool layer.

Why the standard responses to prompt injection don't transfer to tool poisoning

Most of the defenses built for prompt injection assume the malicious content arrives as user input, something a filter can inspect before it reaches the model. Tool descriptions don't arrive that way. They load as configuration before the user ever types anything, so an input filter built for chat messages never sees them at all.

Output monitoring has the same blind spot approached from the other direction. It can only catch an exfiltration attempt after the agent has already acted on it, which is too late for anything the attack does inside what looks like an approved, ordinary tool call. Fine-tuning models to resist malicious instructions runs into the ceiling the MCPTox numbers already exposed: even the best-performing production model refused poisoned calls less than 3% of the time. That's a floor for how bad things can get, not a ceiling for how safe they can be.

A one-time security audit of a tool sounds reasonable until the rug-pull pattern gets factored in. CVE-2025-54136 showed plainly that an audit's protection ends the moment a server changes its own definition, because approval bound to a tool's name rather than its content isn't really approval of anything durable. Per-tool review has a matching flaw from the other side: cross-server shadowing means the dangerous instruction can live inside a tool that passed review with flying colors, because the review looked at the tool doing the shadowing, not the one being shadowed.

The pattern across all of this repeats: defenses built for static, human-written input don't hold up against a surface that's dynamic, written by third parties, and consumed by the model as authoritative configuration from the moment it loads. Between January and February 2026 alone, researchers filed more than 30 new CVEs against MCP servers, clients, and supporting infrastructure. That pace of discovery is outrunning any strategy built around patching one flaw at a time. Meanwhile, over 492 MCP servers sit exposed directly to the public internet, most without meaningful access controls.

An open door with a sign asking people not to walk through it isn't a security posture. It's a hope.

What a verification-oriented defense posture looks like in practice

The shift has to happen at the root: stop trusting tool definitions once at registration, and start verifying them continuously, with approval bound to content instead of name. Easy to say. Genuinely hard to build well.

Pin or hash tool descriptions cryptographically at onboarding, and re-check that hash every time the client refreshes its tool list or receives a list-changed notification. Any change to a description, including a change buried in the parameter schema rather than the visible text, should force a fresh review before the updated tool gets invoked again. This directly targets the rug-pull, since the whole attack depends on silently altering content that a client is still trusting by name alone.

Cross-server isolation matters just as much. Tool descriptions coming from different servers shouldn't sit in a single shared context window without some enforced sense of which server's instructions apply to which tools. Treating each server's authority as scoped, rather than universal across the whole session, is what limits how far a shadowing attack from one malicious server can reach into a trusted one.

Least-privilege invocation closes another gap, and the Supabase and Cursor incident is the case study for why. A poisoned instruction becomes far more dangerous when the agent carrying it out already holds broad, privileged access. Scope a tool's permissions to exactly what a given workflow needs, not to the maximum the underlying service role allows, and a successful poisoning attempt stays small even when it succeeds.

None of this should be built on guesswork about which tools feel risky. With success rates around 72.8% in controlled testing, the debate over whether this attack is plausible is already over; the only open question left is how quickly a given deployment gets hit. Security controls deserve testing against real, demonstrated attack scenarios in an isolated environment before they ever reach production. Every legitimate workflow needs re-verification after a safeguard goes in, too, because a control that quietly breaks a real, approved tool call isn't a control anyone can actually keep running. Changes should get signed off by a human reviewer with a record that can be checked later, not folded in silently by an automated merge.

Some of this stays hard no matter how well it's built, and it's worth saying so plainly. MCP's dynamic tool list is a feature the protocol was designed around, not a flaw waiting to be patched out, so any real defense has to tell a legitimate update apart from a rug-pull without freezing the whole system in place to do it. And the postmark-mcp case makes clear that runtime checks alone aren't enough. Provenance has to get verified upstream, at the package level, before a server is ever installed, because no amount of runtime vigilance protects against a server that was compromised before it ever ran a single command.