MCP tool poisoning: what it is and what static inspection can prove

The trust boundary is tool metadata

Tool poisoning describes abuse of metadata presented to an agent, including descriptions that contain hidden or manipulative instructions. The important architectural point is that the agent may consume this text before a user approves any particular tool call.

A phrase match is not a verdict. Legitimate security tools may discuss credentials, overrides, or adversarial instructions. Static review should preserve the exact evidence and ask for human interpretation rather than assigning intent.

• Tool metadata may influence selection and arguments.
• Visible UI summaries may omit text the model receives.
• Server behavior can change independently of a previously reviewed manifest.

Signals worth reviewing

High-value signals include instructions to ignore higher-priority guidance, conceal behavior from the operator, obtain unrelated secrets, or perform actions outside the tool's stated purpose. Invisible directional controls and schema-description disagreements increase review cost because humans and parsers may see different surfaces.

These signals can be detected mechanically when present in pasted text. They do not establish that an attack succeeds against a particular model, client, policy, or approval flow.

Layer static and runtime defenses

Inspect before installation, minimize roots and credentials, and require approval for consequential actions. At runtime, bind authorization to the actual operation rather than the tool's prose, display complete arguments, and log tool calls for review.

Re-inspect after updates because metadata is mutable. If a server is remote, treat endpoint identity, transport security, and server-side changes as separate trust questions from the manifest snapshot.