Depending on which audit you read, somewhere between 38% and 46% of public MCP servers have no authentication at all. Kai Security AI's scan of 518 registry servers is the most cited number, and a few follow-ups have refined it since. Whatever the exact figure, the takeaway is the same: the registry has no security requirements for listing, and most scanners can't help you before you've already pulled the code down and run it.
That gap is what I've been building trustmcp to close.
What it does
trustmcp is an open-source CLI that scans MCP servers for security issues: hardcoded secrets, unsafe eval/exec/subprocess patterns, hidden prompt-injection text in tool descriptions, missing auth, unpinned dependencies. It outputs an A-F grade plus a SARIF report that shows up directly in GitHub's Security tab.
pip install trustmcp
trustmcp scan --path . --mode static
The part I think is actually new
Every other MCP scanner I've found assumes you already have the source or a running server. trustmcp check scans a server before you install it:
trustmcp check npm:@modelcontextprotocol/server-everything
trustmcp check pypi:some-mcp-server
trustmcp check github:owner/repo
It resolves the package, downloads it into an isolated temp directory, and statically analyzes it. Nothing from the package is ever executed.
A bug I found in my own tool, and how I fixed it
Static analysis is Python-only right now (JS/TS is next). Early on, I ran check against Anthropic's own official reference server, @modelcontextprotocol/server-everything, a TypeScript package, and it came back Grade F, 33/100.
That's a bad look for a security tool: failing the reference implementation while having scanned zero lines of its actual code.
Digging in, it wasn't one bug, it was the same root cause hitting two modules:
- The static analyzer only reads
.pyfiles, so for a TS package it had nothing to scan (reasonable), but nothing told the user that a confident-looking grade had been computed from zero source review. - The auth-posture check has the same Python-only blind spot, and since
checknever runs a live probe (that would mean executing untrusted code), it was falling through to "no authentication mechanism detected" at HIGH severity, asserting an absence it had no way to actually observe. - On top of that, a dozen ordinary
^/~semver ranges inpackage.json, completely normal npm practice, were each individually costing points with no cap, so the score dropped almost regardless of anything else.
Fixed all three: an honest caveat when zero files were analyzed, a new "undetermined" auth state (distinct from "none detected") that doesn't carry the false-positive HIGH penalty, and a cap on how much any single repeated finding can drag the score. Same server now scores 76, Grade C, which is the actually defensible number: real findings (no lockfile, semver ranges, an honest "couldn't check this" note on auth), correctly weighted, nothing invented.
None of this touched the tool's validated detection benchmark, which is run against Damn Vulnerable MCP Server. That's all Python, so it was never affected. Currently 3/10 canonical challenges fully detected, 1 partial, 6 missed. Full per-challenge breakdown, including exactly why each miss happened, is in the README. I'd rather publish the real number than round up.
Demo
Links
Free, open source, MIT licensed. Static + dynamic analysis, auth posture, SARIF/JSON reporting, and the pre-install check command are all in the free tier. Semantic (LLM-based) analysis and cross-server toxic-flow detection are planned as a paid tier later, but everything above is complete on its own.
Feedback and bug reports very welcome, especially if you can break it on a server I haven't tested against.
Top comments (0)