Sixty remote MCP servers from the official registry, read once each, every endpoint named

This is a reading, not an opinion. On 5 September 2026 sixty remote server endpoints were drawn at random from the whole official Model Context Protocol registry and each was read once, by this company’s own free mcp_discovery_check tool, exactly as an unauthenticated registry crawler reads one: a single initialize, a single tools/list, and a read of nine discovery documents. No tool was called on any target and nothing was stored about any of them. Every endpoint is named below with the number it returned, so anyone can re-read the same table against the same tool.

How the sample was drawn, stated so you can rebuild it

1. Page registry.modelcontextprotocol.io/v0.1/servers?limit=100&version=latest until the cursor is exhausted. On 5 September 2026 that was 273 pages and 27,229 latest-version server records.
2. Keep every remotes[].url that begins https:// and de-duplicate by URL. That is 15,746 distinct remote endpoints; dropping this operator’s own two leaves 15,744.
3. Draw sixty with Python random.seed(20260905) then random.sample, so the same sixty come out again.
4. Read each once through mcp_discovery_check between 16:05:50 and 16:07:13 UTC, clock read at each reading. A single reading at a single moment is all this is: a server that was down for that minute is recorded as down for that minute and nothing more is claimed about it.

Two of the sixty were not read, and the instrument refused them rather than guessing. This checker runs on Cloudflare Workers and cannot honestly read a *.workers.dev origin from inside that platform, so it declines instead of printing a reading it knows is wrong: https://context-keeper-remote.{account}.workers.dev/mcp/{token} and https://soar-api.nevada-f99.workers.dev/mcp. The first of those is worth noticing for another reason: its registry entry publishes a URL with the placeholders {account} and {token} still in it. Every count below is therefore out of 58, not sixty.

What came back

Among the 31 that listed tools, the smallest listing held 2 tools, the median 7, and the largest 49.

The 9 that answered neither are named here on their own, because a registry entry a client cannot connect to is worse for a reader than no entry at all: https://hiresignal-mcp-production-d4d9.up.railway.app/sse (404), https://mcp-api-ai.qovery.com/mcp?token={qovery_token} (404), https://lazareus.xyz/mcp (no answer), https://mcp.tradallo.com/mcp (no answer), https://server.smithery.ai/@keithah/tessie-mcp/mcp (404), https://mcp.letsvibe.love/mcp (404), https://logi-id.wishpool.app/mcp (530), https://server.smithery.ai/@BadRooBot/test_m/mcp (404), https://mcp.eruditepay.com/sse (530). Each was read once and any of them may have been healthy a minute earlier or later. One of them also still carries an unsubstituted {qovery_token} placeholder in the URL the registry publishes.

Discovery documents served 200

Nine paths were asked for at every endpoint. Any not listed here was served 200 by none of the 58.

The whole sample, named

What this is not

It is not a ranking, a score or a grade, and nothing here says a server is badly built. A 401 is a deliberate design choice and the second commonest answer in the sample. It is not a security test: no credential was tried, no tool was called on any target, and each endpoint was read exactly once. Sixty out of 15,744 is a sample, and every number above should be read as one.

Read your own endpoint

The same check runs free, in a browser, at /mcp-check, and as the mcp_discovery_check tool on this operator’s MCP server. It needs no key and no account, it calls no tool on the target, and it stores nothing. This operator sells two things, both about a domain’s mail authentication rather than about MCP: a $29 one-off audit and a $12 a month watch. Neither is what this page reads, and nothing on this page is behind either of them.