If you're building with AI agents, you've probably connected to an MCP server. The Model Context Protocol has become the standard for wiring AI models to external tools , adopted by Anthropic, OpenAI, Google, Microsoft, and thousands of developers. There are now 17,000+ MCP servers listed across registries and 97M+ monthly SDK downloads.
But here's a question almost nobody is asking: how do you know if the server you're connecting to is safe?
We built CraftedTrust to answer that question. We scanned the MCP Registry, crawled npm for MCP-related packages, and ran live security assessments against every publicly reachable server. Here's what we found.
The Numbers
We started with the official MCP Registry, which lists 9,538 servers. Of those, only 1,529 declare HTTP or HTTPS transport, the rest are stdio-only, meaning they run locally and can't be reached over the network.
Of those 1,529 HTTP servers, we attempted live handshakes with each. The results:
• 105 servers responded successfully and completed a full trust assessment
• ~800 returned 401/403, authentication required, no public access
• ~200 returned 404, registered but no longer running
• ~100 timed out or returned server errors
The 105 publicly scannable servers represent the entire surface area of the MCP ecosystem that any agent can connect without pre-configured credentials.
What We Found in the Public Ecosystem
Across those 105 servers, the average trust score was 75 out of 100. The distribution:
• 36 servers scored Trusted (80-100)
• 69 servers scored Moderate (60-79)
• 0 servers scored Caution, Warning, or Dangerous
No dangerous servers. That's genuinely good news, the public MCP ecosystem is surprisingly healthy. The developers building public MCP servers are generally doing the right things.
But the score distribution hides a more interesting finding.
The 82% Auth Gap
The biggest security issue in the MCP ecosystem isn't malicious servers.
It's metadata.
82% of HTTP-transport servers in the registry require authentication but don't declare it in their registry metadata. An agent discovering servers through the registry has no way to know, before attempting a connection, whether a server will accept it or demand credentials it doesn't have.
This matters because the agent connection flow is:
discovering server in registry → attempt connection → hope for the best.
If the server requires auth the agent doesn't have, the connection fails silently or with an opaque 401. There's no standard mechanism for an agent to determine auth requirements before connecting.
The MCP spec's own 2026 roadmap acknowledges this gap. One of the planned improvements is a standard metadata format served via .well-known so server capabilities (including auth requirements) are discoverable without a live connection. But that's not shipped yet.
How We Score Trust
Each server gets a 0-100 score based on 7 factors:
Declaration Accuracy, does the server's actual behavior match what it declares in its manifest? If it says it has 3 tools but exposes 8, that's a red flag.
Permission Minimality, does the server request only the permissions it needs? Wildcard permissions score lower than scoped ones.
Network Behavior, does the server make outbound connections? To where? Unexpected external calls are suspicious.
Code Transparency, is the source code available? Open-source servers score higher because they're auditable.
Publisher Reputation, who built this? Maintained GitHub repo with stars and recent commits scores higher than an anonymous package with no activity.
Transport Security, HTTPS only? TLS 1.2+? Certificate valid?
Known Threat Match, does the server match any patterns from known malicious MCP servers or contain dependencies with known vulnerabilities?
For npm packages without a live endpoint, we run static analysis: dependency health, maintenance recency, documentation quality, license clarity, and repository activity. This gives us a "Package Analyzed" score that's less authoritative than a live scan but covers the long tail of the ecosystem.
The stdio Problem
Here's the uncomfortable truth about MCP security: most servers can't be remotely verified at all.
The majority of MCP servers use stdio transport, they run as local processes on the user's machine, invoked via npx or a direct binary. There's no HTTP endpoint to scan. No network traffic to analyze. You install the package, it runs locally, and you trust that the code does what it says.
This is the same trust model as npm packages generally, and we know how that's gone. Supply chain attacks via npm are a well-documented threat vector. The difference is that MCP servers get tool-level access to execute actions on your behalf , reading files, making API calls, accessing databases. A compromised MCP server isn't just reading your code; it's potentially executing arbitrary actions through your AI agent.
For stdio servers, the only verification possible is static code analysis and package metadata assessment. We do both, but the confidence level is inherently lower than a live behavioral scan.
What's Actually Dangerous
We haven't found malicious public MCP servers (yet). But the attack surface is real and growing. Published research has documented several MCP-specific threat vectors:
Tool poisoning, a server declares a tool with a benign description, but its actual implementation does something different. The agent reads the description and trusts it.
Rug pulls: a server behaves normally during initial setup but changes behavior after gaining trust. Since there's no continuous monitoring standard, this goes undetected.
Dependency hijacking, a popular MCP package has a dependency that gets compromised upstream. The server author did nothing wrong, but the package they distribute now contains malicious code.
Metadata manipulation, registry listings don't match actual server behavior. An agent selects a server based on false metadata.
The CVE-2025-6514 incident compromised over 437,000 developer environments through MCP's OAuth proxy. The OpenClaw crisis found 1,184 malicious skills in a single marketplace, roughly 1 in 5 packages. These aren't theoretical risks.
What Needs to Change
The MCP protocol itself explicitly states it "cannot enforce security principles at the protocol level." Security is left to implementations, clients, and the ecosystem. The 2026 roadmap lists security as "On the Horizon", important but not a top four priority.
That leaves a gap that the ecosystem needs to fill:
Registry metadata standards, servers should declare auth requirements, permission scopes, and expected network behavior in a machine-readable format before any connection is attempted.
Independent verification, trust scores from third parties who aren't also selling MCP servers. The conflict of interest when a marketplace scores its own listings is obvious.
Continuous monitoring, a server that scores 80 today could score 20 tomorrow after a dependency update. One-time scans aren't enough.
Cryptographic attestation, trust scores should be independently verifiable, not just a number on a website. On-chain attestations (via EAS or ERC-8004) can provide tamper-proof records of what a server's trust score was at any point in time.
Try It
All of our scan data is public and free at mcp.craftedtrust.com. Search the registry, check any server's trust score, embed badges in your README. The API is documented and open.
If you're a server publisher, you can submit your server for a free scan or apply for certification. If you're building agents, you can query trust scores programmatically before connecting to any server.
The MCP ecosystem is healthy today. But it's growing fast, and the security infrastructure hasn't kept up. The time to build trust verification is before the first major incident, not after.
Top comments (0)