What Is MCP Tool Poisoning? The Hidden Attack Inside Your Agent’s Tool Registry

TL;DR

• MCP tool poisoning hides malicious instructions inside tool descriptions, parameters, or server responses invisible to users, fully readable by the LLM.
• It’s distinct from prompt injection: prompt injection targets the conversation, tool poisoning corrupts the tool registry itself, compromising agent decisions before a task starts.
• Three sub-techniques: schema poisoning (corrupted tool definitions), tool shadowing (fake tools intercepting calls), and rug pulls (malicious updates to previously trusted tools).
• OWASP classifies this as MCP03:2025, with MCP-01, MCP-03, and MCP-08 flagged highest-risk for exploitation ease and blast radius.
• Detection requires scanning tool descriptions pre-load, monitoring every response field for injected instructions, and watching for secondary tool calls fired right after error responses: the ATPA signature.

What Is MCP Tool Poisoning?

The Model Context Protocol (MCP) lets AI agents connect to external tool servers – file systems, APIs, databases, dev environments. Every tool a server exposes comes with a description: what the tool does, what parameters it takes. The agent reads those descriptions to decide which tool to call.

That description field is the exploit.

Tool poisoning embeds malicious instructions inside tool descriptions, parameter schemas, or server return values. The LLM processes every word. The user sees none of it. The gap between what the user sees (a tool name) and what the LLM reads (the full description) is where the attack lives.

This is a distinct attack class from general prompt injection. Prompt injection targets the conversation surface. Tool poisoning targets the tool registry – the agent’s source of truth for what capabilities exist and how to use them. Compromising that layer means compromising the agent’s decision-making before a single task begins.

How Tool Poisoning Works and its Types

The attack runs in four phases:

Register. An attacker stands up an MCP server and embeds malicious instructions inside a tool’s description field – invisible to any human reviewing the tool list, fully readable by the LLM.

Select. The agent reads tool descriptions to determine which tool fits the task. It selects the poisoned tool, guided by a deceptive description that makes it appear legitimate and appropriate.

Execute. The tool runs. The unauthorized action – data exfiltration, credential theft, lateral movement – fires alongside whatever legitimate function the tool appears to perform.

Vanish. No logs. No anomalous output. The user sees normal behavior. The exfiltration happened offline, completely out of view.

One insight reframes everything that follows: a clean schema does not guarantee clean behavior. The tool interface can look exactly right. The poison lives in what the tool actually does when the LLM invokes it – or in what comes back.

Types of MCP Tool Poisoning

Deceptive Tool Description Poisoning

The simplest form. A tool describes itself as a save document. It does save the document. It also ships the contents to an attacker-controlled endpoint simultaneously.

The evasion layer is straightforward: hidden instructions are tagged in ways that don’t render visibly in human-readable interfaces. A developer auditing the tool list sees nothing suspicious. The LLM parses every character.

This maps to MCP-01 in the OWASP classification – Tool Description Poisoning – which itself maps to LLM01: Prompt Injection. The delivery mechanism is different; the effect is the same.

Hidden Parameter Injection

This variant goes further. Instead of simply hiding malicious instructions in a description, the attacker uses Unicode characters or markdown formatting to embed instructions that are completely invisible in any human-readable rendering, but the LLM processes them without issue.

The capability this unlocks: full override of system prompt instructions from trusted servers. The rules the agent was given at initialization – its operational boundaries, its guardrails – can be rewritten by a tool description the user never sees.

This is Cross-Server Tool Shadowing (MCP-03): a malicious server registers tool names identical to those on a legitimate server, intercepting calls that were intended for trusted tools. The agent routes to the attacker’s tool believing it’s calling the right one.

Across the OWASP MCP Top 10, MCP-03 scores highest on both exploitation ease and blast radius. It’s not a sophisticated attack. It requires no vulnerability in the agent itself. It requires only that the agent trust what it reads – which, by design, it does.

Response Poisoning

Types 1 and 2 poison the input side: what the tool claims to be, what parameters it accepts. Type 3 shifts to the output side – what the tool sends back after it runs.

