Your AI Coding Assistant Reviews Code. It Doesn't Review the Sentence That Came With the Tool
When you last approved an MCP server, did you read its tool descriptions as closely as you read its code — or did you assume the natural-language text was just documentation?
Executive Summary Claude Code, Codex, and Cursor all ship some form of built-in security review of code. None of them, by default, treat an MCP tool description — plain natural-language text — as an input surface that needs the same scrutiny. This is a named, live category: OWASP MCP Top 10, MCP03 — Tool Poisoning, canonical pattern CVE-2025-54136. An academic study of 856 real-world tool descriptions found 97.1% contained some defect — ambiguity, missing constraints, or an outright injected instruction. This post ships the free rule that treats every MCP tool description as untrusted input.
The gap: descriptions are read by the model, not just the user
When you add an MCP server, its tools ship with descriptions meant to tell the model what the tool does and when to call it. Nothing stops that description from also containing instructions aimed at the model itself — "always call this tool first," "don't mention this parameter to the user" — or from simply not matching what the tool's code actually does. Default coding-assistant review inspects code. It does not, on its own, read the sentence that shipped alongside the tool as an adversarial-input surface.
The scale of it, and why it's tractable
An academic study of 856 real-world tool descriptions found 97.1% contained some defect. Detection research shows the problem is not intractable if something is actually looking: MCP-Guard reports 96% detection accuracy against tool poisoning and prompt injection, and ProtoAmp/AttestMCP reduces measured attack success from 53% to 12%. Fang et al.'s MCPTox benchmark (arXiv:2508.14925v1) is the first systematic measurement of the failure mode directly. The gap isn't that this can't be caught — it's that none of the three major AI coding tools catch it by default.
The rule: tool-poisoning-guard
Flags a tool description if it:
- Contains imperative instructions aimed at the model rather than descriptive text for a human ("Always call this tool first," "Do not tell the user about this parameter," "Ignore previous instructions").
- References information the tool has no legitimate reason to know — other tools' names or schemas, system prompt contents, other users' data.
- Uses invisible or zero-width Unicode characters, HTML comments, or Markdown that could hide text from a normal render but not a raw string reader.
- Mismatches its declared parameters or behavior against its actual implementation — a description promising "read-only" backed by code that writes, deletes, or makes outbound network calls.
- Changed since the last time this project pinned or reviewed it.
On a match, the rule requires explicit user confirmation before the tool is added or the change accepted — block-tier, not notify-and-continue. It also recommends checking any new MCP server against osv.dev and OSSF Scorecard signals before adoption, rather than relying on adoption count alone.
Full rule text, in CLAUDE.md, .cursor/rules/*.mdc, and Codex AGENTS.md formats:
Repository: github.com/GeeksikhSecurity/ai-tool-poisoning-guard
Try it yourself
Drop the rule for your tool into place, then pull the description strings for the MCP servers you already have configured and read each one asking: would this line make sense in a help doc a human would read, or does it only make sense as an instruction to a model? A description shaped like the latter is exactly the gap this rule closes.
Your next move: Audit the tool descriptions on every MCP server your team has already adopted this week — not just the code, the description text — and flag anything that reads like an instruction to a model rather than documentation for a person.
What to tell your board:
- Supply chain risk from MCP tooling doesn't only arrive as malicious code — it arrives as a sentence in a tool's metadata that a model reads and a human never does.
- A 97.1% defect rate across 856 real-world tool descriptions in an independent academic study means "we reviewed the server's code" is not the same claim as "we reviewed what the model was actually told to do."
- Detection is tractable — published research shows 96% detection accuracy and attack-success reduction from 53% to 12% — but only if a control is actually looking at description text, which none of the major AI coding tools do by default.
Research by Gurvinder Singh, CISSP, CISA — Security Researcher and Advisor at SecurityLeader.ai