MCP security scanners compared

TL;DR:

• MCP security scanners read tool descriptions as untrusted input and flag poisoned instructions, hidden payloads, and over-broad scopes.
• Schema-only validators miss the highest-frequency attack on our bench: tool-description poisoning.
• We tested each scanner against a fixed, dated fixture set; figures here are illustrative of our method, not certified benchmarks.
• Pair any scanner with runtime controls from the AI agent hardening checklist and the MCP security best practices guide.

What is an MCP security scanner?

An MCP security scanner is a tool that inspects Model Context Protocol server definitions for malicious or over-privileged behaviour before you connect them. It parses the server manifest, the tool list, and each tool description, then flags risks. The core insight is that an MCP tool description is model-facing context, so it must be treated as untrusted input, not documentation.

This matters because MCP is now the default way AI agents gain capabilities, and a single poisoned server can hijack an agent. For the wider risk model, see our OWASP LLM Top 10 risk guide, which maps tool poisoning to the broader injection category defined by the OWASP GenAI Security Project.

How did we test MCP scanners?

We ran each scanner against a fixed bench of four known-bad MCP fixtures, last refreshed on 20 June 2026. The fixtures are: a tool description carrying a hidden instruction, a tool requesting file-system scope beyond its stated job, a server with a name-shadowing duplicate tool, and a clean control. A scanner passes a fixture only when it flags the planted risk and leaves the control alone.

Our methodology note: we score true positives, false positives, and install friction. We do not publish a single headline accuracy number, because real-world MCP servers vary too widely for one figure to be honest. We align our threat framing with the OWASP GenAI Security Project and cross-reference control guidance from the NSA Cybersecurity Information Sheets.

What classes of finding did we look for?

We looked for four finding classes: description injection, scope creep, name shadowing, and exfiltration-prone parameters. Each class maps to a real attack. Description injection is the most frequent finding on our bench and the one schema validators consistently miss.

Which MCP security scanners did we compare?

We compared four representative scanner archetypes: a description-injection linter, a scope auditor, a schema validator, and a combined static-plus-policy scanner. The table below records what each archetype caught against our fixtures. Tool names are generalised to archetypes because vendor releases shift quickly and we re-test on each change.

Scanner archetype	What it catches	Install	Verdict
Description-injection linter	Hidden instructions and prompt-injection payloads inside tool descriptions	npm or pip package, runs in CI	Recommended as a first pass, caught description injection on our bench
Scope auditor	Tools requesting permissions broader than their stated purpose	CLI binary, reads the manifest	Recommended alongside a linter, strong on scope creep, weak on injection
Schema-only validator	Malformed manifests and invalid parameter types	Built into many MCP SDKs	Necessary but not sufficient, missed description injection entirely on our bench
Static-plus-policy scanner	All of the above plus org policy rules and an allowlist	Heavier setup, config file and policy pack	Best coverage for teams, highest install friction, illustrative coverage near full on our four fixtures

The pattern is clear: no single archetype covers every finding class, so layering is the practical answer. A description-injection linter plus a scope auditor caught every planted risk on our bench, while a schema validator alone left the most dangerous fixture undetected.

What does a scanner miss?

Every scanner we tested misses behaviour that only appears at runtime. A manifest can be clean while the live server returns a poisoned result mid-session. Static scanning is a build-time gate, not a substitute for runtime egress control and permission scoping. This is why we route readers to the AI agent hardening checklist for the runtime half of the defence.

The other consistent gap is intent: a scanner cannot tell whether a broad scope is malicious or merely lazy. A human reviewer must still approve any third-party MCP server before it touches production.

How should you choose an MCP scanner?

Choose a scanner that treats tool descriptions as untrusted input and run it in CI on every MCP dependency change. Follow these steps:

1. Add a description-injection linter to your continuous integration pipeline so poisoned descriptions block the merge.
2. Add a scope auditor to flag any tool requesting more permission than its description justifies.
3. Keep schema validation on, but never rely on it as your only check.
4. Layer an org policy pack if you run more than a handful of MCP servers.
5. Gate every new server behind a human review, guided by the MCP security best practices guide.

For the coding assistants that consume these MCP servers, our Cursor vs Copilot vs Claude Code security comparison shows how each host handles untrusted tool output. The full tested-tool index lives on the AI security tools hub.

Methodology and honesty note

Every number in this article is illustrative of our 20 June 2026 fixture bench, not a vendor-certified benchmark. We publish the fixtures and the pass condition so the result is reproducible. We read primary sources first, including the OWASP GenAI Security Project, the Claude Code documentation for MCP host behaviour, and the Cursor security documentation. We will re-run this bench and re-date the page whenever a scanner changes behaviour.