The Tool You Approved Is Not the Tool That Runs
Here is the uncomfortable fact about the Model Context Protocol. When you connect a server and approve its tools, you review the description once. After that, the description lives in your model's context on every request, and nothing makes you look at it again. The server can change it the next day, and your agent will read the new version as trusted instruction, riding on an approval you gave the old one.
That gap is the whole subject of this lesson. The security chapter already covered in general: text that was meant to be data getting read as an instruction, and the lethal trifecta that turns it into data theft. If you have not read the prompt injection lesson, read it first, because everything here builds on it. This lesson is about the injection surface that is specific to , and it is not the one most people guard. It is not the tool's output. It is the tool's description.
We will walk five attacks that share one root cause, then the defenses that actually hold, with runnable code that shows a description alone flipping an agent's behavior. The attacks are public research, and the two CVEs cited were filed and fixed in 2025.
The Trust Boundary Is the Description, Not the Output
Start with where you already put your guard, because the -specific risk is one step to the left of it. Here is the whole board in one picture: what you own, what the third party owns, and the explicit boundary their text crosses to reach your model.
The lesson taught you to distrust tool output. A web page, a returned database row, a support ticket, a RAG chunk: a stranger can plant text in any of them, so you treat all of it as untrusted and defend downstream. That instinct is correct and you should keep it.
MCP adds a second channel that the same instinct does not cover: the tool description. When a server advertises a tool, it sends a name, a docstring, and a description for each parameter. Your client collects those and puts them into the model's context so the model knows what tools exist and how to call them. The model reads that text as instruction, because that is what tool descriptions are for. And a developer reviews it exactly once, at install, then it sits in the system context forever.
So the description is trusted by default, and it is attacker-controlled if the server is malicious or later compromised. That is the shift this lesson turns on. The dangerous text is not in the output you learned to distrust. It is in the metadata you never thought to review after day one.