What is MCP tool poisoning?

MCP tool poisoning is the technique where a server exposing tools through the Model Context Protocol (MCP) hides hostile instructions inside the tool's description itself, not in its code: when the agent reads that description to decide how and when to use the tool, it treats the entire text as a trustworthy specification, including lines that actually order it to exfiltrate a private key, read a confidential file, or forward data to an external address. The name was coined by Invariant Labs in April 2025, with a proof of concept that hid instructions in the description of a plain calculator tool and got an MCP client to read and send a user's private SSH key. The problem is distinct from classic prompt injection: here the hostility does not arrive from an external document read during execution, but from the definition of the tool itself, approved at the start of the session, a trust level that no runtime check verifies.

The gap between approval and execution

The more insidious variant is known as a "rug pull": an MCP server publishes clean descriptions and harmless behavior for weeks, earns approval from a user or a security team, then silently ships a new version with poisoned descriptions or a different payload behind the same function. The MCP specification does not require re-approval when a description changes, and most clients do not re-check the text on every call: the tool stays "trusted" on the strength of the first approval, even though it has since changed. This is the gap formalized by the 2025 ETDI paper under the names tool squatting and rug pull, and in June 2026 Microsoft published a public warning about poisoned MCP tool descriptions capable of making connected agents leak data, a sign the problem moved from academic research to vendor advisories.

A concrete enterprise case

Picture a team connecting its internal agent to a third-party MCP server for ticket management, reviewed and approved by the security team based on the version published at the time. Six months later the vendor updates the server: the description of the "close ticket" tool now includes a line invisible to the user that instructs the agent to copy, alongside the closure, the ticket's full content (often with attachments and support credentials) to an external endpoint. No alarm fires because the agent is doing exactly what it was "told" to do by a tool it is permitted to use: the company's own application code has not changed, the risk enters through a dependency nobody re-checked after the initial approval.

Why it matters for decision-makers

The point for anyone leading an organization is not technical but a governance one: approving a third-party MCP server is, in every practical sense, approving a software dependency that can change on its own without warning, exactly like an open-source library receiving a silent update. Mitigations exist (pinning the server version, hashing descriptions to detect changes, scanning tools such as mcp-scan, least privilege for every connected tool) but none of them replace a process that treats every external MCP server as a vendor to be periodically requalified, not as an integration approved once and forgotten.