The MCP Registry, By the Numbers

Originally published on DevToolHub.

The official MCP registry is the closest thing the Model Context Protocol has to an app store. So we pulled every entry from its API and counted what's actually in there. The short version: 30,375 servers as of September 10, 2026, but a third of them come from about 50 accounts, 62% were published once and never updated, and the companies that founded MCP have published almost none of their own servers there. The registry changes every hour, so treat these as a snapshot, not a leaderboard.

How big the MCP registry actually is

The registry API returned 99,114 server-and-version records, which collapse to 30,375 unique servers once you keep only the latest version of each. That is roughly 3x what it held in May 2026 (about 9,650 servers), and the curve is still steepening:

Month servers first published	New servers
Sep 2025 (launch)	407
Feb 2026	1,081
Apr 2026	2,387
Jun 2026	3,662
Jul 2026	4,840
Aug 2026	6,265

August 2026 alone added more servers than the registry's entire first five months combined. Whatever "MCP adoption" means, the supply side is not the bottleneck.

Almost nothing ever leaves. Of the 30,375 servers, 98.9% are marked active and 1.1% (332) are deprecated. Zero are visibly deleted. The registry adds; it does not prune.

Who is publishing all these servers

Every server name is a reverse-DNS namespace tied to a verified source — either a GitHub account (io.github.username/server) or a domain the publisher proved they own (com.example/server), per the registry's publishing rules. The split:

• 67.2% published under an io.github.* namespace — an individual or org GitHub account
• 32.8% published under a verified domain — companies with com., io., ai., dev. prefixes

Across ~18,200 distinct publishers, the distribution is extremely top-heavy. The top 10 publishers account for 17.7% of every server in the registry. The top 50 account for 24.6%. Meanwhile 16,356 publishers have exactly one server each.

The largest single publisher, io.github.sadri-dridi, has 1,505 servers — about one in every twenty in the registry. They are single-function micro-tools with descriptions like "Acres to hectares, number discarded" and "Absolute value sign, number discarded." The next tier tells a similar story: io.github.Evozim has 375 servers, and 276 registry entries share the exact description "Premium agentic endpoint for [name]-mcp." ai.smithery mirrored 213 servers straight from its own directory, test projects and all.

Some bulk publishers are doing real work — io.github.pipeworx-io (1,321 servers) and io.github.mcp-dir (1,113) are systematically wrapping public APIs with genuine descriptions. But the pattern holds: the raw server count is inflated by a handful of automated publishing operations, not 30,000 hand-built tools.

Remote won: how MCP servers are actually deployed

Every server declares how you connect to it — a remote HTTP endpoint, a local package you install, or both.

Deployment	Share of servers
Remote only (HTTP / SSE)	54.8%
Local only (installable package)	38.9%
Both	4.9%
Neither declared	1.4%

Remote is now the majority, and it's overwhelmingly the current transport: 17,584 remote endpoints use streamable-http versus 1,073 still on the deprecated sse transport.

For the local servers, the package ecosystem breaks down as:

Package registry	Packages
npm	8,673
PyPI	3,684
mcpb (Claude Desktop bundle)	1,158
OCI (container image)	899
NuGet	111
Cargo	48

npm is more than twice PyPI. If you maintain MCP tooling, that's where the users are.

The maintenance problem

Here's the number that should make you cautious about picking a server off the list by its description alone.

• 62% of servers have exactly one published version. They shipped once and were never revised.
• 40.8% of servers' latest version is still 1.0.0, 0.1.0, or 0.0.1 — a first release with no iteration behind it.
• Median versions per server: 1. The mean is 3.26 only because a few servers have hundreds of releases (the busiest has 1,176).

On freshness, the picture is better than the versioning suggests but still uneven. Grouping every server by when its current version was last updated:

Last updated	Share
Within 30 days	37.9%
31–90 days	25.7%
91–180 days	19.0%
181–365 days	7.7%
No update timestamp	9.8%

Roughly 36% of servers haven't been touched in three months or more (counting the ones with no timestamp). For a protocol whose auth and transport spec changed materially in the 2026-07-28 update, a server last updated in early 2026 is a server that predates the current rules.

What the registry does not tell you

