Why MCP server security is hard, and how we score it

The Model Context Protocol gives any compatible client a single way to plug into any server, and the ecosystem has grown accordingly: as of 29 July 2026 the official registry lists 19,048 servers exposing 20,692 components. Every one of those is also a new way for something to go wrong, and the speed at which agents install and call servers means the usual “I will review this dependency carefully” instinct rarely survives contact with reality.

That is the problem VerifyMCP exists to address: an independent, transparent trust score for every MCP server. This post explains why the problem is hard, and how we turned “is this server safe?” into a number you can act on.

The short version of why it is hard: the two kinds of MCP server fail in completely different ways, the most dangerous failure mode is one no external scan can see directly, and a scoring system that guesses at what it cannot verify is worse than no score at all.

An MCP server is not a passive API

The reason MCP security differs from “is this REST API up?” comes down to what a server actually is:

• A packaged server (npm, PyPI, NuGet, a container, an MCP bundle) is code you download and execute on your own machine. It is a dependency with execution rights. 10,895 of the registry’s components are these.
• A remote server is a hosted endpoint you hand context and tool calls to. You do not run its code, but you trust its operator and its connection. 9,797 components are these.

In both cases an autonomous agent can invoke the server’s tools without a human in the loop. That is the whole point of MCP, and it is exactly why a careless or malicious server is dangerous.

The two threat models

Because the two server types fail differently, they need different scrutiny.

For packaged servers, the risks are classic supply-chain risks with the review step removed: malware and account takeover, vulnerable transitive dependencies, install-time code execution, and a lack of provenance, meaning no way to prove the published artifact was built from the source you are reading. SLSA defines the build levels that close the provenance gap, in-toto defines the attestation format, and OSV is where the vulnerability data comes from. We cover the detail in MCP security: the risks that matter.

For remote servers, the risk moves to the connection and the operator: broken or weak TLS, plaintext HTTP, missing authentication, and no verifiable identity. Authentication is the one to watch. As of 29 July 2026, only 1,201 of 9,797 remote components required authentication when we probed them. Many of the rest serve public, read-only data and are perfectly reasonable as they are, but the number is worth knowing before assuming the endpoint you are about to connect gates access to anything.

Both share a subtler risk: prompt injection. Tool descriptions and results are text the model reads, so malicious content in either can hijack an agent. This is OWASP LLM01, and the MCP specification is explicit that clients “MUST consider tool annotations to be untrusted unless they come from trusted servers”. The OWASP MCP cheat sheet is the clearest vendor-neutral reference on the family of attacks that follows from it.

This is also the honest limit of any external scan, ours included. We cannot audit what a server does with your data once it has it, and a tool description that reads innocently to us may still be doing something else. What we can verify is whether a server was built by someone paying attention, and that turns out to correlate strongly with everything we cannot see.

Turning “is it safe?” into a number

A score is only useful if you trust how it was computed. Three principles keep ours honest.

A shared core, plus what makes each kind different. Part of every score measures the MCP contract itself, the things both kinds of server have: schema quality, stability, tool coverage and declared capabilities. The rest measures what only that kind can be judged on, supply chain and provenance for a package you download, endpoint security and transport for an endpoint you connect to. The exact weights move as the rubric improves, and how we score always describes the current ones.

Confirmed critical failures cap the score at zero. A confirmed malware verdict, an invalid TLS certificate, MCP served in the clear with no HTTPS redirect, or an unpatched critical CVE for which a fix has been published is not a deduction, it is disqualifying. A high score has to mean safe, not mostly safe.

That last qualifier is deliberate and worth spelling out, because it cuts the other way. Where a critical advisory exists but no fixed version has been published anywhere, the maintainer cannot upgrade out of it. We score that as a serious negative rather than a hard zero, because zeroing it would punish a maintainer for someone else’s unfixed advisory.

We never fabricate a signal. When we cannot verify something, such as an access-gated endpoint or an unreachable repository, we mark it inconclusive rather than guessing a pass or a fail. An inconclusive signal still counts its full weight against the total: a gap we could not confirm is never given the benefit of the doubt. Not observed and not present are different findings, and folding them together would quietly reward servers that are simply hard to look at.

The result is a distribution with very little at the top. Of the 18,689 servers we have scored, the median best score is 27 out of 100, and 123, 0.7% of those scored, reach the 80-plus band we label high trust. A further 352 listed servers carry no component at all, so they can never be scored and sit outside every percentage above.

Where to go next

• Maintainers: see how we score and the fix guides, or learn to build a secure MCP server from day one.
• Choosing a server: the MCP security checklist turns all of the above into two lists of checks you can run yourself, one for remote endpoints and one for packages.
• Everyone else: browse the directory or the comparison guides to see how today’s servers actually stack up.

Scores are independent estimates rather than guarantees of safety, and they are no substitute for your own review. MCP is going to be infrastructure. Infrastructure deserves to be measured, in the open, on signals you can check yourself.