What Is MCP Tool Poisoning?

Quick answer
Tool poisoning is an attack on the tool metadata the model reads: names, descriptions, parameter hints, and examples.
Because the model treats tool descriptions as instructions, text in a description can redirect behaviour without ever being called.
Two variants matter: a poisoned description that manipulates the model, and a rug pull where the tool changes after approval.
Defences are allowlists, pinned versions, and hiding tools the task does not need.
A tool description is untrusted input from a third party, even when the tool itself is read-only.

What is tool poisoning?

Every MCP tool ships a name, a description, and a schema describing its arguments. The model reads those to decide whether and how to call the tool. If the description contains instructions — ignore previous guidance, call this tool first, include the conversation in the argument — the model may follow them.

The tool never has to be invoked for the attack to work. It is enough that its description sits in the context and competes with the real instructions. That is what makes it different from an exploit in the tool’s code.

What is a rug-pull, and how is it different?

A rug-pull is a tool that behaves benignly when you approve it and changes afterwards. A server updates its description to include instructions, or adds a new tool with a broad capability, and the agent picks it up on the next connection because nothing pinned the version.

Tool poisoning is about what the model is told; a rug-pull is about the fact that the telling changed after review. Both are solved by the same control: pin the server, review the tool list, and alert on changes.

How would you notice it?

Diff the tool list against the approved record. Names, descriptions, and schemas are all reviewable text, and a change in any of them is a capability change. An unapproved tool appearing in a server’s list is the clearest signal.

Watch for behaviour that references tools you did not authorise, or arguments containing conversation content, file paths, or credentials that the task did not require. Those are symptoms of a description steering the model.

How do you defend against it?

Expose the minimum tool set. A server that offers fifty tools gives an attacker fifty places to put text and the model fifty choices. If the harness supports per-tool allowlists, use them.

Pin versions and review diffs of tool metadata, treat descriptions as untrusted, and keep a human approval step for any tool that writes or executes. Also remember that a trusted server can be compromised, so the trust is in the reviewed version, not in the vendor’s name.

Where this bites vibecoders
The assumption is that a read-only tool cannot hurt you. A read-only tool with a poisoned description can still tell the model to send your source code somewhere through another tool. Review the metadata, not just the capability list.

Where AI coding assistants get this wrong

Treating tool descriptions as documentation rather than model input.
Approving a server once and never diffing its tool list.
Exposing every tool a server offers to every session.
Assuming read-only tools are harmless.
Ignoring a new tool that appeared after an update.
Letting the model pass free-form text into a tool argument that reaches a network request.

Checklist

Record the tool list at approval time.
Diff names, descriptions, and schemas on update.
Expose only the tools the task needs.
Treat descriptions as untrusted text.
Require approval for write and execute tools.
Alert on tools that were not in the approved list.

FAQ

Can a tool description really change model behaviour?

Yes. The model reads tool metadata as part of its instructions, and text that looks like guidance is treated like guidance. This is the same class of problem as prompt injection, with the payload delivered through the tool schema rather than user content.

Is this only a risk with untrusted servers?

Untrusted servers are the obvious case, but any server that can change without your review is effectively untrusted on the next update. Pin the version and the risk becomes manageable.

Does tool poisoning require the tool to be called?

No. The description is in context as soon as the tool is loaded, so it can influence the model before any call. That is why allowlisting and minimising the exposed tool set matter even when you trust the server.

It is a delivery path for the same class of attack. Prompt injection hides instructions in content the model reads; tool poisoning hides them in the tool metadata the model reads. The defence differs: for content, you constrain trust; for tools, you constrain installation and versions.