Every MCP server you connect ships a tools/list response — a JSON document written by whoever built the server — straight into your model’s context, unread. Paste that response into VeriSwarm’s scanner and get 10 deterministic checks back in seconds: tool poisoning, typosquatting, schema manipulation, rug-pull patterns, prompt injection, excessive permissions, model misbinding, context spoofing, covert channels, and insecure memory references. No LLM judging your tools — pattern and structure analysis that returns the same verdict every time.
MCP tool metadata is load-bearing. The model decides what to call and how based on the description text — not the code behind it. A poisoned description doesn’t need to compromise anything; the attack runs entirely in the model’s reasoning. The MCPTox benchmark tested this against 45 live MCP servers and 353 real tools and measured attack success rates above 60%, topping out at 72%. Reading tool descriptions by eye doesn’t scale past the first server, and it doesn’t survive a rug pull — a server that behaves cleanly during your review and ships something different at the next version bump.
These cover the original risk categories the scanner was built for — the ones most likely to show up in a poisoned or careless tool definition.
Hidden instructions in descriptions and parameter text — “ignore previous instructions,” concealment directives, persona hijacks. The scanner walks the entire schema tree, including properties nested inside oneOf/anyOf branches, so a payload buried four levels deep still surfaces.
Tool names suspiciously close to well-known tools — including case-only impersonations like READ_FILE masquerading as read_file, which a naive exact-match comparison misses entirely.
Empty object schemas that accept arbitrary input, additionalProperties: true letting hidden fields ride along, and schema nesting past 4 levels deep — a common place to hide a malicious parameter.
Language requesting credentials, tokens, or access to sensitive files and internal network endpoints that the tool’s stated purpose doesn’t justify — the setup for a later redefinition once the tool is trusted.
Base64 blobs that decode to readable text — payload smuggling — and Unicode homoglyphs, like a Cyrillic а standing in for your a, used to sneak instructions past a visual review.
A tool named or described as read-only that accepts command, script, or sql parameters is claiming one capability and shipping another.
Protocol-specific risks the original six don’t cover — added to close out the full OWASP MCP Top 10 (2026) mapping the scanner reports against.
Tools hardcoded to a specific model — “only works with GPT-4” or a system-prompt coupling requirement. Locks in a routing dependency and a model-specific exploit surface.
A tool claiming it can rewrite conversation history, inject fake turns, or impersonate the user or assistant — capabilities that can defeat both safety filters and audit trails at once.
Non-standard top-level keys, vendor-extension (x-) schema fields, and long base64 blobs embedded in descriptions — places a reviewer scanning for prose won’t look.
Language claiming global, shared, or cross-session state access, or a session_id parameter defaulting to a wildcard — the pattern behind a tenant-isolation break.
Same 10 checks, same report shape, three ways in:
POST /v1/suite/guard/scan-mcp with the tool definitions in the body. Returns a verdict (pass / warn / fail), a 0–1 risk score, and a findings array — each finding carries the tool name, the check that fired, severity, evidence, and a recommendation.scanMcpTools() in the Node SDK, scan_mcp_tools() in the Python SDK — both wrap the same endpoint with typed request/response shapes.scan_mcp_toolstool on VeriSwarm’s own MCP server lets it scan another server’s tools before ever calling them — no separate HTTP client required.Findings with critical or high severity are persisted as Guard scan findings on your tenant, so a scan result isn’t a one-off console print — it’s a record you can review, triage, and close out over time.
A tool definition scanned clean today can ship something different tomorrow — the defining property of a rug pull is that the version you audited is not the version you’re running next week. Run the scan on every MCP server version bump, or on a schedule, not just at first connection. The scanner is the pre-deployment half of the story; the runtime half — filtering live tool calls as they happen, after the server has already passed a scan — is Guard Proxy. Neither replaces the other: the scanner catches what a tool declares, Guard Proxy catches what it does.
Tool poisoning is the check most worth understanding in depth — it’s the one where the attack runs entirely inside the model’s reasoning, with nothing to catch at the network layer. The mechanics, real-world attack rates, and how the scanner detects it are broken down on MCP Tool Poisoning: How the Attack Works and How to Catch It.
Call its tools/list method to get the tool definitions, then send that array to VeriSwarm's scanner — POST /v1/suite/guard/scan-mcp, the Node SDK's scanMcpTools(), the Python SDK's scan_mcp_tools(), or the hosted MCP server's scan_mcp_tools tool. All four call the same 10-check engine and return the same structured report: a verdict (pass/warn/fail), a 0-1 risk score, and per-finding severity, evidence, and a recommendation.
Ten deterministic checks: tool poisoning, typosquatting, schema manipulation, rug-pull patterns, prompt injection, and excessive permissions cover the original six risk categories; model misbinding, context spoofing, covert channels, and insecure memory references extend coverage to the full OWASP MCP Top 10 (2026). Every check is pattern- and structure-based — no LLM in the loop, so a given tool definition produces the same findings every time you scan it.
No. It's a static analyzer — regex patterns, schema-tree walks, and Unicode normalization, not a model call. That's a deliberate tradeoff: probabilistic judges are the reason at least one independent audit of a YARA-based MCP scanner reported a roughly 78% false-positive rate. Deterministic checks trade some recall for something a CI pipeline can actually gate on — the same input produces the same verdict twice.
Both. In CI, save a server's tools/list response to a file and scan it as a pipeline step — a critical finding is a failing build, not a Slack thread after the fact. In production, hit the API endpoint on a schedule or on every MCP server version bump, because a tool that scanned clean once is only known-good once. Re-scanning is how a rug-pull — a server that behaves during review and turns malicious after — gets caught instead of missed.
The scanner is the pre-deployment half: it reads declared tool definitions before your agent ever calls the server. Guard Proxy is the runtime half: it sits between your agent and its tools, filtering every live call as it happens. Neither substitutes for the other. The scanner catches what a tool says it does; Guard Proxy catches what it actually does at call time.
It's measured, not theoretical. The MCPTox benchmark tested tool poisoning against 45 live MCP servers and 353 real tools and found attack success rates above 60%, peaking at 72% — with more capable models complying more often, because better instruction-following means better compliance with a malicious instruction too. A full walkthrough of the attack mechanics and how the scanner's tool_poisoning check catches it lives on the dedicated explainer.
Send a tools/listresponse to Guard and see what your agents have been reading. Gate’s free tier gets you the trust-scoring and event pipeline first; Guard’s scanner runs on top of it.