Un serveur MCP écrit pour fonctionner en stdio ne peut pas, sans adaptation, être exposé tel quel à un client distant qui s’attend à une URL HTTP : c’est le constat de départ qui pousse à comprendre précisément la différence entre les deux modes de transport prévus par le protocole, avant même d’écrire le premier outil exposé.
Le Model Context Protocol, publié fin 2024, définit deux mécanismes de transport principaux, avec des implications très différentes selon que le serveur tourne en local, à côté du client, ou qu’il est hébergé à distance, comme c’est le cas pour un serveur adossé à un site WordPress.
Le transport stdio, pensé pour l’exécution locale
Le transport stdio fait communiquer un client et un serveur MCP par les flux d’entrée et de sortie standard d’un même processus, lancé localement par le client. C’est le mode privilégié pour un outil de développement exécuté sur la machine du développeur : un éditeur de code qui lance un serveur MCP en tant que sous-processus, échange avec lui par ces flux, et le termine à la fin de la session.
Ce modèle suppose que le client dispose des droits nécessaires pour démarrer un processus, et que le serveur reste accessible uniquement depuis la machine où il tourne. Un hébergement web mutualisé, où le code PHP s’exécute à la demande sans processus persistant contrôlé par le visiteur, ne correspond pas à ce schéma.
Le transport HTTP en flux continu, pensé pour l’hébergement distant
Le second mode de transport repose sur des requêtes HTTP classiques, avec un flux d’événements en continu pour les réponses susceptibles de s’étaler dans le temps. Un serveur MCP exposé de cette façon se comporte, du point de vue de l’infrastructure, comme n’importe quelle route REST accessible par une URL publique, ce qui correspond directement à l’architecture d’un hébergement WordPress classique.
add_action( 'rest_api_init', function () {
register_rest_route( 'mcp/v1', '/message', array(
'methods' => 'POST',
'callback' => 'gerer_message_mcp',
'permission_callback' => 'verifier_client_mcp',
) );
} );
Ce que le flux continu implique côté serveur PHP
Le mode flux continu suppose qu’une connexion puisse rester ouverte le temps que le serveur produise sa réponse par morceaux, plutôt que de renvoyer tout le contenu en un seul bloc. En PHP, ce comportement demande de désactiver la mise en tampon de sortie et d’utiliser un envoi progressif via echo suivi de flush(), une configuration qui n’est pas garantie sur tous les hébergements mutualisés selon la manière dont le serveur web gère les processus PHP.
Ce que le choix du transport implique pour l’architecture
Décider du transport avant d’écrire les outils exposés évite de devoir réorganiser le serveur en cours de route. Un serveur destiné à rester local à un poste de développement peut légitimement s’écrire en stdio, tandis qu’un serveur destiné à être appelé par un agent distant, ou par un service tiers hébergé ailleurs, doit s’écrire en HTTP dès le départ.
- Serveur MCP interne, utilisé uniquement en local par un outil de développement : stdio
- Serveur MCP exposé à un client distant, hébergé sur le même serveur que le site WordPress : HTTP en flux continu
- Éviter de concevoir un serveur qui devrait supporter les deux modes sans nécessité identifiée
Ce que ce choix ne règle pas
Le transport détermine comment les messages circulent, pas qui a le droit de les envoyer. L’authentification du client, la validation des paramètres reçus dans chaque outil et la limitation du nombre d’appels restent des questions distinctes, à traiter indépendamment du mode de transport retenu.
Le transport choisi façonne l’architecture du serveur avant même d’écrire son premier outil : mieux vaut trancher cette question dès la phase de conception plutôt qu’en cours de développement.
Ce qu’il faut retenir
Pour un serveur MCP adossé à un hébergement WordPress classique, le transport HTTP en flux continu s’impose naturellement, dans la continuité de l’architecture REST déjà maîtrisée par la plupart des développeurs du cœur. Le transport stdio garde sa pertinence pour les usages strictement locaux, mais ne convient pas à un serveur destiné à être appelé depuis l’extérieur de la machine qui l’héberge.
