Le transport HTTP en streaming permet aux clients MCP de se connecter à des serveurs hébergés à distance via des connexions HTTP. Contrairement au transport d'entrée/sortie standard qui nécessite que le client et le serveur soient sur la même machine, ce transport ouvre des possibilités pour des serveurs MCP publics accessibles à tous.
Cependant, il existe une mise en garde importante : certains paramètres de configuration peuvent considérablement limiter les fonctionnalités de votre serveur MCP. Si votre application fonctionne parfaitement avec le transport d'entrée/sortie standard en local mais se casse lors du déploiement avec le transport HTTP, c'est probablement la cause.
Paramètres de configuration importants
Deux paramètres clés contrôlent le comportement du transport HTTP en streaming :
stateless_http- Contrôle la gestion de l'état de la connexionjson_response- Contrôle la gestion du format de réponse
Par défaut, ces deux paramètres sont à false, mais certains scénarios de déploiement peuvent vous obliger à les définir sur true. Lorsqu'ils sont activés, ces paramètres peuvent casser des fonctionnalités essentielles telles que les notifications de progression, la journalisation et les requêtes initiées par le serveur.
Le défi de la communication HTTP
Pour comprendre pourquoi ces limitations existent, il faut revoir le fonctionnement de la communication HTTP. En HTTP standard :
- Les clients peuvent facilement initier des requêtes vers les serveurs (le serveur a une URL connue)
- Les serveurs peuvent facilement répondre à ces requêtes
- Les serveurs ne peuvent pas facilement initier des requêtes vers les clients (les clients n'ont pas d'URL connue)
- Les schémas de réponse du client vers le serveur deviennent problématiques
Types de messages MCP concernés
Cette limitation HTTP affecte des schémas de communication MCP spécifiques. Les types de messages suivants deviennent difficiles à mettre en œuvre avec du HTTP simple :
- Requêtes initiées par le serveur : requêtes Create Message, requêtes List Roots
- Notifications : notifications de progression, notifications de journalisation, notifications Initialized, notifications Cancelled
Ce sont exactement les fonctionnalités qui se cassent lorsque vous activez les paramètres HTTP restrictifs. Les barres de progression disparaissent, la journalisation cesse de fonctionner, et les requêtes d'échantillonnage initiées par le serveur échouent.
La solution du transport HTTP en streaming
Le transport HTTP en streaming offre effectivement une solution astucieuse pour contourner les limitations de HTTP, mais elle comporte des compromis. Lorsque vous êtes contraint d'utiliser stateless_http=True ou json_response=True, vous demandez essentiellement au transport de fonctionner dans les contraintes de HTTP plutôt que de les contourner.
Comprendre ces limitations vous aide à prendre des décisions éclairées concernant :
- Le transport à utiliser pour différents scénarios de déploiement
- La manière de concevoir votre serveur MCP pour gérer avec élégance les contraintes HTTP
- Le moment où accepter une fonctionnalité réduite pour bénéficier de l'hébergement distant
L'essentiel est de savoir que ces restrictions existent et de planifier l'architecture de votre serveur MCP en conséquence. Si votre application dépend fortement des requêtes initiées par le serveur ou des notifications en temps réel, vous devrez peut-être reconsidérer votre choix de transport ou mettre en œuvre des schémas de communication alternatifs.