Transports Streaming HTTP et SSE

Ce qu’un transport recouvre exactement

Dans le vocabulaire du MCP, le transport désigne la manière dont votre application et le serveur d’outils s’échangent physiquement des messages. Ce n’est pas un détail d’implémentation anodin : il détermine si la connexion reste ouverte entre deux appels, comment le résultat vous parvient, et ce qui se passe quand un proxy décide de couper. xAI en supporte deux pour le MCP distant, le Streaming HTTP et le SSE (Server-Sent Events), tous deux sur HTTPS.

Streaming HTTP, le transport moderne

Le Streaming HTTP est le plus récent des deux dans le standard MCP. Il s’appuie sur des requêtes HTTP tout à fait ordinaires, avec une nuance : le serveur peut renvoyer sa réponse en flux continu au lieu d’attendre d’avoir tout calculé pour émettre un bloc unique. Le déroulé d’un appel se lit en quatre temps.

1. Grok envoie une requête POST au serveur MCP avec les paramètres de l’outil à appeler
2. Le serveur commence à traiter la requête
3. La réponse arrive progressivement, morceau par morceau
4. La connexion se ferme une fois la réponse complète

Cette mécanique prend tout son sens sur les outils lents ou verbeux. Prenez un outil de recherche qui balaie un corpus documentaire : plutôt que de faire patienter le modèle jusqu’au dernier résultat, il émet ses trouvailles au fil de l’eau. Côté infrastructure, le Streaming HTTP se comporte comme du trafic web classique, ce qui explique qu’il traverse sans difficulté les load balancers et les proxies d’entreprise. Chaque appel d’outil étant une requête indépendante, il n’y a aucune connexion persistante à surveiller.

Server-Sent Events, l’approche par connexion ouverte

Le SSE est le vétéran de l’écosystème MCP. Il repose sur une connexion persistante et unidirectionnelle : le client l’ouvre vers le serveur, le serveur la garde ouverte et y pousse des événements quand il en a. Dans le contexte MCP, l’appel d’outil part sur un endpoint séparé, et c’est par le canal SSE déjà établi que le résultat revient.

Ce fonctionnement a un avantage réel et un défaut symétrique. L’avantage : la connexion étant déjà là, les appels successifs n’ont pas à repayer le coût d’établissement, et le serveur peut émettre des notifications sans que le client les ait demandées. Le défaut : une connexion longue est une connexion fragile. Un proxy qui applique un timeout, une coupure réseau de deux secondes, et le canal tombe. Une implémentation SSE sérieuse doit donc prévoir sa logique de reconnexion.

Vous ne choisissez pas, vous héritez

Voici le point qui surprend souvent : vous ne sélectionnez pas le transport. C’est le serveur MCP qui impose celui qu’il implémente. Quand vous configurez un serveur dans l’API xAI, vous ne fournissez que son URL, et l’API détecte seule le transport en vigueur. Il n’existe aucun paramètre pour forcer l’un plutôt que l’autre.

En pratique, la plupart des serveurs MCP publics récents ont adopté le Streaming HTTP ; les plus anciens restent en SSE. Les deux fonctionnent de manière transparente avec l’API Grok, et vous n’aurez généralement aucun moyen de savoir lequel est utilisé sans regarder la documentation du serveur.

Ce que xAI ne supporte pas

Trois transports vus ailleurs dans l’écosystème MCP sont hors jeu ici, et méconnaître cette liste est la cause la plus fréquente d’un premier essai raté. Le transport stdio, utilisé par les serveurs MCP locaux comme ceux que l’on branche à Claude Desktop, n’est pas accepté : un serveur qui tourne sur votre machine et communique par entrée/sortie standard ne peut pas être connecté à Grok. Le HTTP en clair est refusé sans exception, tout doit passer en HTTPS. Le WebSocket, que certaines implémentations MCP emploient, n’est pas non plus reconnu comme transport MCP par l’API xAI.

Les conséquences sur votre architecture

Le transport imposé par le serveur retentit sur la robustesse de votre application. Avec le Streaming HTTP, chaque appel étant stateless, un redémarrage de votre service ne laisse rien de cassé derrière lui : la prochaine requête repart de zéro et tout fonctionne. Avec le SSE, la connexion persistante peut se rompre en cours de route, et vous devez décider ce qu’il advient d’un appel parti mais dont le résultat n’est jamais revenu — le rejouer, l’abandonner, remonter une erreur à l’utilisateur.

Rassurez-vous néanmoins : dans les deux cas, c’est l’API xAI qui gère la connexion au serveur MCP, pas vous. Vous n’implémentez ni le protocole ni la reconnexion vous-même. Il suffit de fournir l’URL du serveur, et ces considérations n’affectent que la façon dont vous interprétez une erreur ou dimensionnez vos timeouts applicatifs.

Points clés à retenir

• xAI supporte deux transports MCP : Streaming HTTP et SSE, tous deux sur HTTPS
• Le Streaming HTTP est le transport moderne, stateless et compatible avec l’infrastructure web standard
• Le SSE maintient une connexion persistante, utile pour les appels fréquents mais plus fragile
• Le transport est déterminé par le serveur MCP, pas par votre configuration
• stdio, HTTP en clair et WebSocket ne sont pas supportés pour le MCP distant