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 (option distante legacy)

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();

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

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

Les clients et serveurs peuvent maintenir la rétrocompatibilité avec le transport HTTP+SSE legacy.

Les serveurs souhaitant prendre en charge les anciens clients doivent continuer à héberger à la fois 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 (Legacy)

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.

Comment fonctionne le transport SSE

Bob se connecte au point de terminaison SSE du serveur via une requête HTTP GET
Cela établit une connexion persistante sur laquelle le serveur peut envoyer des événements à Bob
Pour la communication client-serveur, Bob envoie des requêtes HTTP POST à un point de terminaison séparé
La communication se fait via deux canaux :
- Flux d'événements (GET) : Mises à jour serveur-client
- Point de terminaison de messages (POST) : Requêtes client-serveur

Client                             Serveur
  |                                  |
  |---- HTTP GET /events ----------->| (Établir 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
Évolutivité : Peut gérer plusieurs connexions client simultanément
Protocole : Fonctionne sur HTTP standard (pas de protocoles spéciaux requis)
Persistance : Maintient une connexion persistante pour les messages serveur-client
Authentification : Peut utiliser des 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 les 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'});
// Enregistrer les outils...

// Utiliser le 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) 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 ou SSE) 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