Les indicateurs stateless_http et json_response des serveurs MCP contrôlent des aspects fondamentaux du comportement de votre serveur. Comprendre quand et pourquoi les utiliser est essentiel, en particulier si vous envisagez de faire évoluer votre serveur ou de le déployer en production.
Quand vous avez besoin de HTTP sans état
Imaginez que vous créez un serveur MCP qui devient populaire. Au départ, vous n'avez peut-être que quelques clients se connectant à une seule instance de serveur :
À mesure que votre serveur se développe, vous pourriez avoir des milliers de clients essayant de se connecter. L'exécution d'une seule instance de serveur ne pourra pas évoluer pour gérer tout ce trafic :
La solution typique est la mise à l'échelle horizontale - l'exécution de plusieurs instances de serveur derrière un équilibreur de charge :
Mais c'est là que les choses se compliquent. Rappelez-vous que les clients MCP ont besoin de deux connexions distinctes :
- Une connexion GET SSE pour recevoir les requêtes du serveur vers le client
- Des requêtes POST pour appeler des outils et recevoir des réponses
Avec un équilibreur de charge, ces requêtes peuvent être acheminées vers différentes instances de serveur. Si votre outil a besoin d'utiliser Claude (via l'échantillonnage), le serveur traitant la requête POST devrait se coordonner avec le serveur gérant la connexion GET SSE. Cela crée un problème de coordination complexe entre les serveurs.
Comment le HTTP sans état résout ce problème
Définir stateless_http=True élimine ce problème de coordination, mais avec des compromis importants :
Lorsque le HTTP sans état est activé :
- Les clients n'obtiennent pas d'identifiants de session - le serveur ne peut pas suivre les clients individuels
- Aucune requête du serveur vers le client - le canal GET SSE devient indisponible
- Aucun échantillonnage - impossible d'utiliser Claude ou d'autres modèles d'IA
- Aucun rapport de progression - impossible d'envoyer des mises à jour de progression pendant les opérations longues
- Aucun abonnement - impossible de notifier les clients des mises à jour de ressources
Cependant, il y a un avantage : l'initialisation du client n'est plus nécessaire. Les clients peuvent effectuer des requêtes directement sans le processus de prise de contact initial.
Comprendre la réponse JSON
L'indicateur json_response=True est plus simple - il désactive simplement le streaming pour les réponses aux requêtes POST. Au lieu d'obtenir plusieurs messages SSE pendant l'exécution d'un outil, vous n'obtenez que le résultat final sous forme de JSON brut.
Avec le streaming désactivé :
- Aucun message de progression intermédiaire
- Aucune instruction de journalisation pendant l'exécution
- Uniquement le résultat final de l'outil
Quand utiliser ces indicateurs
Utilisez le HTTP sans état lorsque :
- Vous avez besoin d'une mise à l'échelle horizontale avec des équilibreurs de charge
- Vous n'avez pas besoin de communication du serveur vers le client
- Vos outils ne nécessitent pas d'échantillonnage de modèle d'IA
- Vous souhaitez minimiser la surcharge de connexion
Utilisez la réponse JSON lorsque :
- Vous n'avez pas besoin de réponses en streaming
- Vous préférez des réponses HTTP plus simples, sans streaming
- Vous intégrez des systèmes qui attendent du JSON brut
Développement vs production
Si vous développez localement avec le transport d'entrée/sortie standard mais que vous prévoyez de déployer avec le transport HTTP, testez avec le même transport que celui que vous utiliserez en production. Les différences de comportement entre les modes avec état et sans état peuvent être importantes, et il vaut mieux détecter les problèmes éventuels pendant le développement plutôt qu'après le déploiement.
Ces indicateurs modifient fondamentalement le fonctionnement de votre serveur MCP, choisissez-les donc en fonction de vos besoins spécifiques en matière de mise à l'échelle et de fonctionnalités.