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 a high-impact attack class: tool-description poisoning.
- Build a fixed, dated fixture set and run each scanner against it. Capabilities here describe what each archetype is designed to detect, 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 should you test MCP scanners?
Run each scanner against a fixed bench of known-bad MCP fixtures. A good bench should include four fixtures: 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.
The method to use: score true positives, false positives, and install friction. Avoid a single headline accuracy number, because real-world MCP servers vary too widely for one figure to be honest. Align the threat framing with the OWASP GenAI Security Project and cross-reference control guidance from the NSA Cybersecurity Information Sheets.
What classes of finding should you look for?
Look 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 highest-impact class and the one schema validators consistently miss.
Which MCP security scanner archetypes are there?
There are 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 is designed to detect. Tool names are generalised to archetypes because vendor releases shift quickly, so re-test on each change.
| Scanner archetype | Detects (per docs) | 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, designed to catch description injection |
| 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, does not detect description injection |
| Static-plus-policy scanner | All of the above plus org policy rules and an allowlist | Heavier setup, config file and policy pack | Best documented coverage for teams, highest install friction |
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 is designed to cover the most dangerous planted risks, while a schema validator alone leaves the most dangerous fixture undetected. Run the bench above to confirm this for the specific tools you shortlist.
What does a scanner miss?
Every scanner 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:
- Add a description-injection linter to your continuous integration pipeline so poisoned descriptions block the merge.
- Add a scope auditor to flag any tool requesting more permission than its description justifies.
- Keep schema validation on, but never rely on it as your only check.
- Layer an org policy pack if you run more than a handful of MCP servers.
- 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 tool index lives on the AI security tools hub.
Methodology and honesty note
Capabilities in this article describe what each archetype is designed to detect, drawn from vendor documentation and primary standards, not vendor-certified benchmarks. The fixtures and pass condition above are published so you can build the bench and reproduce results in your own environment. We read primary sources first, including the OWASP GenAI Security Project, the Claude Code documentation for MCP host behaviour, and the Cursor security documentation. Re-evaluate against the bench and update the page whenever a scanner changes behaviour.