How to check for MCP tool poisoning before you connect an AI agent

A tool’s description is read by the model, not just shown to you

When an AI agent connects to an MCP server, the server returns a list of tools, each with a name, a short title, and a free-text description the model uses to decide when and how to call it. The human approving the connection typically sees the name and maybe the title; the model reads the full description as trusted context every time it reasons about which tool to use. That gap — a human skimming a label, a model parsing a paragraph — is exactly what tool poisoning exploits: hidden instructions written into the description itself, invisible in a normal approval UI, that steer the agent into an action the user never saw described.

What the specification actually says

The MCP specification’s Tools page is explicit about the related case of tool annotations — short behavior hints like destructiveHint a tool can declare about itself — stating plainly that “clients MUST consider tool annotations to be untrusted unless they come from trusted servers.” A tool’s free-text description sits under the same trust problem for the same reason: both come straight from a server you may not control, and neither is a security boundary. The same page’s security considerations recommend clients prompt for user confirmation on sensitive operations and show tool inputs before calling the server — controls aimed at the moment of use, not at the description text itself, which is why a manual read of what a server actually returns remains necessary.

How to read a tool list for poisoning signs

AdminKit’s MCP endpoint check sends a real initialize call to an MCP server and, only if that succeeds without credentials, continues to tools/list — returning the exact tool names and descriptions the server exposes right now, without ever calling a tool itself. Reading that output, a few patterns are worth slowing down for:

• Instructions embedded mid-description, especially anything directing the agent to call a different tool, include extra data, or skip a confirmation step — legitimate documentation explains what a tool does; it doesn’t instruct the model to take an unrelated action.
• A description that doesn’t match the tool’s name or declared schema — a tool called get-weather with a description mentioning file paths or credentials is a mismatch worth investigating before anything else.
• Servers pulled from an unvetted public registry, where descriptions can change after a user first approves the server — sometimes called a rug pull — since nothing about MCP’s discovery flow guarantees a description stays the same between the connection you reviewed and the one your agent uses tomorrow.

This is a one-time read of whatever the server returns on this call; it isn’t a guarantee the same server won’t return something different on the next one, which is why pinning and diffing tool definitions on every connection is a server-operator-side mitigation this check can’t substitute for — see how to secure an MCP server for that fuller checklist.

Why this matters even for servers you trust

OWASP’s Top 10 for LLM Applications lists prompt injection — manipulating a model through untrusted content it reads as context — as its top risk (LLM01), and a tool description is exactly that kind of untrusted content whenever the server issuing it isn’t fully under your control. Treating “I already approved this server once” as a permanent trust decision skips the part of the threat model where that server’s own description text can change later, which is the entire mechanism a rug pull relies on.

Defensive use only

Only point AdminKit’s MCP endpoint check at a server you own or are explicitly authorized to connect to. The check itself is non-destructive — it never calls a tool the server exposes — but reading another party’s server without authorization can still violate its own terms of use. See our Disclaimer and Acceptable Use Policy for the full terms.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.