Transports des serveurs MCP
MCP prend en charge des mécanismes de transport pour la communication entre Bob Shell et les serveurs MCP.
Vue d'ensemble
MCP propose trois options de transport, chacune adaptée à différents scénarios de déploiement :
- Transport STDIO (serveurs locaux)
- Transport HTTP streamable (standard moderne pour les serveurs distants)
- Transport SSE (option distante héritée)
Chaque transport a des caractéristiques, des avantages et des cas d'usage distincts.
Transport STDIO
Le transport STDIO s'exécute localement sur votre machine et communique via des flux d'entrée/sortie standard.
Fonctionnement du transport STDIO
- Bob lance un serveur MCP comme processus enfant
- La communication se fait via les flux de processus : Bob écrit sur le STDIN du serveur, le serveur répond sur STDOUT
- Chaque message est délimité par un caractère de nouvelle ligne
- Les messages sont formatés en JSON-RPC 2.0
Client Serveur
| |
|---- message JSON ------>| (via STDIN)
| | (traitement de la requête)
|<---- message JSON ------| (via STDOUT)
| |Caractéristiques de STDIO
- Localité : S'exécute sur la même machine que Bob
- Performance : Très faible latence et faible surcharge (pas de pile réseau)
- Simplicité : Communication directe entre processus sans configuration réseau
- Relation : Relation un-à-un entre client et serveur
- Sécurité : Intrinsèquement plus sécurisé sans exposition réseau
Quand utiliser STDIO
Le transport STDIO est idéal pour :
- Les intégrations locales et les outils fonctionnant sur la même machine
- Les opérations sensibles en termes de sécurité
- Les exigences de faible latence
- Les scénarios à client unique (une instance Bob par serveur)
- Les outils en ligne de commande et les scripts
Exemple d'implémentation STDIO
const server = new Server({name: 'local-server', version: '1.0.0'});
// Enregistrement des outils...
// Utilisation du transport STDIO
const transport = new StdioServerTransport(server);
transport.listen();Transport HTTP streamable
Le transport HTTP streamable est le standard moderne pour la communication avec les serveurs MCP distants, remplaçant l'ancien transport HTTP+SSE. Il fonctionne sur HTTP/HTTPS et permet des implémentations de serveurs plus flexibles.
Fonctionnement du transport HTTP streamable
- Le serveur expose un endpoint HTTP unique (endpoint MCP) qui prend en charge les méthodes POST et GET
- Bob envoie des requêtes à cet endpoint MCP via HTTP POST
- Le serveur traite la requête et renvoie une réponse
- Optionnellement, le serveur peut utiliser les Server-Sent Events (SSE) sur la même connexion pour diffuser plusieurs messages ou notifications vers Bob
Cela permet des interactions requête-réponse simples ainsi que des communications plus avancées avec streaming et initiation par le serveur.
Client Serveur
| |
|---- HTTP POST /mcp_endpoint ---->| (requête client)
| | (traitement de la requête)
|<--- Réponse HTTP / Flux SSE -----| (réponse / flux serveur)
| |Caractéristiques du transport HTTP streamable
- Standard moderne : Méthode recommandée pour les nouvelles implémentations de serveurs MCP distants
- Accès distant : Peut être hébergé sur une machine différente de Bob
- Scalabilité : Peut gérer plusieurs connexions clients simultanément
- Protocole : Fonctionne sur HTTP/HTTPS standard
- Flexibilité : Prend en charge les requêtes-réponses simples et le streaming avancé
- Endpoint unique : Utilise un seul chemin URL pour toutes les communications MCP
- Authentification : Peut utiliser les mécanismes d'authentification HTTP standard
- Compatibilité ascendante : Les serveurs peuvent maintenir la compatibilité avec les anciens clients HTTP+SSE
Quand utiliser le transport HTTP streamable
Le transport HTTP streamable est idéal pour :
- Tous les nouveaux développements de serveurs MCP distants
- Les serveurs nécessitant une communication robuste, scalable et flexible
- Les intégrations pouvant impliquer le streaming de données ou des notifications serveur
- Les services publics ou les outils centralisés
- Le remplacement des implémentations de transport SSE héritées
Exemple d'implémentation HTTP streamable
Configuration dans ~/.bob/mcp_settings.json (global) ou .bob/mcp.json (projet) :
{
"mcpServers": {
"NomMCPHTTPStreamable": {
"httpURL": "http://localhost:8080/mcp"
}
}
}Pour l'implémentation côté serveur, consultez la documentation du SDK MCP pour StreamableHTTPClientTransport.
Compatibilité ascendante avec HTTP+SSE
Les clients et serveurs peuvent maintenir la compatibilité ascendante avec le transport HTTP+SSE déprécié.
Les serveurs souhaitant prendre en charge les anciens clients doivent continuer à héberger les endpoints SSE (/events) et POST (/message) de l'ancien transport, en plus du nouvel endpoint MCP défini pour le transport HTTP streamable.
Transport SSE (hérité)
Le transport Server-Sent Events (SSE) s'exécute sur un serveur distant et communique via HTTP/HTTPS. Pour les nouveaux serveurs distants, utilisez plutôt le transport HTTP streamable.
Fonctionnement du transport SSE
- Bob se connecte à l'endpoint SSE du serveur via une requête HTTP GET
- Cela établit une connexion persistante via laquelle le serveur peut envoyer des événements à Bob
- Pour la communication client vers serveur, Bob effectue des requêtes HTTP POST vers un endpoint séparé
- La communication s'effectue sur deux canaux :
- Flux d'événements (GET) : Mises à jour serveur vers client
- Endpoint de message (POST) : Requêtes client vers serveur
Client Serveur
| |
|---- HTTP GET /events ----------->| (établir la connexion SSE)
|<---- flux d'événements SSE ------| (connexion persistante)
| |
|---- HTTP POST /message --------->| (requête client)
|<---- événement SSE avec réponse -| (réponse serveur)
| |Caractéristiques de SSE
- Accès distant : Peut être hébergé sur une machine différente de Bob
- Scalabilité : Peut gérer plusieurs connexions clients simultanément
- Protocole : Fonctionne sur HTTP standard (pas de protocoles spéciaux requis)
- Persistance : Maintient une connexion persistante pour les messages serveur vers client
- Authentification : Peut utiliser les mécanismes d'authentification HTTP standard
Quand utiliser SSE
Le transport SSE convient pour :
- L'accès distant sur les réseaux
- Les scénarios multi-clients
- Les services publics
- Les outils centralisés auxquels de nombreux utilisateurs doivent accéder
- L'intégration avec des services web
Exemple d'implémentation SSE
import express from 'express';
const app = express();
const server = new Server({name: 'remote-server', version: '1.0.0'});
// Enregistrement des outils...
// Utilisation du transport SSE
const transport = new SSEServerTransport(server);
app.use('/mcp', transport.requestHandler());
app.listen(3000, () => {
console.log('Serveur MCP en écoute sur le port 3000');
});Considérations de déploiement
Le choix entre STDIO et les transports distants (HTTP streamable ou SSE) impacte directement la façon dont vous déployez et gérez vos serveurs MCP.
STDIO : Déploiement local
Les serveurs STDIO s'exécutent localement sur la même machine que Bob :
- Installation : L'exécutable du serveur doit être installé sur chaque machine utilisateur
- Distribution : Vous devez fournir des packages d'installation pour différents systèmes d'exploitation
- Mises à jour : Chaque instance doit être mise à jour séparément
- Ressources : Utilise le CPU, la mémoire et le disque de la machine locale
- Contrôle d'accès : S'appuie sur les permissions du système de fichiers de la machine locale
- Intégration : Intégration facile avec les ressources système locales (fichiers, processus)
- Exécution : Démarre et s'arrête avec Bob (cycle de vie du processus enfant)
- Dépendances : Toutes les dépendances doivent être installées sur la machine de l'utilisateur
Exemple de cas d'usage :
Un outil de recherche de fichiers local utilisant STDIO :
- S'exécute sur votre machine
- A un accès direct au système de fichiers local
- Démarre quand Bob en a besoin
- Ne nécessite pas de configuration réseau
- Doit être installé avec Bob ou via un gestionnaire de packages
Distant : Déploiement hébergé
Les serveurs distants (HTTP streamable ou SSE) peuvent être déployés sur des serveurs distants et accessibles via le réseau :
- Installation : Installé une fois sur un serveur, accessible par de nombreux utilisateurs
- Distribution : Un seul déploiement sert plusieurs clients
- Mises à jour : Les mises à jour centralisées affectent immédiatement tous les utilisateurs
- Ressources : Utilise les ressources du serveur, pas les ressources de la machine locale
- Contrôle d'accès : Géré via des systèmes d'authentification et d'autorisation
- Intégration : Intégration plus complexe avec les ressources spécifiques à l'utilisateur
- Exécution : Fonctionne comme un service indépendant (souvent en continu)
- Dépendances : Gérées sur le serveur, pas sur les machines des utilisateurs
Exemple de cas d'usage :
Un outil de requête de base de données utilisant un transport distant :
- S'exécute sur un serveur central
- Se connecte aux bases de données avec des identifiants côté serveur
- Est disponible en permanence pour plusieurs utilisateurs
- Nécessite une configuration de sécurité réseau appropriée
- Est déployé à l'aide de technologies de conteneurs ou cloud
Approches hybrides
Certains scénarios bénéficient d'une approche hybride :
- STDIO avec accès réseau : Un serveur STDIO local agissant comme proxy vers des services distants
- Distant avec commandes locales : Un serveur distant pouvant déclencher des opérations sur la machine cliente via des callbacks
- Modèle passerelle : Serveurs STDIO pour les opérations locales qui se connectent à des serveurs distants pour des fonctions spécialisées
Comparaison des transports
| Critère | STDIO | HTTP streamable / SSE |
|---|---|---|
| Emplacement | Machine locale uniquement | Local ou distant |
| Clients | Client unique | Plusieurs clients |
| Performance | Faible latence | Latence plus élevée (surcharge réseau) |
| Complexité de configuration | Plus simple | Plus complexe (serveur HTTP requis) |
| Sécurité | Intrinsèquement sécurisé | Nécessite des mesures de sécurité explicites |
| Accès réseau | Non requis | Requis |
| Scalabilité | Limitée à la machine locale | Peut se distribuer sur le réseau |
| Déploiement | Installation par utilisateur | Installation centralisée |
| Mises à jour | Mises à jour distribuées | Mises à jour centralisées |
| Utilisation des ressources | Ressources client | Ressources serveur |
| Dépendances | Dépendances côté client | Dépendances côté serveur |
Configurer les transports dans Bob Shell
Pour des informations détaillées sur la configuration des transports dans Bob Shell, y compris des exemples de configuration, consultez MCP dans Bob Shell.