The registry entry for a server records its name, description, version, transport type, the package or remote URL, a link to the source repository, icons, and a website. That is the whole schema.

It records nothing about whether the server is safe to run. There is no field for the authentication method, no security-review status, no check that the remote endpoint is even online, and no install or usage count. Namespace verification proves the publisher controls io.github.their-account — it says nothing about the server behind it.

And 22.9% of servers link no source repository at all. For remote-only servers — the ones you point an agent at over HTTP — that rises to 37%. More than a third of the remote MCP servers in the official registry give you an endpoint and a description, and no code to read.

This matters because "official registry" carries weight it hasn't earned yet. It's official in the sense that the MCP project runs it — not in the sense that anything in it is vetted. The archived reference Postgres server with a read-only bypass is the reminder: a trusted label is not an audit.

The founding vendors have barely shown up

The registry is backed by Anthropic, GitHub, and Microsoft. Their own server counts in it:

Namespace	Servers
com.microsoft	16
io.github.github	1
com.stripe	1
io.github.awslabs	1
com.anthropic	0
io.github.modelcontextprotocol	0

The official reference servers, GitHub's remote MCP server, Anthropic's own tools — most of the servers you'd actually reach for aren't published to the registry their maintainers built. Discovery for the servers that matter still happens through docs and word of mouth, not the registry.

How to actually use the MCP registry

It's a genuinely useful index for one thing: finding out whether a server exists and where its code lives. Beyond that, filter hard.

• Start from the namespace. A com. or io. verified-domain namespace means a company staked its domain on it. An io.github. namespace with 1,000+ servers under it is a bulk operation — judge the individual server, not the publisher.
• Check the version and the update date, not just the description. 1.0.0, published eight months ago, no repo link — skip it, especially for anything remote.
• Follow the repository link before you connect anything. If there isn't one, and it's a remote server, that's a hard stop for production use.
• Re-verify auth yourself. The registry won't tell you if a remote server implements the current OAuth 2.1 requirement. You still have to check each one against its own docs.

Frequently Asked Questions

Q: How many MCP servers are in the official registry?
A: 30,375 unique servers as of September 10, 2026, from about 99,000 total version records. It has roughly tripled since May 2026 and is still growing, adding more than 6,000 new servers in August 2026 alone.

Q: Are the servers in the MCP registry vetted or secure?
A: No. The registry verifies that a publisher owns the namespace they publish under (via GitHub OAuth or domain verification), but it stores no security review, no authentication details, and no check that a server works. Treat a listing as "this exists," not "this is safe."

Q: Is the official MCP registry the biggest one?
A: It's the canonical one, but not the only index. Third-party directories like PulseMCP and Smithery aggregate across sources and report similar or larger totals depending on how they count. Some of the official registry's volume is mirrored from those directories.

Q: Should I publish my MCP server to the registry?
A: Yes, if it's real and maintained — it's free, and it's where automated discovery is heading. Publish under a verified-domain namespace if you can, link the source repository, and keep the version current with the spec. That alone puts you ahead of most of the list.

Q: Why aren't Anthropic's or GitHub's servers in the registry?
A: Unclear. As of this snapshot, com.anthropic has zero entries and io.github.github has one. The founding organizations built the registry but have mostly not populated it with their own servers, so the highest-quality servers are underrepresented.

Quick Summary:

• The official MCP registry holds 30,375 servers (99,114 version records) as of 2026-09-10, up ~3x since May 2026, adding 6,000+ per month
• 67% are published under a personal GitHub namespace; the top 10 publishers account for 17.7% of all servers, one of them with 1,505 single-function micro-tools
• 55% of servers are remote-only (almost all streamable-http), 39% are local packages (npm leads, then PyPI, then Claude Desktop bundles)
• 62% have only one version, 41% are still on a 1.0.x/0.x first release, and ~36% haven't been updated in 3+ months
• The registry records no auth method, no security review, and no uptime check; 23% of servers (37% of remote-only ones) link no source repository
• Anthropic, GitHub, and Microsoft — who back the registry — have published almost none of their own servers to it

The registry is a directory, not a seal of approval. Use it to find servers and their code, then vet each one the way you'd vet any dependency you're about to hand your data to.