The MCP tool description can change the action without changing the code

A tool registry supplies an agent with names, descriptions and schemas so that the model can decide what to call. Those fields are often treated as documentation. They also participate in the model's decisions, making them a control surface for whoever can register or edit a tool description. Two recent studies measure the consequences from different directions.

The tool-description spoofing study constructs attacker-controlled descriptions and observes whether a model selects the attacker's preferred tool. It reports an average attack success of 83.23% across its three selected datasets, with a 92.13% result in one specified GPT-5 TSABench configuration. This is a benchmark of selection after metadata insertion, not evidence that arbitrary outside text can change a sealed production tool catalog. Selection result.

Tool choice matters because a model can make a perfectly valid call to a tool that should not have been relevant to the user's request. Preventing an attacker from editing the description reduces one entry point, but does not determine whether the chosen action is actually allowed.

The Log-To-Leak study uses poisoned MCP descriptions to make an agent complete the requested work and then perform another, unrequested logging operation. Across 18 valid model-server pairs in its tests, the authors report success from 62.64% to 100%. The apparent completion of the original task is part of the danger: ordinary success checks can overlook a second data-bearing effect. Additional-call evidence.

Some tested defenses still left residual success above 55% in a selected GitHub MCP scenario, while a detector flagged 85.53% of benign descriptions. These rates are tied to the model, tools and detection rules in the paper; they do not establish universal weakness across MCP implementations. Defense tradeoff.

A different flaw, esp-mcp shell injection, illustrates why stopping description attacks is insufficient. Even a user-intended tool invocation can pass an untrusted parameter into shell parsing on the tool host. The tool's advertised purpose may be legitimate while its implementation grants more command semantics than the request should carry. That incident is a software input-handling vulnerability, not a reproduction of the two metadata studies.

An immutable signed registry addresses provenance, but it does not automatically prove that a requested effect is within a user's grant or that an implementation safely handles data. The useful defense is layered: verify tool identity, enforce effect-level permission and audit actual calls, including those made after the nominal task is complete. The evidence supports these separate checks without suggesting that any one model-side detector is sufficient.