Skip to content

Security Methodology

How we audit every MCP server. Fully transparent. No black boxes.

2805

Servers Scanned

43%

Verified

1165

Caution

433

Untested

Three-Tier Rating System

Verified

Verified

Passed all security checks with zero failures and no more than two informational warnings. Safe to use in production workflows.

Criteria: 0 fails, ≤ 2 warns
Caution

Caution

One or more checks raised warnings but no critical failures. Review the specific warnings before use. May need configuration hardening.

Criteria: ≤ 1 fail, ≤ 4 warns
Untested

Untested

This server has not yet been security scanned, or insufficient data was available. We recommend reviewing the source code and README before use.

Criteria: No scan data available

8-Point Security Audit

Every MCP server in our directory goes through these eight checks. The results are displayed on each server's detail page — nothing is hidden.

1

Authentication

critical

What we check

Does the server require authentication (API key, OAuth, connection credentials) before granting access? Servers that accept unauthenticated requests receive a warning.

How we check it

We analyze MCP handler entry points and configuration requirements. Servers using stdio transport with required environment variables (API keys, tokens) pass. Servers accepting anonymous connections fail.

2

CORS Policy

high

What we check

For servers using SSE or HTTP transport, is the CORS (Cross-Origin Resource Sharing) policy restricted to specific origins? Unrestricted CORS can expose the server to cross-site attacks.

How we check it

We search source code for CORS configuration. Servers using stdio transport are marked N/A (not applicable). HTTP/SSE servers with wildcard (*) origins receive a warning.

3

Rate Limiting

info

What we check

Does the server implement request rate limiting to prevent abuse? This is an informational check — absence does not trigger a failure, but presence is noted positively.

How we check it

We search for rate-limiting middleware, token buckets, or throttling configuration in the source code. This check produces info-level results.

4

Dependency Audit

high

What we check

Are there known security vulnerabilities in the server's dependencies? We run standard audit tools against the package manifest.

How we check it

For Node.js projects: `npm audit`. For Python projects: `pip-audit` or `safety check`. We shallow-clone the repository and run the appropriate audit tool. Critical and high severity vulnerabilities trigger a warning.

5

Known CVEs

critical

What we check

Are there any publicly disclosed CVEs (Common Vulnerabilities and Exposures) associated with the server or its direct dependencies?

How we check it

We query the GitHub Advisory Database API and cross-reference with the NVD (National Vulnerability Database). Any active, unpatched CVE triggers a failure.

6

Code Source Verification

high

What we check

Is the server's source code hosted on a verifiable platform (GitHub/GitLab) by a known organization or individual? This helps detect supply-chain attacks and fake packages.

How we check it

We analyze the GitHub owner profile: organization vs individual, follower count, repository history, and verification status. Official repositories from known companies (Microsoft, GitHub, Anthropic) receive the highest trust.

7

License Verification

medium

What we check

Does the repository have a clear, recognized open-source license? Unlicensed software creates legal risk and may indicate abandoned or experimental projects.

How we check it

We check the `license.spdx_id` field from the GitHub API. Recognized OSI-approved licenses (MIT, Apache-2.0, GPL, BSD) pass. Repositories with no license or custom licenses receive a warning.

8

Maintenance Status

medium

What we check

Is the server actively maintained? Abandoned servers may have unpatched vulnerabilities and compatibility issues with newer MCP protocol versions.

How we check it

We check the `pushed_at` timestamp from the GitHub API. Servers with no commits in 6+ months are flagged as stale. Servers with no commits in 12+ months are flagged as abandoned.

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.