Model Context Protocol servers have quickly become the connective tissue between AI agents and the outside world — file systems, databases, APIs, internal tools, you name it. That convenience comes with a catch: the tools, prompts, and schemas an MCP server exposes are a new kind of attack surface, and most traditional scanners simply don't look there. MCPRadar is an open-source project built specifically to close that gap.
Why this matters
A recent academic study examining nearly 1,900 MCP servers found meaningful security issues in a surprising share of them — general vulnerabilities in roughly 7% and MCP-specific tool poisoning in another 5%. Tool poisoning, prompt injection hidden in tool descriptions, and quietly over-permissioned configurations are easy to miss because they don't look like a "normal" vulnerability — there's no CVE, no obvious buffer overflow, just a tool description that quietly tells an agent to do something it shouldn't.
MCPRadar's whole premise is that this class of risk deserves the same rigor as any other part of your CI pipeline.
What it actually scans
MCPRadar isn't a single-purpose linter — it looks at an MCP server from several angles:
Protocol inspection — enumerates tools, prompts, resources, and templates the server exposes, and checks server instructions for suspicious content.
Source analysis — walks Python and JavaScript/TypeScript code looking for SSRF, unsafe deserialization, command/SQL injection, Trojan Source tricks, and mismatches between a tool's description and what its code actually does.
Configuration review — flags poisoned MCP or agent configuration files, risky hooks, and overly broad permission grants.
Supply chain checks — fetches packages without running install scripts, cross-references dependencies against OSV, and can emit a CycloneDX SBOM with hashes and provenance.
Change monitoring — stores snapshots in SQLite and diffs them over time, classifying changes as cosmetic, behavioral, or security-relevant so silent drift doesn't slip past you.
CI integration — outputs JSON, SARIF, or CEF, and supports policy-as-code gates with suppressions for teams that want scanning baked into pull requests.
Getting started
You don't even need to install it to try it out:
bash
uvx mcpradar scan http://localhost:8080
For repeated use, install the CLI directly:
bash
uv tool install mcpradar
mcpradar --help
It requires Python 3.11+, and pip install mcpradar works too if you're not on uv.
A few other common workflows:
bash
Scan a local stdio server inside a disposable sandbox
mcpradar scan "python ./server.py" -t stdio --sandbox
Analyze source code without executing it
mcpradar scan-source ./path/to/server
Check a published package and its dependency tree
mcpradar deps npm:@modelcontextprotocol/server-filesystem
Diff against the previous snapshot
mcpradar diff http://localhost:8080
Emit SARIF for CI pipelines
mcpradar scan http://localhost:8080 --format sarif -o mcpradar.sarif
The security model is refreshingly paranoid — in a good way
MCPRadar treats every server it scans as untrusted input, which is exactly the right instinct for a security tool:
Stdio commands won't run on your host unless you explicitly opt in with --allow-host-exec, or better, run them in --sandbox.
Sandboxed scans happen in a disposable, non-root container with a read-only filesystem, dropped capabilities, and no host mounts.
Source scans of packages download and inspect archives without ever executing install scripts or server code.
Remote fetches are bounded by URL, redirect, size, and timeout limits, with protections against reaching into private networks.
If a container genuinely needs network access to pull a package at startup, that's an explicit, opt-in flag (--sandbox-network bridge) rather than a default.
Risk scoring that doesn't oversell itself
Findings roll up into MRS-v1 (MCPRadar Risk Score), a versioned 0–10 signal that factors in findings, confidence, server capabilities, dependency risk, and how much of the server was actually covered by the scan. Importantly, the project is upfront that this is a risk signal, not proof of exploitability — and an incomplete scan is reported as incomplete rather than quietly treated as "clean."
A public leaderboard
There's also a public leaderboard that publishes reproducible scan results — coverage, findings, and MRS grades — for popular, installable servers from the official MCP Registry, refreshed daily. You can request a server be added by opening a scan request issue; nothing gets executed just by filing the request, and everything is reviewed before it's added.
Worth knowing before you rely on it
The maintainers are honest about the limits of static, pattern-based detection:
Findings can be false positives and may need contextual review.
Attacks that only manifest at runtime might not show up in a point-in-time scan.
Obfuscated or genuinely novel techniques can evade static rules.
That kind of transparency is refreshing for a security tool, and it's a good reminder that a scanner like this complements manual review rather than replacing it.
Try it
bash
uvx mcpradar scan http://localhost:8080
If you're building or deploying MCP servers — or just plugging third-party ones into your agents — it's worth running a scan before you trust them with real credentials and real data. The project is MIT-licensed and open to contributions if you want to add detection rules or extend coverage.
Top comments (2)
Folding coverage into the same 0 to 10 score as findings and confidence is the part I'd want more detail on, because it can quietly recreate the exact problem this kind of tool exists to catch. If a low-coverage scan and a high-coverage clean scan can land on similar numbers, both have few findings, just for different reasons, the MRS number stops distinguishing verified safe from didn't look very hard, and that's the gap between an artifact and a receipt. Reporting an incomplete scan as incomplete has to mean something the number itself can't say, otherwise incomplete is a label attached to a score that already reads as reassuring on its own.
Concretely: would two servers, one fully scanned with zero findings and one scanned at 20% coverage with zero findings, get meaningfully different MRS values, or does the coverage penalty only show up in a separate field a consumer has to go looking for? If it's the latter, most people are going to read the single number the same way a CI gate reads exit code 0, and coverage becomes the same kind of denominator problem a risk score is supposed to prevent one layer up.
This is the layer MCP needed. The server is not just a transport detail once agents can hand it credentials and local files. I like scanners here most when they produce boring evidence, not a scary score, because the next step is usually deciding which tool surface should not exist at all.