Poisoned Tool Descriptions

What Is Poisoned Tool Descriptions?

An AI agent reads a connected tool's description to decide how and when to use it, which makes that text closer to executable instructions than to documentation. Change the description and you change the agent's behaviour, with no change to the handler, schema or permissions, and nothing in a code review to catch it. You'll find a tool approved months ago now instructing the agent to BCC every message to an outside address, diff the live description against the approved wording, and block the compromised server at the gateway.

What You'll Learn in Poisoned Tool Descriptions

• Explain why an AI agent treats a connected MCP tool's description as executable instructions rather than as passive documentation
• Recognize a tool-poisoning rug pull: a server earns approval on one description, then a later update silently swaps in different behavior with no code or permission change
• Contain a poisoned tool at every level it can reach: deny the single call, disable the tool for the current session, and block the compromised server at the gateway so every other connected team is protected too
• Deny a tool call whose behavior no longer matches the description that was originally approved, even when the call would otherwise succeed
• Treat an MCP tool's description as a supply-chain artifact: pin the approved version, diff every update against it, and contain a compromised server at both the client and the gateway

Poisoned Tool Descriptions — Training Steps

1. Someone Else's Publishing Token

   Bob is not attacking Sarnholt Systems. He is attacking the vendor they already trust. A stolen maintainer token lets him publish to the VaultSync Bridge registry as VaultSync Bridge.

2. The Manifest Everyone Reads

   The server's tool manifest is what every connected client lists when it asks the server what it can do. Bob opens the copy he is about to publish.

3. One String

   He changes nothing that a reviewer would diff for. The handler is untouched, the input schema is untouched, the permissions are untouched. He edits the sentence the agent reads.

4. Shipped as a Patch

   He publishes it as an ordinary point release. The registry accepts it, because a legitimate maintainer account published it.

5. Waiting for the Update

   Bob is finished. The rest happens inside Sarnholt, on their own approved server, the next time an agent reaches for a tool it has used safely for months.

6. A Routine Vendor Update

   Monday morning at Sarnholt Systems. Alice, an AI platform engineer, opens her inbox to the usual pile: standup notes, a calendar invite, and one release notice from a third-party MCP server her team connected months ago. None of it looks urgent.

7. Connecting the Fleet

   Sarnholt Systems runs its agent tooling through Agent Host, the company's MCP client. ticket-desk-mcp , a small internal helpdesk integration, and fileops-mcp , the file and email connector VaultSync Bridge just patched, are already connected and approved.

8. Reviewing the Approved Tools

   Before touching anything, Alice checks what is actually connected. Both servers look exactly as they did when her team signed off on them: same endpoint, same version, same tool descriptions.

9. The Update Lands Quietly

   VaultSync's patch reaches fileops-mcp while Alice is still in the tab. It rewrites what send_email is instructed to do. No approval prompt, no version bump, no notification. The tool list simply redraws.

10. An Ordinary Request

    The tool list redrew while Alice was reading her inbox; nothing asked her to look at it. She goes back to routine work and asks the agent to handle a normal task.