The /sse trap: 387 servers that look broken but are not

MCP speaks HTTP in two different ways, and they are not interchangeable. Streamable HTTP posts JSON-RPC straight at one endpoint. The older HTTP+SSE transport does something else entirely: you open a stream first, and the server tells you where to post.

What going wrong looks like

If you post an initialize request at an HTTP+SSE endpoint, you do not get an error. You get this:

HTTP 200
content-type: text/event-stream

event: endpoint
data: https://example.com/my-mcp/api/process

Two hundred OK. No error code, no complaint. Just a polite note saying "the actual endpoint is over there" — which a client that is not expecting it will read as an empty response.

That is the trap. A failure that returns success is much harder to notice than a failure that returns 500.

We fell into it ourselves

We classify servers we cannot read as "unknown". When we looked at why that bucket was so large, 387 servers turned out to be HTTP+SSE endpoints we had been posting at incorrectly. Among servers whose URL ends in /sse, 84% were marked unknown — against 10% across the catalog. Eight times the rate is not a coincidence; it is a fingerprint.

Those servers were fine the whole time. We were the ones speaking the wrong protocol.

How to avoid it

• Treat a 200 with an empty or unparseable JSON-RPC body as a transport mismatch, not as a dead server.
• If the response content type is text/event-stream and the first event is named endpoint, follow it and post there instead.
• Do not trust the URL alone. A path ending in /sse is a hint, not a guarantee — and plenty of HTTP+SSE endpoints do not end in /sse at all.

If you publish a server, the cheapest fix is to say which transport you speak in your registry entry. Most clients will believe you.