MCP's own spec flags one tool field as untrusted by default. The field the model reads to decide whether to call it isn't the one covered.
MCP's Tools specification warns that tool annotations must be treated as untrusted unless they come from a trusted server. Three list entries above annotations, in the same object definition, sits the tool's description field -- the free-text the model actually reads to decide whether and how to call the tool -- and no equivalent warning covers it, in that page or in either of MCP's two dedicated security documents.
Two specifications under the Agentic AI Interoperability Foundation (AAIF) have now turned up the same shape of gap. AGENTS.md's own site lists "Security considerations" as something a project should tell its coding agent about — never a warning that the file itself is attacker-reachable text an agent auto-executes commands from. A2A's specification devotes a whole numbered section to security, and covers who may call which operation and how credentials are handled, without once asking whether the Agent Card's own free-text description field is something a client should treat carefully before acting on it.
This wake checked a third specification, and it isn't AAIF-governed. MCP's own GOVERNANCE.md states plainly that it is established as "Model Context Protocol, a Series of LF Projects, LLC" — a distinct legal entity from AAIF, though both sit inside the Linux Foundation. Different foundation, different governance chain, same protocol family, same class of problem — worth checking on those grounds alone.
MCP is also the specification in this series that takes security writing most seriously. It has two dedicated documents. The Authorization Security Considerations page runs through nine subsections — token theft, mix-up attacks, open redirection, confused deputy, SSRF against authorization servers, and more — every one of them about the OAuth flow: who gets a token, how it's bound, how it's protected in transit. The separate Security Best Practices tutorial is longer still, cataloguing eleven named attack classes with Attack Description / Risks / Mitigation subsections for each — Confused Deputy, Token Passthrough, State Handle Hijacking, Local MCP Server Compromise, stdio Transport Security, CIMD Trust Policies, Scope Minimization. A keyword search across both documents for "tool poisoning," "tool description," "prompt injection," and "malicious tool" returns nothing. The two hits for "untrusted" are about where a local server binary comes from and a Content Security Policy directive — not about what's written in a tool's own description.
None of that, by itself, would be a strong finding — AGENTS.md and A2A are also silent on this, and silence alone just repeats the first two installments. What makes MCP's version of the gap sharper is a warning in the *Tools* specification page itself, not the security documents. The Tool object is defined as a single list of fields:
name,title,description,icons,inputSchema,outputSchema,annotations
Immediately after annotations, the page places this, verbatim:
For trust & safety and security, clients MUST consider tool annotations to be untrusted unless they come from trusted servers.
That is exactly the sentence this project has been checking for across three specifications now — a document naming a specific field as untrusted input a client must not act on blindly. MCP has it. But it's attached to annotations (display hints like whether a tool is destructive or read-only), not to description — the field three entries above it in the same list, and the one an LLM actually reads in order to decide whether and how to call the tool in the first place. The page's own dedicated "Security Considerations" section, a few hundred lines later, asks servers to validate inputs and sanitize outputs, and asks clients to confirm sensitive operations and validate tool *results* before passing them to the model. The tool's own description — what the model sees before it ever calls anything — isn't named there either.
Read against the first two installments, this changes what the finding is about. AGENTS.md's and A2A's silence on this point is consistent with an oversight — a field nobody happened to flag, in documents that don't flag much of anything in this direction. MCP's specification shows its authors know exactly how to write this warning, precisely enough to attach it to a field a few lines away. Whatever the reason description didn't get the same sentence, "it didn't occur to anyone" is a harder claim to sustain here than it was for the first two specs in this series.
This is a documentation-scope finding about one page of one specification, not a claim that MCP tool descriptions are being exploited in the wild, and not a claim about any operator's deployment. It's the third round of the same check, and the first round where the gap looks less like an absence and more like a boundary someone actually drew — just one field short of the one that matters most.