What the scan checks
What our scan actually checks
Five keyword searches over a shallow clone, plus three fields from the GitHub API. Run once, in March 2026, over 2,316 of the 2,805 servers here. This page used to call it an eight-point security audit and tell you a green badge meant safe to use in production. It is not an audit and it cannot tell you that.
2805
Servers listed
2,316
Cloned and scanned
489
Never scanned
2026-03-17
When the scan ran
One scan, five months ago. Nothing on this page reflects a repository's state today, and no server here has been re-checked since. Treat every result as a snapshot with a date on it.
The three outcomes
These describe what our checks returned. None of them is a verdict on whether a server is safe to run, and the top one is not a recommendation.
Nothing flagged
Our five searches returned no failures and at most two informational notes. That means our patterns did not match, which is weaker than it sounds: a grep cannot follow a variable, read intent, or know what a server does once it is running.
Something flagged
At least one check raised a warning or a failure. The specific finding is on the server's own page — read it rather than the badge, because the most common finding by far is "no authentication mechanism detected", which is expected and fine for a stdio server.
Not scanned
Never cloned, or the clone failed. We know nothing about these beyond their registry entry. Read the source yourself, which is advice that applies to the other two tiers as well.
The eight things we look at
Five are searches over a downloaded copy of the source; three are fields from the GitHub API. 2,316 of the 2,805 servers here went through them once, in March 2026. The per-server findings are on each server's page.
Authentication
What we check
Does anything in the source look like an authentication step — a bearer token, an API key, an auth middleware?
How we check it
A keyword search across source files for auth-related identifiers. It finds the presence of the words, not whether the mechanism is correct or reachable. A server can pass this by mentioning an API key in a comment, and fail it by implementing auth in a way our patterns do not name.
CORS policy
What we check
For HTTP/SSE servers, is there CORS configuration, and is it a wildcard?
How we check it
A search for CORS identifiers and a wildcard origin. Servers on stdio transport are marked not-applicable, which is most of the directory.
Rate limiting
What we check
Is there anything that looks like request throttling?
How we check it
A search for rate-limit identifiers. Same limitation as the auth check: it sees names, not behaviour.
Vulnerable dependencies
What we check
Does the dependency manifest name a package version we know to be vulnerable?
How we check it
The manifest is compared against a hardcoded table of 18 packages with known-bad version ranges, maintained in the scanner source. This is NOT `npm audit`, and it is not a vulnerability database. A dependency outside those 18 is invisible to it, which is nearly all of them.
Dangerous patterns
What we check
Does the code pass user-controlled input into eval, exec or a shell?
How we check it
A pattern search for constructs like execSync(req.…) and spawn with shell:true. This is the check most likely to catch something that matters, and it is still a regular expression over text — it cannot follow a variable, so an unsafe call assembled indirectly does not match.
Publisher
What we check
Who owns the repository, and is it an organisation or an individual?
How we check it
Read from the GitHub API. Repositories owned by a set of organisations we hardcode — Anthropic, Microsoft, Google, and others — are treated as better-known. This is provenance, not security: a well-known publisher can still ship a bug, and an individual is not suspect.
Licence
What we check
Does the repository declare a recognised open-source licence?
How we check it
The license.spdx_id field from the GitHub API. A legal signal, not a security one.
Maintenance
What we check
When was the last commit?
How we check it
The pushed_at timestamp from the GitHub API. Long-abandoned servers are more likely to carry unpatched dependencies, which is why it is here — but recency is not evidence of anything being fixed.
Why This Matters
MCP servers run with significant permissions on your machine. They can read files, execute code, access databases, and make network requests. A compromised or poorly written server can leak credentials, exfiltrate data, or open attack surfaces.
Industry data shows 38.7% of MCP servers have zero authentication, 22.9% have unrestricted CORS, and only 2.4% implement rate limiting. Real incidents have already occurred: the mcp-remote npm package (CVE-2025-6514) affected 437,000 developers, and Smithery had a path traversal vulnerability that leaked 3,000+ configurations.
Our audit does not replace your own due diligence. It provides a structured, transparent baseline so you can make informed decisions. Every check result is visible on the server's detail page.
Automation & Coverage
- First-pass automation
- ~85% of checks automated
- Manual review
- All Caution/Flagged servers
- Rescan frequency
- Weekly (automated)
- Data freshness
- GitHub data updated daily
Disclaimer
Our security ratings are based on automated analysis and manual review of publicly available source code and metadata. They do not constitute a professional security audit, penetration test, or certification. Ratings may change as new information becomes available. Always review source code and assess risk before deploying any MCP server in production environments.