Census of the registry: 25,125 distinct servers from 82,994 version records

[ashishsinha1602]

I took a full census of the registry and wanted to share the numbers, since I could not find them published anywhere.

Method

Retrieved every record from GET /v0/servers by cursor pagination in August 2026, continuing until no cursor was returned: 82,994 version records over 830 pages, resolving to 25,125 distinct servers from 15,468 publishers after filtering on isLatest.

Retrieval script: https://github.com/ashishsinha1602/dataset-integrity-audit/blob/main/fetch_mcp_registry.py

The unit-of-analysis trap

This is the part I would flag for anyone else measuring the registry. The endpoint returns one record per version, not per server.

Unit	Records	Sharing a description
Version records (as returned)	82,994	61,859 (74.5%)
Distinct servers (isLatest)	25,125	904 (3.6%)

Read as a catalogue the registry looks three-quarters duplicated. It is not — that figure is release cadence. Mean is 3.30 versions per server; the maximum is 1,175 versions of one server. Measuring without deduplicating inflates duplication by about 20x.

Shape of the registry

Publishers are extremely long-tailed. 13,848 publishers (89.5%) have registered exactly one server. The ten largest account for 15.7% of all servers. Any "X% of MCP servers do Y" statistic is therefore describing a handful of bulk publishers unless it is weighted.

Transports (servers may declare more than one):

Transport	Servers
Remote, streamable HTTP	13,279
Package, npm	7,985
Package, PyPI	3,434
Remote, SSE	1,054
Package, MCPB	891
Package, OCI	821
Package, NuGet	105
None declared	393

Metadata: no required field is missing from any record. 5,643 servers (22.5%) have no repository link, so their implementation cannot be inspected from the registry entry. Descriptions are capped at 100 characters, median 89.

Small concrete gaps

I opened #1579 for the actionable part: 387 active servers declare neither remotes nor packages, 262 deprecated servers remain listed, and 8 entries still carry the unedited [describe what your server does] template.

Caveats

Snapshot from August 2026; counts will drift. I measured only what records declare — I did not attempt to connect to any endpoint, so I cannot say how many of the 24,732 servers that do declare a transport are actually reachable.

Happy to rerun this periodically if a longitudinal view would be useful to the maintainers.

[ashishsinha1602]

Correction to the census above: the unreachable count is 189, not 393.

The table lists "None declared: 393" and the text cites 387 active servers as the actionable defect. Both overstate it, and I'd rather correct it here than leave the wrong number on the page people would cite.

The registry documents a custom installation path pattern — a server may declare neither packages nor remotes provided it supplies a websiteUrl pointing at setup instructions (docs/reference/server-json/generic-server-json.md, "Server with Custom Installation Path"). The example beneath that heading declares neither, deliberately.

Splitting the 387 accordingly:

	Servers
Active, no remotes and no packages	387
— with websiteUrl (documented pattern)	198
— with no websiteUrl at all	189

So roughly half were following guidance. The genuine defect is 189.

@erdemt independently reproduced this from a separate ingest pipeline in #1579 and got 385 / 197 / 188 on a different pull date — a one-server drift on a registry gaining several hundred a day, which settles the figure more firmly than my single measurement did.

They also found the complementary class I missed entirely: 1,314 servers declare a remote endpoint that is hard-unreachable (620 DNS-dead, 609 HTTP 404, 85 TLS failures), against 2,556 more that are auth-walled and therefore alive rather than dead. That "declares a transport that no longer exists" class is roughly 7x the "declares nothing" class, and no publish-time check can catch it — it decays after publication.

Everything else in the census above stands: the 20.7x unit-of-analysis result, publisher concentration, and the metadata figures were all computed over distinct servers and are unaffected.