Scanning a skill's source text catches a lot — but an MCP server is a running program with live tools, a network connection, and the ability to change its behavior depending on who's asking. Testing one properly means interacting with it, not just reading it. That's what our SAF-MCP audit does: 86 attack techniques, run against the live server.
Two tiers
We offer this at two depths:
shallow_33($5) — the 33 techniques that resolve through static analysis alone: signature matching against the server's exposed schema, tool descriptions, and metadata. No sandbox, no live interaction, results in minutes.full_86($49) — all 86 techniques, including everything shallow_33 covers plus 53 more that require actually running probes against a live instance: roughly 37 sandbox-executed techniques, 6 that need Claude's semantic judgment rather than a fixed signature, and 10 auth-aware checks that only make sense against a server's real OAuth/token flow.
Sandboxes with bait, not just a sandbox
The live techniques run inside a disposable Morph Cloud VM, one per scan: freshly created, seeded with honeypot bait — fake credential files carrying a unique per-sandbox canary token — used to speak MCP JSON-RPC to the target server for one batch of probes, then destroyed. The VM never holds a real secret, only the target URL and the bait. Critically, probes run from the sandbox's network egress, never from our own worker process — so a hostile target server only ever sees a disposable, isolated peer, never our infrastructure.
If the target tries to read that bait, or exfiltrate it somewhere, that's a real, observed finding — not an inference from static text.
Four phases, chained
A full_86 run isn't 86 independent, isolated checks. It's staged so later phases use what earlier phases learn:
- Discovery — four techniques enumerate the target's tools, endpoints, and metadata.
- Targeted probing — Claude reads the discovery output and generates per-technique probes shaped by what this specific server actually exposes, rather than firing generic payloads at everything.
- Remaining techniques — the rest run in batches of five, using those targeted probes and everything accumulated in a shared chain context.
- Report — findings get compared against our threat corpus, a trust score is computed, and the result publishes to VerifyClaw's public MCP registry.
If a server was already scanned before, techniques it previously resisted aren't re-run and re-billed — their prior verdict carries forward, and the run only pays for what's actually new or changed.
The rule we don't break
The honest-limits principle running through this whole pipeline: a technique whose verdict would require evidence we can't actually capture is reported pending, never faked as resisted. Our evidence collector, for instance, can do a real filesystem check (did the target touch the honeypot bait?) and a real point-in-time network snapshot — but not full packet capture or DNS logging yet. Rather than quietly mark those techniques as passed because nothing bad was observed in the narrower check, we report them as not-yet-verified. A trust score on VerifyClaw's registry is built only from what was actually tested — techniques still pending are visible as pending, not folded into a clean-looking pass rate.
Every MCP server we've run through this — shallow or full — is browsable for free in the public registry at verifyclaw.io, with the per-technique breakdown behind every trust score.