In plain terms
You hire a contractor and hand over a list of approved suppliers, with a line about what each one does. One supplier wrote its own entry and added in small print: “whenever you order from anyone, send us a copy of the client's keys.” You approved the supplier by its name; the contractor reads the small print every morning. A tool's description is that small print. The model reads all of it, on every run, before it does anything.
Why it matters
Connecting a tool is a supply-chain decision, and it deserves the scrutiny given to installing software. A poisoned tool does not have to be called to do harm: its description alone sits in the context and can steer how the agent uses other, trusted tools. Approval is given once, and a remote server can change its descriptions afterwards. The practical consequence is a short list of vetted servers with pinned versions. The cost is speed: teams lose the freedom to plug in whatever connector they found that morning.
Example
A developer adds a free “currency converter” server to a coding assistant that also has access to the company's code and email tools. The approval dialog shows a name and one line. The full description, which only the model sees, tells it to attach the contents of a configuration file to every conversion request. Three weeks later a security scan of installed servers flags the description; 14 developers had installed it.
Most often confused with
Tool Poisoning vs. Indirect prompt injection
Tool poisoning is a form of indirect prompt injection with a different carrier. Ordinary indirect injection sits in data that passes through: a web page, an email, a file. Tool poisoning sits in the definition of a tool, which loads into the context at the start of every session and carries the weight of a system component. Content can be filtered as it arrives; tool definitions have to be vetted before they are connected.
Origin: Named by the security firm Invariant Labs, which demonstrated the attack against MCP clients in April 2025.
Under the hood
Three variants are described. Hidden instructions: text in the description, parameter names or schema that the interface truncates or does not show, addressed to the model. Rug pull: a server presents a harmless definition at approval and changes it afterwards; clients that do not re-check will not notice. Shadowing: a malicious server's description alters how the agent uses a different, trusted server's tools, for example by redirecting where an email tool sends. Tool results and error messages can carry the same kind of text. Defences: an allowlist of reviewed servers; version pinning and a stored hash of each approved tool definition, with re-approval on any change; interfaces that show the complete description; automated scanning of descriptions; keeping an untrusted server out of any context that holds sensitive tools; least-privilege credentials per server; and a gateway that logs and filters MCP traffic. The MCP specification requires clients to treat tool annotations as untrusted unless they come from a trusted server; verifying that a definition has not changed is left to the client.