Transports de serveur MCP
MCP prend en charge des mécanismes de transport pour la communication entre Bob et les serveurs MCP.
Vue d'ensemble
MCP offre 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 (supprimé)
Chaque transport a des caractéristiques, des avantages et des cas d'utilisation différents.
Transport STDIO
Le transport STDIO s'exécute localement sur votre ordinateur et communique via des flux d'entrée/sortie standard.
Comment fonctionne le transport STDIO
- Bob démarre un serveur MCP en tant que processus enfant
- La communication se fait via des flux de processus : Bob écrit dans 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)
| | (traite la requête)
|<---- Message JSON ------| (via STDOUT)
| |Caractéristiques de STDIO
- Localité : S'exécute sur la même machine que Bob
- Performance : Latence et surcharge très faibles (pas de pile réseau impliquée)
- Simplicité : Communication de processus directe sans configuration réseau
- Relation : Relation un-à-un entre client et serveur
- Sécurité : Intrinsèquement plus sûr sans exposition réseau
Quand utiliser STDIO
Le transport STDIO est idéal pour :
- Les intégrations locales et les outils qui s'exécutent sur la même machine
- Les opérations critiques pour la sécurité
- Les exigences de faible latence
- Les scénarios à client unique (une instance Bob par serveur)
- Les outils en ligne de commande ou les extensions IDE
Exemple d'implémentation STDIO
const server = new Server({name: 'local-server', version: '1.0.0'});
// Enregistrer les outils...
// Utiliser le 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 via HTTP/HTTPS et permet des implémentations de serveur plus flexibles.
Comment fonctionne le transport HTTP streamable
- Le serveur expose un seul point de terminaison HTTP (point de terminaison MCP) qui prend en charge les méthodes POST et GET
- Bob envoie des requêtes à ce point de terminaison MCP avec HTTP POST
- Le serveur traite la requête et renvoie une réponse
- Optionnellement, le serveur peut utiliser Server-Sent Events (SSE) sur la même connexion pour diffuser plusieurs messages ou notifications à Bob
Cela permet à la fois des interactions de base requête-réponse et un streaming plus avancé et une communication initiée par le serveur.
Client Serveur
| |
|---- HTTP POST /mcp_endpoint ---->| (Requête client)
| | (traite la requête)
|<--- Réponse HTTP / Flux SSE -----| (Réponse / Flux serveur)
| |Caractéristiques du HTTP streamable
- Standard moderne : Méthode préférée pour les nouvelles implémentations de serveur MCP distant
- Accès distant : Peut être hébergé sur une machine différente de Bob
- Évolutivité : Peut gérer plusieurs connexions client simultanément
- Protocole : Fonctionne sur HTTP/HTTPS standard
- Flexibilité : Prend en charge la requête-réponse simple et le streaming avancé
- Point de terminaison unique : Utilise un seul chemin d'URL pour toute la communication MCP
- Authentification : Peut utiliser des mécanismes d'authentification HTTP standard
- Rétrocompatibilité : Les serveurs peuvent maintenir la compatibilité avec les anciens clients HTTP+SSE
Quand utiliser le HTTP streamable
Le transport HTTP streamable est idéal pour :
- Tous les nouveaux développements de serveur MCP distant
- Les serveurs nécessitant une communication robuste, évolutive et flexible
- Les intégrations pouvant impliquer des données en streaming ou des notifications envoyées par le serveur
- Les services publics ou les outils centralisés
- Le remplacement des implémentations de transport SSE legacy
Négociation de protocole
Lorsque Bob se connecte à un serveur HTTP streamable, il utilise l'option protocolNegotiation pour déterminer comment s'accorder sur une version de protocole. Les serveurs HTTP utilisent "auto" par défaut.
| Valeur | Description |
|---|---|
"auto" | Bob envoie une sonde server/discover avant initialize pour négocier la version de protocole mutuellement supportée la plus élevée. Par défaut pour les serveurs HTTP. |
"legacy" | Bob saute la sonde et se connecte directement via le handshake initialize, compatible avec tous les serveurs MCP. |
{ "pin": "<version>" } | Bob se connecte en utilisant une version de protocole spécifique (par exemple, { "pin": "2024-11-05" }). |
Si un serveur HTTP expire avec MCP connection timed out after 10000ms, le serveur peut ne pas répondre à la sonde server/discover. Définissez "protocolNegotiation": "legacy" pour sauter la sonde :
{
"mcpServers": {
"my-server": {
"url": "https://votre-url-serveur.com/mcp",
"protocolNegotiation": "legacy"
}
}
}Pour plus de détails, consultez Négociation de protocole dans « Utiliser MCP dans Bob ».
Exemple d'implémentation HTTP streamable
Configuration dans settings.json :
{
"mcpServers": {
"StreamableHTTPMCPName": {
"type": "streamable-http",
"url": "http://localhost:8080/mcp"
}
}
}Pour l'implémentation côté serveur, consultez la documentation du SDK MCP pour StreamableHTTPClientTransport.
Rétrocompatibilité avec HTTP+SSE
Le client MCP de Bob ne bascule pas vers le transport HTTP+SSE. Les indications ci-dessous s'adressent aux auteurs de serveurs qui souhaitent que leur serveur HTTP streamable reste accessible aux anciens clients ne prenant pas encore en charge le HTTP streamable.
Les serveurs devant prendre en charge les anciens clients doivent continuer à héberger les points de terminaison SSE (/events) et POST (/message) de l'ancien transport, en plus du nouveau point de terminaison MCP défini pour le transport HTTP streamable.
Transport SSE (supprimé)
Le client MCP de Bob ne prend plus en charge le transport HTTP+SSE autonome (spécification MCP 2024-11-05). Les serveurs utilisant uniquement le transport HTTP+SSE ne peuvent pas se connecter à Bob.
SSE comme canal de réponse au sein d'une connexion HTTP streamable est toujours pris en charge. Bob peut recevoir des flux SSE d'un serveur HTTP streamable. Seul le transport HTTP+SSE autonome (avec des points de terminaison /events et /message distincts) a été supprimé.
Migration depuis le transport SSE
Si tu as un serveur existant utilisant le transport HTTP+SSE, migre-le vers le transport HTTP streamable ou STDIO :
- HTTP streamable : Expose un seul point de terminaison MCP acceptant les requêtes HTTP POST. C'est la voie recommandée pour les serveurs distants. Consulte Transport HTTP streamable.
- STDIO : Si le serveur s'exécute localement sur la même machine que Bob, convertis-le en serveur STDIO. Consulte Transport STDIO.
Considérations de déploiement
Le choix entre STDIO et le transport HTTP streamable affecte 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 l'ordinateur de chaque 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 l'ordinateur de l'utilisateur
Exemple de cas d'utilisation :
Un outil de recherche de fichiers local avec STDIO :
- S'exécuterait sur l'ordinateur de l'utilisateur
- Aurait un accès direct au système de fichiers local
- Serait démarré par Bob selon les besoins
- Ne nécessiterait aucune configuration réseau
- Devrait être installé aux côtés de Bob ou via un gestionnaire de paquets
Distant : Déploiement hébergé
Les serveurs distants (HTTP streamable) peuvent être déployés sur des serveurs distants et invoqués via le réseau :
- Installation : Installé une fois sur un serveur, invoqué par de nombreux utilisateurs
- Distribution : Un seul déploiement sert plusieurs clients
- Mises à jour : Les mises à jour centralisées affectent tous les utilisateurs immédiatement
- Ressources : Utilise les ressources du serveur, pas celles de la machine locale
- Contrôle d'accès : Géré par des systèmes d'authentification et d'autorisation
- Intégration : Intégration plus complexe avec les ressources spécifiques à l'utilisateur
- Exécution : S'exécute 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'utilisation :
Un outil de requête de base de données avec transport distant :
- S'exécuterait sur un serveur central
- Se connecterait aux bases de données avec des identifiants côté serveur
- Serait disponible en continu pour plusieurs utilisateurs
- Nécessiterait une configuration de sécurité réseau appropriée
- Serait déployé avec des technologies de conteneur 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 pour des services distants
- Distant avec commandes locales : Un serveur distant pouvant déclencher des opérations sur la machine client via des callbacks
- Modèle de passerelle : Serveurs STDIO pour les opérations locales se connectant à des serveurs distants pour des fonctionnalités spécialisées
Comparaison des transports
| Considération | STDIO | HTTP streamable |
|---|---|---|
| Emplacement | Machine locale uniquement | Local ou distant |
| Clients | Client unique | Plusieurs clients |
| Performance | Latence plus faible | Latence plus élevée (surcharge réseau) |
| Complexité de configuration | Plus simple | Plus complexe (nécessite un serveur HTTP) |
| Sécurité | Intrinsèquement sûr | Nécessite des mesures de sécurité explicites |
| Accès réseau | Non requis | Requis |
| Évolutivité | Limité à la machine locale | Peut être distribué 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 | Utilise les ressources du client | Utilise les ressources du serveur |
| Dépendances | Dépendances côté client | Dépendances côté serveur |
Configurer les transports dans Bob
Pour des informations détaillées sur la configuration des transports dans Bob, y compris des exemples de configuration, consultez MCP dans Bob.
Comprendre MCP
Le Model Context Protocol (MCP) est un protocole de communication standardisé qui permet aux systèmes d'IA d'interagir avec des outils et services externes.
Utiliser MCP dans Bob
Le Model Context Protocol (MCP) étend les capacités de Bob en se connectant à des outils et services externes. Ce guide vous montre comment configurer, gérer et utiliser les serveurs MCP avec Bob.