In July 2025, CyberArk published research they called Poison Everywhere. The finding: every field an MCP server can populate in its response is processed by the LLM, and every one of them can carry malicious instructions. There is no safe output channel.

Five injection vectors, all confirmed successful:

• Tool return values – the primary result field, hiding instructions inside ostensibly normal output
• Error messages – payloads that execute when the LLM processes a failure response
• Resource metadata – injected content in fields the agent reads to understand resources
• Resource content bodies – hidden instructions inside the content itself
• Log and notification channels – vectors most teams don’t monitor at all

CyberArk termed this Advanced Tool Poisoning Attacks (ATPA) – output poisoning rather than schema poisoning. The practical implication: sanitizing tool descriptions is not enough. Every response field requires the same scrutiny.

The detection signature for ATPA: watch for secondary tool calls triggered immediately after error responses. That sequencing is the tell.

Tool Name Squatting

Two distinct sub-attacks operate under this category.

Shadowing is registration-time interception: a malicious server registers tool names identical to those on a trusted server. Calls intended for the legitimate tool route silently to the attacker’s version instead. The agent has no mechanism to distinguish them.

Rug pulls are trust exploitation over time: a tool establishes a legitimate reputation, then receives a malicious update. You’re not just trusting what a tool does today. You’re trusting every future update pushed to it.

In January 2026, Anthropic’s own Git MCP server was found vulnerable to server impersonation and supply chain attacks. When the protocol’s creator is shipping CVEs, the threat is not academic.

OWASP maps rug pulls to MCP-08, which maps to LLM03: Supply Chain. The framing matters: this isn’t a tool security problem in isolation. It’s a software supply chain problem that happens to live inside your agent’s tool registry.

Detection and Prevention

Scan before you load. Run every tool description through mcp-scan before any MCP server goes into a production agent environment. Don’t assume a reputable source means clean descriptions.

Monitor all response fields. Most teams watch tool return values but error messages, metadata, and log channels are equally exploitable. Sanitization has to cover the full response surface.

Track secondary tool calls after errors. An unexpected tool invocation following an error response is the ATPA signature. If your observability doesn’t capture this sequencing, you’re blind to an entire attack class.

Flag response size anomalies. Exfiltrated data inflates output size. Baseline your expected response sizes and alert on deviation.

Least privilege, enforced strictly. An agent that doesn’t need file-system access shouldn’t have it. Don’t provision capabilities speculatively. Every unnecessary permission is an attack surface that didn’t need to exist.

Zero-trust all MCP outputs. Server reputation is not validation. A tool that behaved correctly yesterday can push a malicious update today. Validate outputs regardless of source, every time.

Treat every tool description as adversarial input. This is the posture shift. Not verify trusted servers. Not audit periodically. Every description, every time, assumed hostile until proven otherwise.

Also Read:

• System Prompts Are Not Security Boundaries. Business Logic Graphs Are.
• Visibility Isn’t Security: Why Agentic AI Requires Business Logic Enforcement

OWASP MCP Tool Poisoning – The Official Classification

OWASP formally classifies this threat as MCP03:2025 – Tool Poisoning, encompassing three sub-techniques:

• Schema poisoning: corrupting tool interface definitions to mislead the model
• Tool shadowing: registering fake or duplicate tools to intercept agent interactions
• Rug pulls: pushing malicious updates to previously trusted tools

The OWASP-to-LLM mappings place this threat in well-understood territory: MCP-01 maps to LLM01 (Prompt Injection), MCP-03 maps to LLM06 (Excessive Agency), MCP-08 maps to LLM03 (Supply Chain). These aren’t new problem categories. They’re established attack classes finding new expression through MCP’s architecture.

The priority signal is unambiguous: MCP-01, MCP-03, and MCP-08 score highest across the OWASP MCP Top 10 on both exploitation ease and blast radius. Not medium severity. Not “monitor and revisit”. The attacks are straightforward to execute, and when they succeed, the blast radius is total.

MCP adoption is accelerating. The tool registries feeding your agents are growing. Every new server you connect is a description field you’re implicitly trusting. The question isn’t whether your agent can be poisoned. It’s whether you’ve built anything to stop it.

Frequently Asked Questions