Le piège /sse : 387 serveurs qui semblent cassés sans l'être

MCP parle HTTP de deux façons différentes, et elles ne sont pas interchangeables. Streamable HTTP envoie le JSON-RPC directement vers un endpoint. Le transport plus ancien, HTTP+SSE, fonctionne autrement : vous ouvrez d'abord un flux, puis le serveur vous indique où envoyer.

À quoi ressemble l'échec

Si vous envoyez une requête initialize à un endpoint HTTP+SSE, vous n'obtenez pas d'erreur. Vous obtenez ceci :

HTTP 200
content-type: text/event-stream

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

Deux cents OK. Aucun code d'erreur, aucune protestation. Juste une note polie : « le vrai endpoint est là-bas » — et un client qui ne s'y attend pas la lira comme une réponse vide.

Le piège est là. Un échec qui renvoie un succès est bien plus difficile à repérer qu'un échec qui renvoie 500.

Nous y sommes tombés nous-mêmes

Les serveurs que nous n'arrivons pas à lire sont classés « unknown ». En cherchant pourquoi cette catégorie était si grande, il s'est avéré que 387 d'entre eux étaient des endpoints HTTP+SSE que nous interrogions de travers. Parmi les serveurs dont l'URL se termine par /sse, 84 % étaient marqués unknown — contre 10 % sur l'ensemble du catalogue. Huit fois le taux, ce n'est pas une coïncidence : c'est une empreinte.

Ces serveurs allaient très bien depuis le début. C'est nous qui parlions le mauvais protocole.

Comment l'éviter

• Traitez un 200 dont le corps JSON-RPC est vide ou illisible comme une incompatibilité de transport, pas comme un serveur mort.
• Si le type de contenu est text/event-stream et que le premier événement s'appelle endpoint, suivez-le et envoyez la requête là-bas.
• Ne vous fiez pas à la seule URL. Se terminer par /sse est un indice, pas une garantie — et beaucoup d'endpoints HTTP+SSE ne finissent pas par /sse.

Si vous publiez un serveur, le plus économique est de déclarer le transport que vous parlez dans votre entrée de registre. La plupart des clients vous croiront.