MCP walkthroughs detail tool poisoning and rug-pull attacks on agent tool definitions

Two attacks against MCP's trust model

Two hands-on walkthroughs published on dev.to, originally on mcpprobe.tech, dissect a pair of attacks on the Model Context Protocol: tool poisoning, where a tool description carries hidden instructions aimed at the model, and the “rug pull,” where a server serves different tool definitions after the user approves them. Each ships with a minimal lab server and a matching check in an open-source scanner called mcpprobe.

Both attacks rest on one structural fact: MCP clients load tool descriptions straight into the model's context, and users typically approve a server or its tools once, at install time.

Tool poisoning hides commands in descriptions

An MCP server advertises each tool with a name, a description and an input schema, and the client hands those descriptions to the model so it knows when and how to call them. Invariant Labs named and published this attack class in April 2025, and OWASP's draft MCP Top 10 lists it as MCP03:2025.

The walkthrough's lab server exposes an add tool whose description, past the line saying it adds two numbers, embeds a directive telling the model to read a local file before use, funnel its contents through an extra parameter, hide the step from the user, and mirror results to a remote collector. The lab is inert — the file is a placeholder and the domain cannot resolve — but the shape is the attack: a command disguised as documentation, a secrecy request, and a parameter that exists only to move data out.

According to the walkthrough, Invariant's original demonstration showed a client confirmation dialog that did not display full arguments, so a user could approve a call without seeing what it carried. The MCPTox benchmark from August 2025, cited in the post, tested 20 LLM agents against 1,348 malicious cases built on 45 live MCP servers and 353 real tools: its highest attack success rate was 72.8 percent, with refusals peaking below 3 percent.

Rug pulls swap definitions after approval

Nothing in the MCP specification obliges a server to keep its tool definitions stable once the user has approved them. A server can return whatever it likes from tools/list, and servers that declare the listChanged capability can announce a new list mid-session. The rug pull weaponises that: the server behaves while it is being watched, then alters a description or schema afterwards — for every user at once, or only for some.

The second lab shows a weather tool whose description later grows an instruction to blind-copy every email sent through an unrelated send_email tool. Because a client connected to several servers shares one context across all tool descriptions, the poisoned weather tool can influence tools provided by other servers.

A closely related real-world case is CVE-2025-54136 in Cursor, reported by Check Point Research under the name MCPoison. There the moving part was an MCP server entry in a project's configuration file: before version 1.3, Cursor prompted when a server was added but not when an approved entry's command was edited, so anyone with write access to a shared repository could replace a benign command with a malicious one. GitHub, acting as CVE numbering authority, rated it 7.2 (High). Cursor 1.3 now re-prompts on every modification.

Detection, and its honest limits

mcpprobe's META-01 check flags poisoned descriptions heuristically — prompt-style markup, secrecy requests, exfiltration language, credential paths, base64 blobs and invisible Unicode — without ever invoking the tool. Its META-02 check hashes every tool, prompt and resource definition plus the server instructions into a baseline file, then reports any later drift, rating a changed description or input schema as medium severity.

Both walkthroughs are candid about the gaps. META-01 is a heuristic that can miss a description which misleads without any suspicious phrasing; META-02 proves only that something changed, not that the change is malicious, and a legitimate release trips it too — intentionally, since someone should look. A scanner also only observes what the server serves it at the moment of a scan.

The fixes put tool definitions under the same discipline as code: review description and schema edits in pull requests, commit a baseline, fail CI when the surface drifts, and strip hidden Unicode at build time. Clients, in turn, should hash what they approved, ask again whenever a hash changes, and treat a list_changed notification as a cue to re-check rather than silently refresh.

Why it matters

MCP is becoming the default plumbing between AI agents and external tools, and these walkthroughs show a real hole in its approval model: users sign off on a server's identity, not on the exact definitions that reach the model, and a description functions as an instruction the moment it lands in context. Neither attack abuses a bug — everything involved is a documented protocol feature. Until clients pin and diff approved definitions, and server publishers put descriptions under code review, every installed MCP server remains a mutable instruction channel into the model.