Comparison
How does Agent Blast Radius compare to MCP-scan and Snyk Agent Scan?
MCP-scan and Snyk Agent Scan inspect MCP servers themselves — connecting to or starting them to analyze tool descriptions for prompt injection, tool poisoning, and rug pulls (tools that change after approval). Agent Blast Radius doesn't evaluate MCP servers' behavior; it inventories what credentials an agent can already reach, including secrets hardcoded into MCP config files and unpinned npx packages those configs would run. Different layers, same workstation.
Updated · Kloudle
What do MCP-scan and Snyk Agent Scan check?
Invariant Labs' MCP-scan inspects installed MCP server configurations and the tool descriptions those servers expose, looking for prompt injections hidden in descriptions, tool poisoning, and rug pulls — a tool's description changing after a user has already approved it. Per Invariant's announcement, MCP-scan connects to configured servers to retrieve tool descriptions for analysis, rather than executing arbitrary server code; if its optional Guardrailing API is used, tool names and descriptions are shared with Invariant for that check.
Snyk Agent Scan (also distributed as the snyk-agent-scan CLI) discovers MCP servers, agent skills and tools installed on a machine and looks for prompt injection, malware payloads and "toxic flows." According to its documentation, to retrieve tool descriptions it starts stdio MCP servers by executing the commands configured to launch them, and connects to configured remote MCP server URLs — interactive mode asks for consent before contacting each server, and an enterprise background mode reports results to a central Snyk Evo instance, with secrets redacted before anything is sent to its analysis API.
What does Agent Blast Radius check instead?
Blast never starts, connects to, or executes an MCP server. It reads MCP configuration files for Claude Desktop, Claude Code, Cursor, Windsurf, Gemini and project-level configs as plain text, and reports what's in them: inline environment credentials, references to env vars or files, filesystem roots the config grants, and unpinned npx packages that a config would run on next launch. The scan is local, offline and read-only.
Why does starting the server vs. just reading its config matter?
Retrieving a live tool description from an MCP server means contacting it — in Snyk Agent Scan's case, literally executing the launch command in the config, which is why its own documentation recommends sandboxing untrusted configs and gating execution behind a consent prompt. That's the cost of being able to catch behavioral issues like a manipulative tool description or a description that changed after approval.
Blast avoids that execution step entirely by staying read-only on the config file. The trade-off is scope: it can tell you a config hardcodes a credential or points at an unpinned package, but it has no way to evaluate what a server's tools actually say once running — that's what MCP-scan and Snyk Agent Scan are built for.
| Tool | What it inspects | Does it run the MCP server? | Data leaving the machine |
|---|---|---|---|
| MCP-scan (Invariant Labs) | Installed MCP configs and tool descriptions: prompt injection, tool poisoning, rug pulls | Connects to servers to retrieve tool descriptions; does not execute arbitrary server code | Tool names/descriptions shared with Invariant only if the optional Guardrailing API is used |
| Snyk Agent Scan | MCP servers, agent skills and tools on the machine: prompt injection, malware, toxic flows | Yes — starts stdio servers by executing their launch command to retrieve descriptions | Background mode reports results to Snyk Evo; secrets redacted before analysis |
| Agent Blast Radius | MCP config files: inline credentials, env/file references, filesystem roots, unpinned npx | No — never starts, connects to, or executes an MCP server | Fully local; nothing leaves the machine unless paid verify is used |
Should I run more than one of these?
Yes — they cover different layers of the same MCP setup. Run MCP-scan or Snyk Agent Scan periodically against the MCP servers you've installed to catch malicious or injected tool descriptions and rug pulls. Run Agent Blast Radius to see what credentials those same configs already expose or could hand to an unpinned package, since a server passing a behavioral scan today doesn't mean its config isn't also holding a live API key in plain text.
Check your own machine
See what an agent running as you can reach. Offline, read-only, never prints values:
npx -y @kloudle/agent-blast-radius@0.3.0Inside your agent: install guides for Claude Code, Codex, Cursor, Claude Desktop and more. Which keys are live? npx -y @kloudle/agent-blast-radius@0.3.0 verify (paid per check).
Frequently asked
Does Agent Blast Radius detect prompt injection in MCP tool descriptions?
No. That's outside its scope — it looks at what credentials an MCP config would hand to an agent, not at the wording of each tool's description. MCP-scan and Snyk Agent Scan are built for that.
Does MCP-scan execute my MCP servers?
According to Invariant Labs, MCP-scan connects to servers to retrieve tool descriptions rather than executing arbitrary server code, but it does share tool names and descriptions with Invariant's service when the optional Guardrailing API is used.
Does Snyk Agent Scan run code on my machine?
Yes. Per its documentation, scanning stdio MCP servers means executing the commands configured to launch them, which is why Snyk recommends sandboxing untrusted configs and gating execution behind consent prompts.
What's the benefit of a scanner that never runs the MCP server?
It avoids the risk of executing a server's launch command just to inspect it. The trade-off is that it can only report what the config says — such as a hardcoded secret or an unpinned package — not how a running server actually behaves.
Sources
- Introducing MCP-Scan — Invariant Labs
- snyk/agent-scan — GitHub
- Agent Security overview — Snyk documentation