We Health-Checked 86 Public MCP Servers. Not One Uses the Legacy Transport.

Merlonix — Thu, 13 Aug 2026 18:28:24 +0000

We keep a directory of public remote MCP servers and re-check every one of them through the same health checker that powers our free MCP health tool. It sends a real JSON-RPC initialize handshake, follows up with tools/list where it can, and records what came back.

This post is the aggregate. Every number below comes from one snapshot run at 2026-08-04T00:45:56Z against 86 reachable public remote MCP endpoints — the servers in the directory that answered at the transport layer. Nothing here is modelled, sampled or estimated.

One caveat worth stating before the numbers rather than after: 86 endpoints is a curated set of well-known public servers, not a random sample of the ecosystem. It is biased toward servers that vendors publish and maintain. Read everything below as "what the visible, vendor-published part of the remote MCP ecosystem looks like", not "what all MCP servers look like".

The headline: legacy HTTP+SSE is gone

Transport	Servers
Streamable HTTP	86
Legacy HTTP+SSE	0

Not "mostly". Not "a long tail remains". Zero out of 86.

This matters because the legacy two-endpoint HTTP+SSE transport — the one from the original 2024-11-05 spec revision, where you GET an SSE stream, wait for an endpoint event, and POST your requests somewhere else — is still taught by a meaningful number of tutorials and blog posts that read as current. If you are building a server today and following one of those, you are implementing a transport that, in this sample, precisely nobody still serves.

We wrote up how the two transports differ on the wire separately. The short version for server authors: single endpoint, POST your JSON-RPC message, get the answer in the POST response.

We got this number wrong the first time

The honest part of the methodology, because it changes how you should read the table above.

Before we published this, our own classifier said 11 of these servers were legacy SSE. They were not. The bug was ours, and it is an easy one to make: our checker treated an SSE-framed response as evidence of the legacy transport.

That inference is wrong. Streamable HTTP explicitly permits a server to answer a POST with Content-Type: text/event-stream — SSE framing is an allowed response encoding within a normal request/response cycle. It has nothing to do with the legacy split-channel design. A server can be entirely modern and still hand you an event stream.

The actual signal for the legacy transport is the server refusing the single-endpoint model: a 405 on POST to the advertised URL, or a redirect to a separate SSE endpoint. Once we classified on that instead, all 11 reclassified to Streamable HTTP and the legacy count went to zero.

If you are writing anything that detects MCP transports — a client, a registry, a monitor — check which signal you are keying on. "The response was text/event-stream" will mislabel modern servers as legacy, and it will do it quietly.

Most public MCP servers are not open

Handshake result	Servers
Completed `initialize` without credentials	12
Returned 401/403 — reachable, healthy, credential required	74

86% of these public servers require authentication to do anything at all. They are listed publicly, they are up, and they will not talk to you without a token.

This is the single most common thing people get wrong when they wire up MCP monitoring, and it is worth being blunt about: a 401 is not an outage. It means the server is healthy and you are missing a credential. If your monitoring collapses "401" and "down" into the same red state, you will page yourself for expired tokens and, worse, learn to ignore the alert that eventually means a real outage. They need to be separate states with separate responses.

The corollary for directory operators: if you list remote MCP servers and claim to show live status, most of your entries are ones you cannot fully check. Say so. We mark auth-required servers distinctly rather than pretending a credentialed check happened.

Everyone who negotiated a version negotiated the same one

All 12 servers that completed the handshake reported protocolVersion 2025-06-18. Twelve out of twelve.

Notably, zero answered on the newer stateless 2026-07-28 revision — the one that removes the initialize handshake entirely (SEP-2575) and drops Mcp-Session-Id (SEP-2567). Our checker specifically probes for it: if initialize is refused but a direct tools/list works, that is a stateless-generation server and we record it as healthy rather than broken. Nothing in this set has migrated yet.

So the practical state of remote MCP right now is a monoculture: one transport, one negotiated revision. That is genuinely good news for anyone writing a client. It will not last, and the stateless revision is the thing to watch — a client that treats a refused initialize as a fatal error will start reporting false outages the moment servers begin moving.

Handshake latency

Round-trip time for the initialize POST, across all 86:

	ms
Fastest	14
Median	115
90th percentile	260
Slowest	1,008

A second to complete a handshake is not "down", and it will not trip any uptime check. It is also a full second added to the front of every agent interaction that touches that server, before a single tool has been called. If you operate a server, handshake latency is a user-facing number and worth alerting on separately from availability.

Tool surfaces are small

Of the 12 servers we could enumerate without credentials, the total tool count was 33 — a median of 2.5 tools each, ranging from 1 to 6.

We would not generalise this to the whole ecosystem; the servers you can call anonymously skew toward narrow, read-only utilities, and the big authenticated platform servers behind the other 74 endpoints are where the 60-and-200-tool surfaces live. But it is a useful counterweight to the assumption that an MCP server means a large tool catalogue. Plenty of useful ones do one thing.

What the directory covers

The 86 servers span 17 categories, most heavily: Web & data (12), Dev & code (11), Observability (10), Productivity (9), Databases (7).

Reproduce any of this

Every number here came from an endpoint anyone can probe. Do it yourself in one command:

curl -sX POST https://your-mcp-server.example/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
        "protocolVersion":"2025-06-18","capabilities":{},
        "clientInfo":{"name":"curl","version":"1"}}}'

A result containing protocolVersion and serverInfo means a live MCP server. A 405 means legacy transport. A 401 means healthy-but-credentialed. An HTML body means something is answering that is not an MCP server at all.

Full methodology and the continuously re-checked directory live at merlonix.com/mcp-directory. You can run the same handshake against your own server with the free MCP health check, or over MCP itself: https://api.merlonix.com/mcp.

Snapshot: 2026-08-04T00:45:56Z, 86 reachable public remote MCP endpoints. These are point-in-time results, not real-time. If you run one of these servers and think we have measured it wrong, tell us — we would rather fix the checker than defend a number.

DEV Community: Merlonix