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

O MCP fala HTTP de duas maneiras diferentes, e elas não são intercambiáveis. O Streamable HTTP envia JSON-RPC diretamente para um endpoint. O transporte mais antigo, HTTP+SSE, funciona de outra forma: primeiro abre-se um fluxo e o servidor diz para onde enviar.

Como é a falha

Se enviar um pedido initialize para um endpoint HTTP+SSE, não recebe um 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 queixa. Apenas um aviso educado: "o endpoint verdadeiro está ali" — e um cliente que não está à espera disso vai lê-lo como resposta vazia.

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

Também caímos nela

Os servidores que não conseguimos ler são classificados como "unknown". Ao investigar porque esse grupo era tão grande, descobrimos que 387 eram endpoints HTTP+SSE aos quais enviávamos pedidos de forma errada. Entre os servidores cujo URL termina em /sse, 84% estavam marcados como unknown — contra 10% em todo o catálogo. Oito vezes a taxa não é coincidência: é uma impressão digital.

Aqueles servidores estiveram sempre bem. 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 tipo de conteúdo for text/event-stream e o primeiro evento se chamar endpoint, siga-o e envie o pedido para lá.
• Não confie apenas no URL. Terminar em /sse é uma pista, não uma garantia — e muitos endpoints HTTP+SSE não terminam em /sse.

Se publica um servidor, o mais barato é declarar que transporte fala na sua entrada do registo. A maioria dos clientes vai acreditar.