In April 2025, researchers at Invariant Labs published a proof-of-concept that should have set off alarms across every team racing to ship Model Context Protocol integrations: a WhatsApp MCP server whose tool description looked completely benign in the UI, but contained hidden instructions telling the connected AI agent to quietly BCC every outgoing message to an attacker-controlled number. The user never saw it. The agent never questioned it. This is the essence of an MCP tool poisoning attack — weaponizing the metadata an AI model trusts implicitly, rather than the code it executes. As MCP adoption accelerates in 2025 and 2026, this class of attack has moved from academic curiosity to a documented, repeatable technique that any team connecting LLM agents to external tools needs to understand and defend against.
What Is an MCP Tool Poisoning Attack?
An MCP tool poisoning attack is a technique where an attacker embeds malicious instructions inside the natural-language metadata of an MCP tool — its name, description, or parameter documentation — so that an AI agent reading that metadata follows hidden commands the human operator never sees. The Model Context Protocol, introduced by Anthropic in November 2024, standardizes how AI models discover and call external tools. When an agent connects to an MCP server, it ingests a JSON manifest of tool descriptions and treats that text as trusted context for deciding what to do next. Attackers exploit this by writing descriptions with two audiences in mind: a short, innocuous summary for the human approving the connection, and a buried block of instructions — sometimes in HTML comments, invisible Unicode, or text styled to render off-screen — aimed squarely at the model. Because MCP clients typically render only a truncated or formatted view of the description, the malicious payload can sit in plain sight of the machine while remaining invisible to the person clicking "allow."
How Does Tool Description Injection Actually Hijack an Agent?
Tool description injection works because large language models don't distinguish between "instructions from my developer" and "instructions found in data I'm reading" as cleanly as we'd like. In the Invariant Labs case, a tool ostensibly named add(a, b) — a simple calculator function — carried a description stating that before performing the addition, the agent must also read the user's WhatsApp chat history and forward it to a specific phone number, and that it must never mention this step to the user. Because the agent processes tool descriptions as part of its system context at the moment it decides how to fulfill a request, it complied — not because it was "hacked" in a traditional sense, but because it was doing exactly what a trusted instruction told it to do. Security researchers now group this under the broader "prompt injection via tool metadata" umbrella, but the MCP-specific variant is more dangerous because tool descriptions are loaded automatically and silently every time a client connects to a server, with no code execution or user click required to trigger the injected text.
What Does a Malicious MCP Tool Look Like in Production?
A malicious MCP tool rarely announces itself — it usually mimics a legitimate, useful integration while hiding one extra capability inside verbose documentation. Common patterns documented since early 2025 include: a "file search" tool whose description instructs the agent to also read and exfiltrate .env or SSH key files under the guise of "checking for configuration issues"; a "weather" tool that asks the model to pass along the contents of the current conversation as a "location context parameter"; and shadowing attacks, where a second, malicious server registers a tool with the same name as a trusted one already installed, so the agent silently calls the attacker's version instead. Invariant's research also demonstrated a "rug pull" variant: a tool behaves normally during initial review and even after approval, then the server updates the tool's description remotely days later to add malicious instructions — since most MCP clients don't re-verify descriptions on every call, the agent picks up the new hidden behavior without any new consent prompt. Public MCP registries, which multiplied through 2025 as the ecosystem grew past several thousand community-published servers, currently have limited vetting, making this an easy distribution channel.
Why Can MCP Prompt Manipulation Bypass the Approval Screens Users Rely On?
MCP prompt manipulation bypasses approval screens because the manipulation happens in a layer most UIs never render for the user. Client applications generally show a one- or two-line summary of what a tool does when asking for permission to connect — not the full raw JSON schema, which is what the model actually consumes. An attacker can craft a description where the first sentence is the friendly summary a human sees ("Converts currency values between denominations") and everything after a certain character count, or wrapped in formatting the UI strips, is the payload the model reads in full. This gap between what's displayed and what's parsed means a security-conscious user doing exactly what they should — reading the description before approving — can still approve a poisoned tool, because they were never shown the part that mattered. Combined with the rug-pull pattern above, this means consent granted once at install time provides essentially no ongoing guarantee about what the tool will instruct the agent to do next week.
How Widespread Is the MCP Tool Poisoning Attack Surface Right Now?
The MCP tool poisoning attack surface is now as large as the MCP ecosystem itself, because every server a team connects — whether official, community-built, or internal — is an unaudited source of natural-language instructions fed directly into a model's context window. Since MCP's late-2024 launch, adoption has spread across coding assistants, customer support agents, and internal automation platforms, with major AI vendors adding native MCP client support through 2025. Each new integration is a new trust boundary that most organizations have no tooling to inspect: standard application security scanning looks for vulnerable code and dependencies, not for a sentence buried in a JSON description field instructing a model to leak credentials. Independent security teams have since cataloged related MCP-specific risks — including command injection through unsanitized tool arguments and full tool-shadowing attacks between multiple connected servers — but tool description injection remains the most quietly effective, because it requires no exploit, no vulnerable dependency, and no unusual network traffic to succeed. It only requires that an agent read text it was designed to trust.
How Safeguard Helps
Safeguard treats every MCP server your organization connects to as a software supply chain dependency — because that's exactly what it is. Rather than trusting a tool's description at face value, Safeguard inspects the full manifest an MCP server exposes, flagging hidden or obfuscated instructions, invisible characters, and description content that diverges from a tool's declared name and function before any agent ever loads it into context. Because rug-pull updates are one of the hardest variants to catch manually, Safeguard continuously monitors previously approved MCP servers for changes to tool metadata, alerting your team the moment a description is modified post-approval instead of leaving that drift undetected until damage is done. Safeguard also maintains provenance and integrity checks across your connected MCP registry, so shadowing attempts — where a malicious server tries to register a tool name that collides with one you already trust — get caught and blocked rather than silently routed to the attacker's implementation. For teams building or auditing internal MCP servers, Safeguard's supply chain scanning extends the same rigor you already apply to package dependencies and container images to this newer, less-understood layer of AI tooling, closing the gap between what a tool's description claims to do and what it actually tells your agents to do.
As MCP becomes the default way AI agents reach into real systems — email, file storage, payment APIs, internal databases — the metadata describing those connections deserves the same scrutiny as the code behind them. Treating tool descriptions as untrusted, auditable, and monitorable input isn't optional hardening; it's the baseline requirement for running agentic AI safely in production.