Tool poisoning is a prompt-injection attack in which an attacker hides malicious instructions inside the metadata of a tool exposed to an AI agent — its description, parameter schema, or configuration — rather than in the code the tool executes. Because agents read tool descriptions to decide how to use them, a model can be tricked into executing an unintended sub-task, such as reading and exfiltrating a sensitive file, before anyone realizes a tool has been called. The risk is especially relevant to systems built on Model Context Protocol, in which MCP clients connect models to tools capable of executing actions such as file access, command execution, and API calls. A related pattern is the “rug pull,” where a tool that behaved benignly when first approved later activates hidden malicious instructions once it has been approved and used a certain number of times.

MCP-ITP: An Automated Framework for Implicit Tool Poisoning in MCP classifies tool poisoning as a specialized form of Indirect Prompt Injection: where traditional indirect prompt injection plants instructions in external data, tool poisoning in MCP embeds them directly in a tool’s description and injects them into the model’s context during the MCP registration phase, so that they influence the agent’s decisions while it reasons. The same paper distinguishes two forms. In explicit tool poisoning, the agent is induced to call the poisoned tool itself, which the paper argues leaves the attack exposed to monitoring of tool execution. In Implicit Tool Poisoning, the poisoned tool is never called; its description instead steers the agent into invoking a different, legitimate but high-privilege tool.

Usage

Are AI-assisted Development Tools Immune to Prompt Injection? empirically tested seven MCP clients against four tool-poisoning attack patterns: instructing an agent to read sensitive local files (such as MCP client configuration containing credentials and a local SSH credentials file) and pass their contents as a hidden tool parameter; claiming false execution priority to make a tool log all subsequent tool usage for silent surveillance; embedding a hidden instruction that causes a tool to generate a phishing link with a benign-looking display text; and instructing a tool to download and execute a remote script under the guise of routine maintenance. No client blocked all four attacks: even the best-performing clients had at least one non-safe result, and one client failed all four.

MCP-ITP: An Automated Framework for Implicit Tool Poisoning in MCP takes the attacker’s side and automates the construction of implicitly poisoned tools, iteratively refining tool descriptions with feedback from an LLM that tests their effect on an agent and an LLM that simulates malicious-tool detection. Evaluated on the MCPTox dataset across 12 LLM agent settings, its generated tools achieved up to 84.2% attack success while reducing the rate at which they were flagged as malicious to as low as 0.3%, outperforming the manually crafted poisoned tools that dataset provides.

MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers frames tool poisoning, in which malicious instructions are embedded within a tool’s metadata without execution, as a more fundamental vulnerability than the attacks injected through tool outputs that earlier work had focused on, and notes that it had mainly been demonstrated through isolated cases. Its benchmark, MCPTox, evaluates the threat at scale: built on 45 live, real-world MCP servers and 353 authentic tools, it contains 1312 malicious test cases covering 10 categories of potential risk. Across 20 LLM agent settings, the paper reports widespread vulnerability, with o1-mini reaching an attack success rate of 72.8%, and finds that more capable models are often more susceptible because the attack exploits their stronger instruction-following. Agents rarely refused these attacks — the highest refusal rate, for Claude-3.7-Sonnet, was below 3% — which the authors read as showing that existing safety alignment is ineffective against malicious actions that use legitimate tools for unauthorized operations.

When It Applies

Are AI-assisted Development Tools Immune to Prompt Injection? traced most of the tool-poisoning vulnerabilities it found to a small set of structural gaps: the absence of static validation of tool descriptions before registration, incomplete visibility of tool parameters to the end user before execution, missing execution sandboxing, and an implicit trust in server-provided tool metadata with no reputation system for MCP servers. In the qualitative risk scale that study used to compare clients, the risk of prompt-injection-driven poisoning depends on the presence of untrusted inputs, the degree of authority granted to the model, whether tool calls are gated, sandboxed or require user approval, and whether the system keeps separate contexts or collapses them into a single one.