Run an MCP server through a security scanner and you get back a rating: clear, review, or caution, sometimes with a score and a letter grade attached. It’s easy to read that as a verdict on the server as a whole. It isn’t. A scanner like this reads tool descriptions and schemas — the text a server hands your AI client before any tool actually runs — and it checks that text for a specific, narrow set of red flags. Here’s what that actually covers, using gate’s own scanner as a concrete example, and just as importantly, what it structurally can’t see.
What gets scanned
Before any tool call happens, a scan looks at every tool a server exposes: its name, its description, and its input schema — the same text your AI client reads to decide what a tool does and when to call it. That combined text runs through three layers.
- Deterministic checks. Pattern matching for things that show up reliably in known attacks: hidden or invisible Unicode characters (zero-width characters, bidi overrides) used to bury instructions from a human reviewer while the model still reads them; phrasing that reads like instructions aimed at the AI rather than a description of a tool (“ignore previous instructions,” “without telling the user”); references to credentials, environment variables, or sending data elsewhere; language suggesting arbitrary code, shell, or SQL execution; and descriptions that are unusually long, which is a common way to bury a real instruction inside padding.
- An LLM review pass. Regexes catch phrasing that repeats known patterns; they miss a rewritten version of the same trick. The second layer sends the full tool list to Claude with instructions to flag manipulation a pattern match would miss — embedded instructions, spoofed tool names, capabilities that don’t match the tool’s stated purpose.
- Provenance. Is this server on gate’s own handpicked, tested list, or in the official MCP registry? Being unlisted isn’t treated as a strike against the score — plenty of legitimate servers aren’t in either place — but it’s surfaced as a note: there’s no third-party signal on this one, so look closer yourself.
Findings get deduplicated and rolled into a rating and a 0–100 score: a high-severity finding (hidden characters, injection phrasing) costs more than a medium one (an exfiltration-adjacent reference), which costs more than a low one (an oversized description). One genuine high-severity finding is enough to move the rating to “caution.”
Drift: a second scan matters as much as the first
A tool you approved last month isn’t guaranteed to still say the same thing today. On a re-sync, the scanner hashes each tool’s description and schema and compares it against what it saw last time. A tool whose content changed since you approved it gets flagged as high severity — not because a changed tool is automatically malicious, but because a server quietly redefining a tool after you’ve already trusted it is exactly the mechanism behind an MCP rug pull. New tools and removed tools get flagged too, at lower severity, so nothing silently changes under you between reviews.
What a scan genuinely can’t catch
This is the part worth being honest about, because treating a clean scan as a guarantee is its own risk.
- Runtime behavior. A scan reads what a tool says it does. It doesn’t call the tool and observe what actually happens. A description that reads as completely benign can still front an implementation that behaves differently once invoked — that gap is invisible to any text-based check, gate’s included.
- Token handling. Whether a server issues its own audience-scoped tokens or forwards whatever bearer token the client already holds — the pattern covered in MCP token passthrough — is server implementation behavior. It doesn’t show up in a tool description at all, so a scan has nothing to read.
- Cross-server interactions. A tool description on one server can contain text that changes how the model calls a tool on a completely different, fully legitimate server — see MCP tool shadowing. Scanning one server’s tools in isolation won’t surface an interaction that only exists once two servers are connected at the same time.
- An agent misusing legitimate access. The confused deputy problem doesn’t require a malicious tool at all — a properly authorized tool, aimed by untrusted content the agent happened to read, is a completely different failure mode than anything a tool-description scan is built to catch.
None of this makes scanning pointless — it catches a real, specific class of attack (the kind covered in MCP prompt injection and tool poisoning) cheaply and before you’ve connected anything. It just isn’t the only check worth doing. Pair it with the broader review in how to vet an MCP server, which covers the questions a scan doesn’t ask — who built it, what it’s allowed to touch, whether you actually need every tool it exposes.
How to actually use a scan result
Treat “clear” as “nothing in the tool text matched a known red flag today,” not “safe forever.” Treat “caution” as a reason to open the specific finding and read the flagged tool yourself — the detail text exists so you don’t have to take the rating on faith. And re-scan on a schedule or on every sync rather than once at connection time, since the whole value of drift detection disappears if nothing ever runs it again.
The bottom line
A security scan for MCP servers is a cheap, useful, and narrow check: it reads tool descriptions and schemas for known manipulation patterns before you’ve connected anything, and it can catch a changed tool after the fact. It doesn’t watch what a tool actually does when called, doesn’t see how a server handles the token it’s given, and doesn’t know what happens when two servers’ tools interact. Use it as the first filter, not the last one.