How many MCP servers are there? The answer spans two orders of magnitude

Ask how big the MCP ecosystem is and you'll get confident answers between ten thousand and several hundred thousand. Both are defensible. Neither is wrong. The number depends entirely on a definition nobody states out loud.

Here's the same question, measured six ways, today:

That's a 167× spread between the loosest and tightest honest reading. Any headline number quoted without its definition is noise.

Why the big numbers are wrong

npm's search is fuzzy. Query mcp-server and it returns 371,199 "matches" — every package whose name, description or keywords partially resemble the terms. There are not 371,199 MCP servers. There probably aren't 371,199 server packages of any kind.

This is the trap most ecosystem counts fall into: a registry search endpoint returns a total, the total gets quoted, and nobody checks what it counted.

Why the small numbers are also incomplete

The tightest counts come from curated sources:

• The official MCP Registry listed roughly 9,652 servers as of May 2026 (secondary source).
• Anthropic cited "more than 10,000 active public MCP servers" in December 2025 (secondary).
• GitHub's mcp-server topic returned 15,926 repositories in May 2026 (secondary).

These are real and useful, but they measure registration, not existence. The official registry is metadata-only and opt-in: a server appears because its author chose to publish it. Plenty of working servers never do. Counting the registry tells you how many people filled in a form.

The middle: what we actually measure

We crawl npm, PyPI, Docker Hub, GitHub and the official registry, and we keep 62,418 entries. Of those, 3,072 are hidden because they carry no MCP signal at all — broad GitHub scrapes that matched on the string "mcp" and nothing else. That leaves 59,346 publicly listed.

By how you'd actually run them:

The one trend worth watching: remote servers are growing fastest. Across three measurements of our own index this summer, the hosted share moved 10.7% → 14.7% → 17.1%. Everything else held roughly flat or declined. If that holds, the "MCP server" of 2027 is increasingly a URL you connect to rather than a package you install — which changes the security model, the distribution model, and who can participate (a phone can call a hosted server; it cannot spawn a local one).

So what's the real number?

There isn't one. There are tiers, and honest reporting names which tier it's using:

• ~2,200 — servers with meaningful community traction (≥100 stars)
• ~5,200 — servers with any traction at all (≥10 stars)
• ~9,700–16,000 — curated or registered, depending on the registry
• ~59,000 — everything discoverable that shows an MCP signal
• 100,000+ — anything a fuzzy registry search will return

Our own index sits at 59,346, and we say "indexed entries", not "MCP servers". The distinction is the whole point of this post.

What we don't claim

• We have barely verified that these servers work. We have started connecting to servers and asking what they expose, but only the 60 most-starred so far — 0.1% of the index. Of those, 20 answered, between them declaring 451 tools. For the other 59,286, our "MCP Compliance" signal is derived from metadata — packaging, tagging, declared capabilities — not from connecting and asking. A low compliance score means unverified, not broken.
• Do not read that as "two thirds of popular MCP servers are broken." Our harness spawns each server with no credentials and a 45-second budget, so anything wanting an API key, a build step, or a slow cold start fails for reasons that are ours, not the server's. 20 of 60 is a floor on how many work, not a measurement of how many don't — which is exactly the kind of number this post is warning you about.
• We can't measure staleness from this data. Our updated_at is our own row timestamp, not the upstream project's last commit, so we cannot tell you from this index how many servers are abandoned. External audits have claimed ~52% (secondary, unverified by us). We'd want to measure it before repeating it.
• Our index over-represents npm. Published packages are far easier to crawl than the long tail of un-packaged GitHub repos, so npm's 51% share is inflated relative to reality and manual-build servers are under-counted. Docker is under-crawled.
• Quality scores are relative, not absolute. Only 29 entries score ≥70 and the mean is 38 — that reflects our weighting (popularity, freshness, completeness, compliance, community) against a very long tail, not a claim that the ecosystem is 99.95% bad.
• We are not neutral. We run a registry and a gateway. The numbers are reproducible from public sources; the framing is ours.

Reproduce it

npm's counts are one request:

curl -s "https://registry.npmjs.org/-/v1/search?text=mcp-server&size=1" | jq .total

Run that today and you will not get 371,199 — npm's index grows by tens of packages an hour, and it was 371,305 by the time this went up. The tier it lands in is the point; the digits are not.

Our index is a public API:

curl -s "https://mcprating.io/api/v1/servers?limit=1" | jq .total
curl -s "https://mcprating.io/api/v1/servers?accessMethod=remote&limit=1" | jq .total

Next in this series: if most of the web becomes servers rather than pages, what does using it look like? And why discovery — not the protocol — is the binding constraint.