/sse 陷阱：387 台看起来坏了、其实没坏的服务器

MCP 用两种不同的方式说 HTTP，而且两者不能互换。Streamable HTTP 直接把 JSON-RPC 发到一个端点。更早的 HTTP+SSE 传输则完全不同：你先打开一条流，服务器再告诉你该往哪里发。

出错时是什么样子

如果你把 initialize 请求发到一个 HTTP+SSE 端点，你不会收到错误，而是收到这个：

HTTP 200
content-type: text/event-stream

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

200 OK。没有错误码，没有抱怨。只有一句礼貌的提示：「真正的端点在那边。」而没有预期到这一点的客户端，会把它读成空响应。

陷阱就在这里。返回成功的失败，比返回 500 的失败难发现得多。

我们自己也掉进去了

我们把读不出来的服务器归类为「unknown」。当我们去查这一类为什么这么大时，发现有 387 台其实是 HTTP+SSE 端点，而我们一直在用错误的方式请求它们。在 URL 以 /sse 结尾的服务器里，84% 被标为 unknown——而整个目录的比例是 10%。八倍的差距不是巧合，是指纹。

那些服务器一直都好好的。说错协议的是我们。

如何避免

• 把「返回 200 但 JSON-RPC 主体为空或无法解析」当作传输方式不匹配，而不是服务器已死。
• 如果响应的内容类型是 text/event-stream，且第一个事件名为 endpoint，就跟随它，把请求发到那里。
• 不要只信 URL。以 /sse 结尾只是线索，不是保证——而且很多 HTTP+SSE 端点根本不以 /sse 结尾。

如果你发布服务器，最省事的办法是在注册表条目里写清自己使用哪种传输。大多数客户端会相信你。