Types de Serveurs MCP : STDIO, SSE et OAuth

Deux modes de transport, deux architectures

Un serveur MCP communique avec son client de deux manières fondamentalement différentes, selon qu’il tourne sur la même machine ou sur un hôte distant. Cette distinction n’est pas un détail d’implémentation : elle détermine qui peut consommer votre serveur, comment vous le déployez et quelles données il peut atteindre. La trancher tôt vous évitera de réécrire votre projet à mi-parcours.

STDIO : le serveur qui vit sur votre machine

Le mode STDIO (Standard Input/Output) est le transport local. Le serveur MCP s’exécute sur la même machine que le client, et l’échange passe par les flux standard du système d’exploitation : stdin et stdout. Le mécanisme est direct : le client lance le processus du serveur, lui envoie ses requêtes via stdin, lit les réponses sur stdout, puis arrête le processus quand la conversation se termine. Aucun port, aucune URL, aucun certificat.

Ce transport s’impose naturellement dès que l’outil doit toucher à l’environnement local. Un serveur qui lit vos fichiers, appelle git, pilote Docker ou inspecte une base SQLite posée sur votre disque n’a de sens qu’en STDIO. C’est aussi le mode privilégié des intégrations dans un éditeur comme VS Code ou Cursor, et le compagnon évident de la phase de développement, où vous voulez relancer votre serveur toutes les trente secondes.

from mcp import StdioServerParameters

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

La contrepartie est stricte : serveur et client doivent cohabiter. Vous ne pourrez pas brancher un serveur STDIO sur Le Chat de Mistral, puisque Le Chat s’exécute sur l’infrastructure de Mistral et n’a aucun moyen de lancer un processus sur votre poste.

SSE et Streamable HTTP : les serveurs distants

Pour sortir de la machine locale, MCP passe par HTTP. Deux variantes se sont succédé, et il est utile de savoir laquelle vous avez sous les yeux quand vous lisez du code existant.

Le SSE (Server-Sent Events) fut le premier transport distant du protocole. Il permettait au serveur d’émettre des événements en streaming vers le client, lequel devait en retour effectuer des requêtes POST séparées pour parler au serveur. Son défaut structurel : il exigeait une connexion permanente entre les deux, ce qui complique l’hébergement serverless et la montée en charge. Il est aujourd’hui déprécié — le SDK Mistral fournit encore MCPClientSSE pour les endpoints /sse existants, mais un nouveau serveur ne doit plus être écrit sur cette base.

Le Streamable HTTP l’a remplacé comme transport distant de référence. Il supprime l’exigence de connexion permanente : le client envoie des requêtes HTTP classiques, et le serveur répond en streaming ou d’un bloc, selon le besoin. En pratique, votre serveur distant expose un endpoint /mcp sur lequel le client se branche.

from mistralai.extra.mcp.streamable_http import (
    MCPClientStreamableHTTP,
    StreamableHTTPServerParams,
)

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

Trois niveaux d’authentification

Le transport dit où se trouve le serveur ; l’authentification dit qui a le droit de l’appeler. Les deux questions sont indépendantes, et le protocole admet trois réponses.

Le plus simple est l’absence d’authentification : quiconque connaît l’URL peut utiliser vos tools. Ce choix ne se défend que pour des outils publics sans données sensibles — un convertisseur d’unités, un scraper de pages web, un calculateur.

Vient ensuite le token, ou clé d’API. Vous générez un jeton portant des droits précis et le transmettez au client, qui l’ajoutera à ses requêtes. GitHub illustre bien ce modèle : vous créez un Personal Access Token en cochant les scopes dont votre agent a réellement besoin, et rien de plus.

Le troisième niveau est OAuth 2.0, le flux complet avec écran de consentement. L’utilisateur autorise explicitement l’application à agir sur son compte, et le serveur reçoit un jeton lié à cette personne. C’est ce que font Gmail, Linear ou Google Calendar lorsque vous les connectez dans Le Chat — et c’est le seul modèle acceptable dès qu’un serveur manipule les données personnelles de plusieurs utilisateurs.

Comment trancher en pratique

La décision tient en deux questions posées dans l’ordre. Le serveur tourne-t-il sur la même machine que le client ? Si oui, prenez STDIO. Sinon, prenez Streamable HTTP, avec ou sans authentification selon la sensibilité des données manipulées.

Gardez en tête la contrainte côté client : Le Chat de Mistral et les chatbots hébergés en général ne consomment que des serveurs distants. Un IDE comme VS Code ou Cursor, lui, accepte les deux modes — d’où l’habitude confortable de développer en STDIO, puis de basculer en HTTP au moment de partager le serveur.

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