Types de Serveurs MCP : STDIO, SSE et OAuth

Les deux modes de transport MCP

Un serveur MCP peut communiquer avec son client de deux manières fondamentalement différentes, selon qu’il tourne sur la même machine ou sur un serveur distant. Comprendre cette distinction est essentiel pour choisir la bonne architecture.

STDIO : le serveur local

Le mode STDIO (Standard Input/Output) est le transport local. Le serveur MCP tourne sur la même machine que le client. La communication passe par les flux standard du système d’exploitation : stdin et stdout.

Fonctionnement : le client lance le processus du serveur, lui envoie des requêtes via stdin, et lit les réponses via stdout. Quand la conversation se termine, le processus est arrêté.

Cas d’usage typiques :

• Outils CLI (accès au système de fichiers, Git, Docker)
• Intégrations IDE (VS Code, Cursor) avec des outils locaux
• Développement et tests en local
• Applications qui nécessitent l’accès à des ressources locales

from mcp import StdioServerParameters

server_params = StdioServerParameters(
    command="python",
    args=["mon_serveur_mcp.py"],
    env=None,  # Variables d environnement optionnelles
)

Limitation principale : le serveur et le client doivent être sur la même machine. Impossible d’utiliser un serveur STDIO depuis Le Chat de Mistral, par exemple, car Le Chat tourne sur les serveurs Mistral.

SSE et Streamable HTTP : les serveurs distants

Pour les serveurs distants, MCP propose le transport HTTP. Deux variantes ont existé :

SSE (Server-Sent Events) — Déprécié

Le SSE était le premier transport distant de MCP. Il permettait au serveur d’envoyer des événements en streaming vers le client, mais le client devait effectuer des requêtes POST séparées pour communiquer avec le serveur. Son principal défaut : il exigeait une connexion permanente entre client et serveur.

Streamable HTTP — Le standard actuel

Le Streamable HTTP a remplacé le SSE comme transport distant de référence. Son avantage clé : il ne nécessite pas de connexion permanente. Le client envoie des requêtes HTTP classiques, et le serveur peut répondre en streaming ou non.

En pratique, votre serveur MCP distant expose un endpoint /mcp accessible via HTTP :

from mistralai.extra.mcp.sse import MCPClientSSE, SSEServerParams

# Connexion à un serveur MCP distant
server_url = "https://mon-serveur.example.com/mcp"
mcp_client = MCPClientSSE(
    sse_params=SSEServerParams(url=server_url, timeout=100)
)

Les trois niveaux d’authentification

Indépendamment du transport, un serveur MCP peut exiger différents niveaux d’authentification :

1. Aucune authentification

Le serveur est accessible à quiconque possède l’URL. Adapté pour des outils publics sans données sensibles (scraping web, conversions, calculs).

2. Token (API Key)

Le serveur exige un token d’authentification. Vous créez un token qui définit les droits d’accès et le transmettez au client. C’est le cas de GitHub : vous générez un Personal Access Token avec des scopes spécifiques.

3. OAuth 2.0

Le serveur utilise le flux OAuth complet. L’utilisateur autorise l’application à accéder à son compte via un processus de consentement. C’est le cas de Gmail, Linear, ou Google Calendar dans Le Chat.

Tableau comparatif

Quelle configuration choisir ?

Le choix se résume à deux questions :

1. Le serveur tourne-t-il sur la même machine que le client ? → STDIO
2. Sinon → Streamable HTTP (avec ou sans authentification selon la sensibilité des données)

Pour Le Chat de Mistral et les chatbots hébergés, seuls les serveurs distants (HTTP) sont utilisables. Pour un IDE comme VS Code ou Cursor, les deux modes sont possibles.

Points clés à retenir

• STDIO = serveur local, même machine, parfait pour le développement
• Streamable HTTP = serveur distant, standard actuel, remplace SSE
• Trois niveaux d’auth : aucune, token, OAuth 2.0
• Le Chat de Mistral ne supporte que les serveurs distants
• Le choix du transport dépend de votre architecture de déploiement