Transports Streaming HTTP et SSE

Les transports du MCP distant

Un transport, dans le contexte du MCP, définit comment votre application communique avec le serveur d’outils. xAI supporte deux transports pour le MCP distant : Streaming HTTP et SSE (Server-Sent Events). Ces deux protocoles fonctionnent sur HTTPS et permettent une communication en temps réel entre Grok et le serveur MCP.

Streaming HTTP

Le Streaming HTTP est le transport le plus récent du standard MCP. Il utilise des requêtes HTTP classiques avec une particularité : le serveur peut envoyer sa réponse en flux continu plutôt qu’en un seul bloc.

Le fonctionnement est le suivant :

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

Ce transport est adapté aux outils qui produisent des résultats volumineux ou dont le traitement prend du temps. Par exemple, un outil de recherche qui renvoie des résultats au fur et à mesure qu’il les trouve.

Avantages du Streaming HTTP

• Compatible avec la plupart des infrastructures web existantes
• Fonctionne bien derrière les load balancers et les proxies
• Pas de connexion persistante à maintenir
• Chaque appel d’outil est une requête indépendante

Server-Sent Events (SSE)

Le SSE est un protocole plus ancien dans l’écosystème MCP. Il établit une connexion persistante unidirectionnelle entre le serveur et le client. Le serveur peut envoyer des événements à tout moment sur cette connexion.

Le flux SSE pour le MCP fonctionne ainsi :

1. Le client ouvre une connexion SSE vers le serveur MCP
2. Le serveur garde cette connexion ouverte
3. Quand Grok appelle un outil, la requête part sur un endpoint séparé
4. Le résultat arrive via la connexion SSE déjà établie

Particularités du SSE

• La connexion reste ouverte entre les appels, ce qui réduit la latence sur les appels successifs
• Le serveur peut envoyer des notifications sans que le client ne les demande
• Plus sensible aux interruptions réseau et aux timeouts des proxies
• Nécessite une gestion de la reconnexion côté client

Quel transport choisir ?

En pratique, vous ne choisissez pas directement le transport. C’est le serveur MCP qui détermine le transport qu’il supporte. Quand vous configurez un serveur MCP dans l’API xAI, vous fournissez uniquement l’URL du serveur. L’API détecte automatiquement le transport utilisé.

La plupart des serveurs MCP publics récents utilisent le Streaming HTTP. Les serveurs plus anciens peuvent encore utiliser le SSE. Les deux fonctionnent de manière transparente avec l’API Grok.

Ce qui n’est pas supporté

Il est important de comprendre ce que xAI ne supporte pas pour le MCP distant :

• stdio : le transport standard input/output, utilisé pour les serveurs MCP locaux (par exemple dans Claude Desktop), n’est pas supporté. Vous ne pouvez pas connecter un serveur MCP qui tourne sur votre machine locale via stdio
• HTTP en clair : toutes les connexions doivent être en HTTPS. Un serveur accessible uniquement en HTTP sera refusé
• WebSocket : bien que certaines implémentations MCP utilisent WebSocket, l’API xAI ne le supporte pas comme transport MCP

Impact sur votre architecture

Le choix du transport par le serveur MCP a des implications pour votre architecture :

• Streaming HTTP : chaque appel d’outil est stateless. Si votre application tombe, elle peut reprendre sans reconfigurer la connexion MCP
• SSE : la connexion persistante peut se rompre. Votre application doit gérer la reconnexion et potentiellement le rejeu des appels en cours

Dans les deux cas, l’API xAI gère la connexion au serveur MCP. Vous n’avez pas à implémenter le protocole de transport vous-même — il suffit de fournir l’URL du serveur.

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