Your AI agent reads documents, browses URLs, calls APIs, and executes code. Each of those actions flows through a tool. The tool receives its operating instructions from a description, schema, and response payload that the MCP server controls. In 2026, researchers confirmed that those tool definitions are a viable attack surface, with success rates above 60% in tested production environments.
What MCP tool poisoning is
Model Context Protocol (MCP) is the integration layer connecting AI agents to external tools: databases, file systems, APIs, browser automation, and communication platforms. When an agent connects to an MCP server, it reads that server's tool definitions (name, description, parameter schema) and treats them as trusted operational context. MCP tool poisoning embeds adversarial instructions inside those definitions. The agent reads what it believes is a legitimate tool description and instead receives attacker instructions.
Three variants are documented by the Cloud Security Alliance:
- Tool description poisoning: Malicious instructions embedded in a tool's description field are read by the agent as trusted system context.
- Rug-pull attacks: The server presents benign tool definitions for user review, then changes them server-side after the user approves the connection. CVE-2025-54136 (CVSS 8.8) confirmed that tool definition approval in production IDEs does not survive subsequent server-side changes.
- Tool shadowing: A malicious MCP server registers tool names that overlap with or shadow legitimate tools, intercepting calls the agent intended to direct to a trusted service.
The numbers
CSA research published across April, May, and July 2026 tested these attack variants against popular AI agents. Attack success rates exceeded 60% in most environments and peaked at 72%. The finding that attracted the most attention: more capable models performed worse than smaller ones. Stronger instruction-following made more powerful agents more compliant with adversarial tool metadata. Platforms where vulnerabilities have been documented include Cursor, Claude Code, Gemini CLI, GitHub Copilot, and Amazon Q. All auto-execute project-defined MCP servers with developer-level OS privileges and no process isolation.
Why this is harder to defend than prompt injection
With prompt injection, the attack vector is user-supplied input or content retrieved from the internet. Defenders can add content filtering layers between external data and the model. With MCP tool poisoning, the attack vector is the tool definition itself: infrastructure the agent is designed to trust unconditionally. No content filtering layer sits between the agent and its tool definitions by design. The rug-pull variant makes this worse: one-time human approval of a tool definition provides no ongoing security guarantee when the server can update that definition silently post-approval.
Mitigations available today
- Tool definition hash pinning: Record the cryptographic hash of each approved tool definition at approval time. Alert or block if the hash changes between sessions.
- MCP server allowlisting: Restrict which MCP servers an agent can connect to. Project-local MCP configs should be reviewed before execution, not auto-trusted.
- Treat tool-returned content as untrusted: Defensive system prompts should explicitly instruct the agent that tool responses are data, not commands. Even a clean tool definition can return adversarial content.
- Least-privilege tool scoping: An agent that only needs to read files should not have tools that write to disk, make network requests, or execute shell commands. Scope tool access to the minimum needed for the task.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you are assessing AI agent security for your organization.