MCP security scanners compared
Several open-source tools now scan MCP servers for poisoned tools and risky configurations. They differ most in how they detect (patterns, LLMs or a hosted API), what they send off your machine, and what happens after the first scan.
Checked against each project’s own README on 30 September 2026. Projects move quickly: “not documented” means we could not find it in their docs, not that it cannot exist. Spotted something out of date? Open an issue and we will fix it.
| Hecate | Snyk Agent Scan | Cisco MCP Scanner | Proximity | |
|---|---|---|---|---|
| Formerly | n/a | Invariant Labs mcp-scan | n/a | n/a |
| Runtime | Node.js 20+ | Python, or a standalone binary | Python 3.11+ | Python 3.10+ |
| Install | npx hecate-mcp@beta | uvx snyk-agent-scan@latest | uv tool install cisco-ai-mcp-scanner | clone, pip install -r requirements.txt |
| License | Apache-2.0 | Apache-2.0 | Apache-2.0 | GPL-3.0 |
| Detection | Deterministic rules | Local checks plus the Agent Scan API | YARA rules; optional LLM, Cisco AI Defense API and VirusTotal engines | Discovery; NOVA rules with LLM evaluation for security analysis |
| Tool definitions leave your machine | Never | Yes: tool names, descriptions and configs go to the API (secrets redacted) | Only with the LLM or API engines | Only with LLM evaluation |
| Rug pulls: pin approved definitions, check in CI | Yes (pin, check, committed lockfile) | Not documented | Not documented | Not documented |
| Cross-server analysis | Lethal trifecta and shadowing across all of an agent’s servers | Toxic flows, tool shadowing | Not documented | Not documented |
| SARIF for code scanning | Yes | Not documented (JSON, CI mode) | Not documented (JSON and other formats) | Not documented (JSON, Markdown) |
| Runtime guard | Yes: @hecate-mcp/sdk (TypeScript) | Not in this tool | Not in this tool | Not in this tool |
| Beyond MCP | No | Agent skills | Package and behavioural code analysis, malware lookups | Agent skills |
Sources: snyk/agent-scan, cisco-ai-defense/mcp-scanner, fr0gger/proximity, protyoya/hecate-public.
The real trade-off: patterns or models
Pattern-based detection (Hecate, Cisco’s YARA engine, Proximity without an LLM) is fast, free to run, reproducible and private: the same input always gives the same result, and nothing leaves your machine. It is also literal. An injection worded in a way no rule anticipates will pass.
Model-based detection (an LLM, or a hosted API such as Snyk’s) can recognise intent in text it has never seen. The costs are that your tool definitions go to a model or service, results can vary between runs, and each scan has a price or needs a key.
Neither approach makes an agent safe on its own, because the most damaging attacks (rug pulls after review, and prompt injection through content at runtime) are not visible in a one-off scan at all.
Which one to use
- Every pull request, in CI: a deterministic scanner that fails the build and never needs network access or keys. Hecate is built for this: exit codes, SARIF annotations and a committed lockfile for rug-pull checks.
- Before adopting a new server: add a model-based scan for a second opinion on tool text, if your policy allows sending definitions to a model or service.
- Reviewing a server’s code or package: Cisco’s behavioural and package analysis goes beyond tool metadata.
- While the agent runs: a runtime guard (Hecate’s SDK for TypeScript agents) to hide changed tools, gate command execution and break the lethal trifecta with approvals.
Layering tools is normal. The combination that matters most is a scan before connection, pinned definitions checked continuously, and least privilege for each agent.