A armadilha /sse: 387 servidores que parecem quebrados mas não estão

O MCP fala HTTP de dois jeitos diferentes, e eles não são intercambiáveis. O Streamable HTTP manda JSON-RPC direto para um endpoint. O transporte mais antigo, HTTP+SSE, funciona de outro jeito: primeiro você abre um stream e o servidor diz para onde mandar.

Como a falha aparece

Se você mandar um initialize para um endpoint HTTP+SSE, não recebe erro. Recebe isto:

HTTP 200
content-type: text/event-stream

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

Duzentos OK. Sem código de erro, sem reclamação. Só um aviso educado: "o endpoint de verdade está ali" — e um cliente que não espera isso vai ler como resposta vazia.

A armadilha é essa. Uma falha que devolve sucesso é muito mais difícil de perceber do que uma que devolve 500.

Nós também caímos

Servidores que não conseguimos ler viram "unknown". Quando fomos ver por que essa categoria estava tão grande, 387 deles eram endpoints HTTP+SSE que estávamos chamando errado. Entre os servidores cuja URL termina em /sse, 84% estavam marcados como unknown — contra 10% no catálogo inteiro. Oito vezes a taxa não é coincidência: é impressão digital.

Aqueles servidores estavam bem o tempo todo. Quem falava o protocolo errado éramos nós.

Como evitar

• Trate um 200 com corpo JSON-RPC vazio ou ilegível como incompatibilidade de transporte, não como servidor morto.
• Se o content type for text/event-stream e o primeiro evento se chamar endpoint, siga ele e mande a requisição para lá.
• Não confie só na URL. Terminar em /sse é pista, não garantia — e muitos endpoints HTTP+SSE não terminam em /sse.

Se você publica um servidor, o mais barato é declarar qual transporte você fala no seu registro. A maioria dos clientes vai acreditar.