← X190

The MCP registry lists 7,862 servers. 2,053 hostnames exist.

Measured 11 September 2026 with DNS alone. No endpoint was contacted, nothing was probed, and no publisher is named. This is a counting exercise, not a security finding.

Advertised, then actual

60% of remote listings are duplicates. 6,686 listings resolve to 2,660 distinct URLs. The registry permits the same endpoint to be listed many times, and one publisher alone accounts for 763 listings above its distinct URL count.

7.2% of hostnames do not resolve. 159 of 2,212. A hostname with no DNS record cannot be reached by any client, so whatever is listed against it cannot be serving anyone.

Both distortions are concentrated

This is not an even spread of sloppiness. A single publisher accounts for 125 of the 159 non-resolving hostnames, which is 78.6% of the entire dead surface. A different single publisher accounts for the 763 duplicate listings.

Remove those two and the registry looks materially healthier than the raw totals suggest. That is the useful part: the problem is two publishers, not a systemic failure, and it is fixable by whoever maintains the registry rather than by 1,766 separate operators.

Why this matters for anything you measure

Any statement of the form "N% of MCP servers do X" depends on what N counts. Counting listings rather than endpoints inflates the denominator by a factor of 2.5 here, and counting endpoints rather than reachable endpoints inflates it again.

We made exactly this mistake. Our own authentication measurement first described the population as 4,942 endpoints when that was a count of listings. The rate was unaffected, because the sample drew one endpoint per publisher domain, but the population around it was wrong and is corrected on that page. This report exists partly because finding our own error made the question worth asking properly.

The registry is also moving very fast

Active entries went from 5,897 to 7,862 in roughly eighteen hours between two runs, a 33% increase. Every figure here is a single snapshot and will be wrong shortly. That is an argument for re-measuring rather than for quoting this indefinitely.

Method, and what it is not

• DNS only. Each distinct hostname was resolved once. No TCP connection, no HTTP request, no MCP handshake. Nothing here touches anyone's server.
• Not an availability measurement. A hostname that resolves may still be down, and this says nothing about that. Resolution is a floor, not a health check.
• Not a security finding. Dead DNS is a hygiene matter. Nobody is exposed by it and nobody is accused of anything here.
• A resolving hostname is not necessarily reachable by you. Split horizon DNS and internal-only records exist. The direction of the error favours the registry: we may be counting some hostnames as alive that no public client can use.
• No publisher is named. Not in this report and not on request. The per-publisher breakdown is available privately to the registry maintainers, which is where a hygiene problem belongs.

Reproduce it

The registry API is public and DNS is public. The whole measurement is a page fetch loop and getaddrinfo, and you should not take our word for any of it.

curl 'https://registry.modelcontextprotocol.io/v0/servers?limit=100'

If you are running an MCP endpoint and want to know what an unauthenticated caller gets from it, that is the other question, and the tool for it is free: X190 ↗.