We Checked 55,934 MCP Registry Entries. Here's What We Found.

I run TrustedMCP, an MCP server directory. It's run by a small dev shop that builds MCP servers for clients, so I have a stake in this topic. People keep asking whether a given MCP server is OK to install, and my honest answer usually starts with "depends what you can check". So we checked the whole official MCP Registry against public data, to see how much of it can be checked at all.

Full report with the method, the limits and the raw data: State of MCP server security, November 2026. This post covers how the check works and what surprised me.

The setup

Snapshot: the official MCP Registry on 5 November 2026, 55,934 active entries (deleted and deprecated ones left out). Public data only:

• OSV (which includes GitHub Security Advisories) for each npm, PyPI, NuGet or cargo package, at the version the registry record pins.
• NVD for CVEs that mention MCP over 120 days, matched to an entry only when a CVE reference cites the entry's GitHub repo.
• GitHub API for last push, archived status and security policy of each of 29,540 distinct repos. Monorepos back many entries, so each repo counts once.

We didn't install or run any server, and didn't connect to any endpoint.

Step 1: can a scanner even look it up?

A registry record says how the server ships: a package (npm, PyPI, NuGet, cargo, an OCI image, an mcpb bundle), a remote URL, or both. OSV keys advisories by ecosystem, package name and version, so checking one package is one request:

curl -s https://api.osv.dev/v1/query -d '{
  "package": {"ecosystem": "npm", "name": "some-mcp-server"},
  "version": "1.4.2"
}'

An empty {} back means OSV has no advisory for that version. That only helps if there's a package and a version to ask about. Here's how the 55,934 entries split:

So 36,164 of 55,934 entries (64.7%) can't be checked this way, and 33,297 of those are remote-only: a URL someone else runs, with nothing to look up. (5 more pin a tag like latest instead of a version, so I left them out of the checkable base too.)

For those entries a clean result means "unknown". It isn't evidence of risk, but it isn't a clean bill either.

Step 2: what the checkable part shows

9 of the 19,765 checkable entries (0.05%) list a version with a known advisory. I read all 9 against the advisory text by hand, and 8 hold as written. One is a malware flag on a version npm has since removed, and the registry record still lists it.

The count is low for two reasons: only checkable entries are in the base, and OSV covers the package itself, not its dependencies.

The part I didn't expect: for only 3 of the 9 is the registry-listed version also the package's newest release. The package moved on and the registry record didn't. If your client installs the version the registry lists, you can get the older, affected release while a fixed one exists.

I'm not naming the 9 entries or their publishers. The report is about the registry, not individual maintainers.

Step 3: source links

17,915 of the 19,146 with no source link are remote-only, and some of those are hosted products that were never going to publish source. That limits what you can check. It doesn't prove neglect.

The dead links are more interesting. 3,965 of 29,540 linked GitHub repos (13.4%) return 404, and 4,800 entries point at one of them. A deleted repo, a private repo and a renamed repo whose redirect has gone all look the same from outside. I retested a random 50 while logged out, and all 50 still returned 404. I don't list the names: if a dead name can be registered again, the link could end up pointing at someone else's code, and a list would make that easier.

Step 4: CVEs that don't land on an entry

273 of 331 CVEs mentioning MCP (published 8 Jul to 5 Nov 2026) didn't match a registry entry by repo. That sounds bad, so I read a random 60. 54 were really about MCP. Of the 60, 35 were in standalone servers or gateways, 6 in SDKs or frameworks, and 19 in larger products.

So it isn't a coverage number. Many MCP flaws sit in the code around servers: the SDK a server is built on, or the app that hosts it. Those advisories never show up against a registry entry, which is why you should watch your SDK and client too.

The numbers that look fine

I'm including these because a report that only shows the scary numbers isn't worth much:

• 0 of 37,722 listed remote endpoints use plain http on a public host (read from the URLs as published).
• Only 1,957 of 25,575 reachable repos (7.7%) are stale (no push for 180 days) or archived.

What's missing is process. 17,399 of those 25,575 repos (68%) have no security policy, so someone who finds a flaw may have no private way to report it.

Ten days later

A full re-run on 11 November flagged the same 9 entries. By 15 November the registry had 62,678 active entries, a net 6,744 more than the snapshot. About 7 in 10 of the net new entries (71.2%) can't be checked, up from 64.7% at the snapshot, and most of those are remote-only. The gap is growing.

Before you install an MCP server

1. Remote-only server? Read "no known advisories" as "unknown", and ask the vendor how they handle security reports.
2. Open the source link. If it's missing or dead, ask why.
3. Compare the version the registry lists with the package's newest release, and pin the one you checked.
4. Prefer scoped, revocable sign-in over one broad API key.
5. Watch advisories for your MCP SDK and client as well as the server, and re-check monthly.

If you maintain a server: add a SECURITY.md or turn on GitHub's private vulnerability reporting, publish a new registry version when you release, and keep your source link current.

What this doesn't measure

Dependencies, code quality, how a server behaves at runtime, sign-in across the registry (stdio servers can't be observed, and probing remote ones would be active scanning), and anything outside the official registry. It's a signal from public data, from one snapshot. It isn't an audit.

The data is CSV and JSON under CC BY 4.0, linked from the report. If I got something wrong, say so in the comments and I'll correct the page.

Full report: trustedmcp.io/mcp-security-report