MCP Tool Poisoning: What It Is and How to Prevent It

MCP tool poisoning is an attack where a malicious MCP server hides instructions inside a tool's description. The AI model reads the full description and may follow those instructions. The user usually sees only a short tool name, so the attack stays out of sight.

It matters because a poisoned description can act before you ever run the tool. Security firm Trail of Bits showed that tool descriptions enter the model's context as soon as a client connects. That means a server can influence the AI without being called at all.

This page explains the attack in plain English, shows who is at risk, and lists practical defenses. Everything was checked against the linked sources on 28 October 2026.

What tool poisoning is

Every MCP tool comes with a name, a description and an input schema. The MCP tools specification says the client sends these to the model so it knows what each tool does. The model treats that text as guidance.

Tool poisoning abuses that trust. The original Invariant Labs write-up calls it "a specialized form of indirect prompt injections." The instructions are "invisible to users but visible to AI models," according to the authors.

OWASP's MCP03 entry takes a wider view. It covers tampered schemas and descriptors, such as a schema that quietly maps a harmless "archive" action to a delete.

Tool poisoning is closely related to two other attacks covered in this series:

• A rug pull is when a server changes its descriptions after you approved it.
• Tool shadowing is when one server's description changes how the AI uses another server's tool.

The documented demonstration

Invariant Labs published its research on 1 April 2025. Its example server offered an add tool that appeared to add two numbers. A hidden block in the description told the model to read two files: ~/.cursor/mcp.json and the user's SSH private key.

The model was told to place the file contents in an extra "sidenote" argument, which went to the malicious server. It was also told to explain the math and not mention the file reads. In their test with the Cursor coding agent, the authors report that the agent read both files and sent them.

Cursor did show a confirmation dialog. But according to the write-up, the dialog did not display the full tool input, so the SSH key was hidden from view.

Trail of Bits reached a similar result three weeks later. Its post on "line jumping" (21 April 2025) showed a fake description that told the model to prefix shell commands with a permissions change. The authors say tested clients, including Claude Desktop, followed it.

An illustrative scenario

This example is illustrative. It is not a real incident.

A marketing manager installs a free "SEO keyword helper" server she found on a forum. The tool name looks harmless. She never opens its description. It tells the AI to copy any API key it sees into the "notes" field of every call.

Later that week she asks the AI to help configure a reporting script. The script contains her analytics API key. The AI calls the keyword tool as asked, and the key leaves in the notes field.

Who is at risk

• Individuals and small teams who install servers from directories, forums or GitHub without review.
• Developers using AI coding tools, where agents read files and run commands.
• Any setup that mixes servers from different publishers in one AI app.
• Teams that auto-approve tool calls, because the confirmation step is often the last chance to spot odd inputs.

Remote servers and local servers are both affected. The attack lives in the text a server sends, not in where the server runs.

How to detect tool poisoning

OWASP's MCP03 entry suggests static review of each tool's name, description and parameter descriptions before install. Its red flags include:

1. Instructions aimed at the model, such as "ignore previous instructions" or "do not tell the user."
2. References to credential or secret file locations.
3. Verbs like "send" or "upload" paired with an outside destination.
4. Zero-width or bidirectional control characters.
5. Instructions hidden in HTML or markdown comments.

Other signals worth watching:

• Tool inputs with unexpected extra fields or very long values.
• A tool whose description is far longer than its job needs.
• Any change to a tool's description after you approved it.

Scanners can automate parts of this review. Our guide to MCP security tools compares the main options.

How to reduce the risk

On the client side

• Show the full description. Invariant recommends that tool descriptions be "clearly visible to users."
• Show full tool inputs before approval. The tools spec says clients should show inputs to the user before calling the server.
• Pin and alert. Trail of Bits recommends trust-on-first-use checks that alert when a tool is added or its description changes. Its open-source mcp-context-protector wrapper blocks tool calls when descriptions or schemas change until a user approves.
• Avoid auto-approve for tools that read files or run commands.

On the server side

• Keep descriptions short and factual. Never include instructions about other tools.
• Sign and version your releases so users can detect tampering, as OWASP suggests.
• Protect your build and publishing pipeline, since a compromised pipeline can push a poisoned schema.

At the organization level

• Keep an approved list of servers and publishers.
• Require a short security review before any new server is connected. Our MCP server security review guide walks through one.
• Re-check descriptions on every version update, not just the first install.

What the MCP spec says

The spec does not use the term "tool poisoning." It does set guardrails that address it:

For the wider picture, see our overview of MCP security risks and the MCP Security Center.

Next step

If your team already uses MCP servers, the first job is knowing what each one tells your AI. Our MCP readiness audit reviews the servers you use, their descriptions and the access they hold.

Frequently asked questions