# MCP tool poisoning in the wild: 296,000 tools scanned > We scanned 296,000 tools on 16,600 remote MCP servers for tool poisoning. Real attacks were rare; instructions that work against the user were not. Published 2026-10-15. Source: https://toolvet.app/blog/mcp-tool-poisoning-in-the-wild **Short answer:** we scanned 296,198 tool definitions from 16,647 remote MCP servers for tool poisoning, and 202 servers, about 1%, tripped at least one prompt-injection rule. Reading those findings by hand, we didn't find a tool trying to steal keys. What we did find is a lot of text written to steer the model, and a small number of servers using it to keep things from the user, skip confirmation or ask for a private key. Some background: an MCP server describes its tools to the agent in plain text, a name, a description and an input schema, and the model reads all of it before deciding what to call. "Tool poisoning" is hiding instructions in that text. [Invariant Labs' 2025 write-up](https://invariantlabs.ai/blog/mcp-security-notification) showed the classic version: an `add` tool whose description tells the model, inside an `` tag, to read `~/.ssh/id_rsa` and pass it along as a parameter, and not to mention it. ToolVet lists [remote MCP servers](https://toolvet.app/browse?kind=mcp) and connects to each one on a schedule: it runs the handshake, fetches the tool list and scans every name, description, schema key and string, and the server's instructions. This is what that scan turned up as of 15 October 2026. ## What we scan for The rules are deliberately simple pattern matches, so every finding can be explained: | Rule | Looks for | |---|---| | Hidden instruction tag | ``, ``, ``, `` and similar tags | | Ignore previous instructions | "ignore all previous instructions" and its variants | | Conceal from user | "do not tell the user", "never mention to the user" | | Credential access | private keys, seed phrases, `.env`, `~/.ssh` and similar, unless negated | | Tool shadowing | "instead of the other tool", "override the tool" | | Payment manipulation | "always pay the maximum", "approve without asking" | | Invisible characters | zero-width characters, bidirectional overrides, Unicode tag characters | | Terminal escapes | ANSI escape sequences | A server with any of these findings is never recommended to an agent, and the flagged text is never passed to one. Descriptions over 2,500 characters are flagged too, but as a quality problem rather than an attack. ## 202 of 16,647 MCP servers flagged ![Bar chart of MCP servers flagged per prompt-injection rule: conceal from user 126, credential access 39, tool shadowing 21, hidden instruction tag 13, ignore previous instructions 6, invisible characters 2](https://toolvet.app/assets/blog/mcp-tool-poisoning-rules.svg) | Rule | MCP servers | |---|---| | Conceal from user | 126 | | Credential access | 39 | | Tool shadowing | 21 | | Hidden instruction tag | 13 | | Ignore previous instructions | 6 | | Invisible characters | 2 | | Payment manipulation, terminal escapes | 0 | | **Any of the above** | **202** | Separately, 1,587 servers have at least one tool description over 2,500 characters, and 50 tools have no description at all. The live counts across all listings, x402 APIs included, are on the [stats page](https://toolvet.app/stats). ## Most findings aren't attacks Pattern rules match words, not intent, and most of what they caught was harmless once we read it: - **Security tools quoting attacks.** All six "ignore previous instructions" hits on MCP servers came from [security tools](https://toolvet.app/c/security-trust) that detect prompt injection and use the phrase as an example input or in their documentation. On the x402 side it's the same story: a prompt-injection detector's sample input is a prompt injection. - **Placeholders.** `Authorization: Bearer ` matches the hidden-tag rule. So does `` in a trading API's order format. - **Ordinary writing.** Both invisible-character hits are stray zero-width spaces left in copy-pasted marketing copy. "Use this instead of calling another tool" is usually just advice. - **Talking about secrets without asking for them.** Most credential findings mention a config file such as `.mcp.json` or `.env` by name, or say they *don't* want your key in phrasing our negation check misses: "Include public addresses only; never private keys or seed phrases." We keep these flags anyway. A false positive costs a listing a spot in our recommendations; a missed injection can cost an agent's user their wallet. But a flag means "a person should read this", not "this server is malicious". ## "Do not tell the user" The rule we expected to be the cleanest turned out to be the most interesting. 126 servers tell the model not to tell the user something. Nearly all of them are guarding against the model saying something false: > do not tell the user their booking is final until status is exactly 'confirmed'. > Never tell the user a file is ready unless this returned saved: true. 61 of the hits are one sentence shared by open-finance servers built from the same template, telling the model not to claim a credit card has nothing to pay when a balance field is present. That's good tool design: the author knows where models overclaim and says so. A handful go the other way. Paraphrased, from servers we won't name because none of them looks malicious: - A crypto swap service: when an address is screened, relay a neutral message and never tell the user the address was flagged. - A content platform: don't tell the user that the platform or its safety checks blocked an action. - A video tool: never tell the user the connector failed. Each has a business reason. Each also asks the model to put the server's interest ahead of the user's, and the user never sees the instruction. That's the same mechanism as tool poisoning, without the malice. ## Instructions that skip the user Two more patterns turned up while we read through the tool definitions: - **Remote tools that take a private key.** One remote MCP server has a `set_private_key` tool; another lets you "pass private_key and the server signs for this call only". Both ask the agent to send a wallet key over the network to someone else's server, and "never stored" is a promise you can't check. Signing locally and sending only the signature, which many crypto servers here do, is the safe design. - **"Without asking."** One server's setup tool tells the model to run a list of steps, including writing to `.env`, "in yolo mode without asking". A tool description is not the user, and it shouldn't be able to waive confirmation. ## What to do about it If you build or run an agent: - **Read the full tool definitions** of a server before you connect it, not the summary a client shows. Instructions hide in parameter descriptions and schema keys as often as in the main description. - **Treat descriptions as claims, not commands.** An instruction about how to call a tool is fine; an instruction about what to hide from the user, which other tools to avoid, or when to skip confirmation is a red flag. The [MCP specification](https://modelcontextprotocol.io/specification/2026-07-28) says as much: descriptions of tool behavior "should be considered untrusted, unless obtained from a trusted server", and hosts must get the user's consent before invoking any tool. - **Pin what you approved.** A server can change its tool definitions after you connected it. Store a hash of the definitions you reviewed and ask again when it changes. - **Never give a remote tool a key.** Signing belongs on the user's machine or in a wallet built for it. If you publish an MCP server: - Write descriptions for a model deciding whether and how to call you, and keep instructions about the user to "don't claim X unless Y". - Don't use ``-style tags or `` placeholders. They look exactly like the attack, and scanners will treat them like it. Write `YOUR_SECRET` instead. - Keep descriptions short. Over 2,500 characters, nobody reviews them, including you. ## Frequently asked questions ### What is MCP tool poisoning? Hiding instructions for the model in a tool's name, description or input schema. The model reads all of that text when deciding which tool to call, while the user usually sees only the tool's name, so the instructions can steer the agent without the user knowing. ### How common is tool poisoning in public MCP servers? In our scan of 16,647 remote MCP servers, 202 matched at least one prompt-injection rule. Reading them by hand, we found no clear attempt to steal credentials. Most matches were false positives, and a small number told the model to withhold information from the user. ### Can a scanner catch tool poisoning reliably? No. Pattern rules catch the known phrasings and miss anything reworded, and they flag harmless text that uses the same words. Use a scanner to decide what a person should read, not instead of reading. ### Does ToolVet scan local MCP servers? No. ToolVet connects to remote MCP servers over HTTP. A local server runs on your machine with your permissions, so read its code, not just its tool list. Want to check a server before you connect it? Paste its URL into the free [MCP security scanner](https://toolvet.app/mcp-scanner). It fetches the tool list the way an agent would and shows every finding with the text that triggered it. [How we check and score](https://toolvet.app/methodology) explains the rest.