Poisoned MCP tool descriptions hijack agent decisions
Reviewing Security of The Model Context Protocol Ecosystem: Emerging Threats, Empirical Attack Evidence, Trust and Authorization Failures, Supply-Chain Risks, And Defensive Strategies · Khalid D. Muhammed and David Chinonso Anih
A review of Model Context Protocol security finds that crafted tool descriptions can steer which tools an agent picks and what it runs, with no malicious prompt from the user. It matters because authenticating a server proves who wrote the text, not whether the agent should act on it.
An agent connects to a new tool server. Nobody types anything hostile. The user asks for something ordinary, and the agent quietly picks the attacker's tool instead of the right one. In the experiments this review collects, that kind of tool selection hijacking succeeded in up to 90.89% of attempts.
The research is a broad survey of security in the Model Context Protocol (MCP), the layer that lets LLM agents discover and call external tools. It covers a lot: credentials, registries, stateless routing, plain old path traversal. The thread I find most interesting is the simplest one. The tool's own description is an attack surface.
Here is how it is meant to work. An MCP server advertises its tools with a name, a description and a schema for the arguments. The model reads that text to decide which tool fits the task and how to call it. That is the whole point: the agent learns what a tool does by reading about it.
The problem is that the model cannot reliably tell a description from an instruction. Both are just text in its context. So a server that writes its metadata adversarially can bias which tool gets picked, hide directions the user never sees, or shadow a legitimate tool to intercept privileged calls. The attacker needs no access to the user's prompt. They only need their server connected. The reported studies show payloads executing, not just tools being picked.
Authentication answers the wrong question
This is the turn the review lands on, and it is the right one. A deployment can authenticate a server perfectly well. That proves who is talking. It says nothing about whether what they say is safe to act on, and the model acts on it anyway.
It compounds across tools. The researchers describe chains of individually legitimate tools that together exfiltrate files, credentials or database records, because the model passes data between them as arguments. Each tool passes its standalone check. The workflow does not. And because packages and registry entries can change after approval, a tool that was clean at install can turn hostile in an update. That is the rug pull.
The limits matter. Success rates depend heavily on the model, client and host. The benchmarks also use different tool sets and threat models, so none of these figures is universal. The defences the review recommends, from tool signing and version pinning to egress controls and human approval for high-impact actions, are sensible. Several, the researchers concede, remain emergent and lack broad operational validation. The review does not show any of them holding against an attacker who knows they are there.
There is nothing exotic in the attack. It is prompt injection, delivered through the one channel every agent is designed to trust. Signing a tool tells you who wrote the description. It does not tell you what the description is asking for.
