You Audit Your Dependencies. You Don't Audit Your MCP Tools.

Published July 7, 2026

Your lockfile is pinned. Your SBOM is signed. Dependabot files PRs before you've had coffee. Somewhere along the way, your team internalized that third-party code gets reviewed before it ships.

Then you connect your agent to an MCP server you found on a registry, and its tools/list response — a JSON document written by a stranger — goes straight into your model's context. Unread. Every description, every parameter hint, every schema annotation becomes text your LLM treats as instructions.

That's not a dependency. That's a prompt you didn't write, from an author you've never met, executing in the most privileged position in your stack.

Tool descriptions are executable

The uncomfortable property of MCP is that tool metadata is load-bearing. The model decides what to call and how based on descriptions. Poison the description, and you don't need to compromise the tool's code at all — the attack runs in the model's head.

This is not hypothetical. The MCPTox benchmark tested tool poisoning against 45 live MCP servers and 353 real tools: popular agent frameworks followed poisoned tool metadata with attack success rates above 60%, topping out at 72%. The study's nastiest finding: more capable models did worse, because better instruction-following means better compliance with malicious instructions.

And poisoned tools are already in the wild. An academic scan of 1,899 public MCP servers found roughly 5.5% exhibiting tool poisoning, per the 2026 MCP security statistics roundup. Registries don't catch this for you — no major MCP registry publishes security audit coverage, and when the CoSAI consortium audited 17 popular servers, the average security score was 34 out of 100.

Then there's the rug pull. In September 2025, Snyk documented the postmark-mcp npm package shipping a malicious version that silently BCC'd every email it processed to an external domain — the first tracked malicious-MCP-server supply-chain incident. The server behaved perfectly during evaluation. The redefinition came later. That's the defining property of rug pulls: the tool you audited is not the tool you're running.

What "scanning a tool" actually means

VeriSwarm's MCP scanner is a static analyzer for tool definitions. Feed it a tools/list response; it runs 10 deterministic checks and returns findings with severity, evidence, and a recommendation. No LLM in the loop, no probabilistic judgment — pattern and structure analysis you can run in CI and get the same answer twice. (That determinism matters: one independent audit found YARA-based MCP scanners producing a ~78% false-positive rate. A scanner that cries wolf gets unplugged.)

The six core checks:

Tool poisoning. Hidden instructions in descriptions and parameter text — "ignore previous instructions," exfiltration directives, instruction overrides. The scanner walks the entire schema tree, including nested properties and oneOf/anyOf branches, so a payload buried four levels deep in a parameter description still surfaces.

Typosquatting. Tool names suspiciously close to well-known tools — including case-only impersonations like READ_FILE masquerading as read_file, which naive exact-match comparisons miss entirely.

Schema manipulation. Empty object schemas that accept anything, additionalProperties: true letting hidden fields ride along, and suspiciously deep nesting that gives malicious parameters somewhere to hide.

Rug-pull patterns. Language requesting access to credentials, tokens, or sensitive resources that the tool's stated purpose doesn't justify — the setup for a later redefinition.

Prompt injection. Base64 blobs that decode to readable text (payload smuggling) and Unicode homoglyphs — the Cyrillic а that looks like your a — used to sneak instructions past visual review.

Excessive permissions. A tool that describes itself as read-only but accepts command, script, or sql parameters is lying about something.

Four more checks map to the OWASP MCP Top 10's protocol-specific risks: model misbinding (tools hardcoded to specific models, a routing and exploit-surface risk), context spoofing (tools claiming the ability to rewrite conversation history or impersonate the user — capabilities that defeat both safety filters and audit trails), covert channels (non-standard metadata keys and vendor-extension fields carrying data your review never looked at), and insecure memory references (cross-session or wildcard state access that breaks tenant isolation).

Where it runs

Two surfaces, same checks.

In CI, as a gate: point the CLI at a saved tools/list response and wire the exit code into your pipeline — 0 for clean, 1 for warnings, 2 for critical findings. Vetting a new MCP server becomes a failing build instead of a Slack thread.

In production, via the API: POST /v1/guard/scan-mcp with the tool definitions, get the findings report back. This is part of Guard, VeriSwarm's security layer — and it's built to re-run. Because of rug pulls, a tool scanned once is only known-good once. Re-scan on every server update, or on a schedule, and the postmark-mcp pattern — clean at review, malicious at version bump — stops being invisible.

Scanning is the pre-deployment half of the story. The runtime half is Guard Proxy, which sits between your agent and its tool servers filtering live calls. Scan before you connect; proxy while you run. Neither substitutes for the other — the scanner catches what's declared, the proxy catches what's done.

Vet the tool before your model reads it

The MCP ecosystem crossed 10,000 public servers with essentially no audit infrastructure. The gap between "found it on a registry" and "let it into my agent's context" is where tool poisoning lives — and it's a gap you can close in about five minutes.

Send your current tools/list to /v1/guard/scan-mcp and see what your agents have been reading. If the answer is "nothing interesting," you've spent one API call confirming it. If it isn't — better to find out from a scanner than from MCPTox's 72%.