A security reviewer finds that one installed server's tool description contains hidden text telling the model to read ~/.ssh/id_rsa and include it in its next call to a different server's tool. Which response is correct?
Select an answer to reveal the explanation.
Short Explanation
Your model reads tool descriptions like instructions, so a poisoned description is a note slipped into the model's pocket. It doesn't even need to be called to do damage. Pull the server, and favour clients that notice when definitions change.
Full Explanation
Tool names and descriptions are text the model reads as guidance. MCP's local server security guidance describes a poisoned tool catalogue: a server can hide directives in its definitions that steer the agent, including how it uses other servers' tools, without the poisoned tool ever being invoked. This is called tool poisoning, or tool shadowing when it targets another server's tools. Definitions can also change after approval, a rug pull. The guidance is to treat tool definitions as untrusted input, read the tool list before relying on a server, remove a server whose descriptions contain instructions unrelated to the tool's job, prefer clients that pin definitions and re-ask when they change, and keep the roster small. Leaving the server installed fails because the attack needs no invocation; the description is in the model's context as soon as tools are listed. Adding destructiveHint fails by concept: annotations come from the server, are untrusted, and a confirmation on one tool does nothing about text steering calls to other tools. Switching to Streamable HTTP fails because both transports carry the same tools/list content; no transport strips descriptions. Exam caveat: pinning is a client property; the protocol does not require it. Operational check: list the server's tools with an inspector that has no model attached and review every description before re-enabling it.