La trampa /sse: 387 servidores que parecen rotos y no lo están

MCP habla HTTP de dos maneras distintas, y no son intercambiables. Streamable HTTP envía JSON-RPC directamente a un endpoint. El transporte más antiguo, HTTP+SSE, funciona de otro modo: primero abres un flujo y el servidor te dice dónde enviar.

Qué aspecto tiene el fallo

Si envías una petición initialize a un endpoint HTTP+SSE, no recibes un error. Recibes esto:

HTTP 200
content-type: text/event-stream

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

Doscientos OK. Sin código de error, sin queja. Solo una nota cortés que dice "el endpoint real está allí" — y un cliente que no lo espera lo leerá como una respuesta vacía.

Ahí está la trampa. Un fallo que devuelve éxito es mucho más difícil de detectar que uno que devuelve 500.

Nosotros mismos caímos

A los servidores que no podemos leer los clasificamos como "unknown". Al investigar por qué ese grupo era tan grande, resultó que 387 eran endpoints HTTP+SSE a los que enviábamos peticiones de forma incorrecta. Entre los servidores cuya URL termina en /sse, el 84% estaba marcado como unknown, frente al 10% del catálogo entero. Ocho veces la tasa no es casualidad: es una huella.

Esos servidores estuvieron bien todo el tiempo. Los que hablábamos el protocolo equivocado éramos nosotros.

Cómo evitarlo

• Trata un 200 con cuerpo JSON-RPC vacío o ilegible como un desajuste de transporte, no como un servidor muerto.
• Si el tipo de contenido es text/event-stream y el primer evento se llama endpoint, síguelo y envía allí la petición.
• No te fíes solo de la URL. Terminar en /sse es una pista, no una garantía — y muchos endpoints HTTP+SSE no terminan en /sse.

Si publicas un servidor, lo más barato es declarar qué transporte hablas en tu entrada del registro. La mayoría de clientes te creerá.