En 2024, Anthropic a ouvert MCP au monde. En 2025, tout le monde a construit des serveurs stdio. En 2026, ceux qui n'ont pas de transport HTTP sont déjà en retard.
Si tu as lu l'introduction à MCP dans la série précédente, tu sais qu'un serveur MCP expose des tools qu'un LLM peut appeler. Ce qu'on n'a pas abordé, c'est le transport. Le serveur de l'article précédent tournait en stdio : un processus local, lancé par Claude Desktop. Simple, efficace pour du dev.
Mais stdio a des limites sérieuses. Et le passage au transport HTTP remote est ce qui transforme MCP d'un outil de dev local en une brique d'infrastructure.
Stdio : simple mais limité
Un serveur MCP stdio communique via stdin/stdout. Le client le lance comme un sous-processus sur ta machine. 90% des serveurs MCP fonctionnent encore comme ça.
Le problème :
- Le serveur tourne sur ta machine. PC allumé, bon runtime installé.
- Seuls les clients locaux y accèdent. Claude Desktop ou Claude Code peuvent lancer un processus. Pas Claude.ai web, pas l'appli mobile.
- Pas de multi-utilisateur. Un processus, un user, un context.
- Pas de scaling. Exposer ça à une équipe ou en SaaS, c'est un refactoring complet.
Pour un dev qui branche un serveur MCP à Claude Code dans son terminal, stdio fonctionne. Le besoin de remote apparait quand tu veux accéder depuis un autre device, partager avec une équipe, ou transformer ton serveur en produit.
De SSE à Streamable HTTP
Quand le transport remote a été introduit, MCP utilisait Server-Sent Events (SSE). Le client ouvrait une connexion persistante sur /sse pour recevoir les réponses, et envoyait ses requêtes sur /sse/messages. Deux connexions, deux endpoints.
En mars 2025 (spec 2025-03-26), MCP a introduit Streamable HTTP et déprécié SSE :
1# Ancien modèle (SSE, déprécié)
2Client ──GET──▶ /sse (connexion persistante, réception)
3Client ──POST─▶ /sse/messages (envoi des requêtes)
4
5# Nouveau modèle (Streamable HTTP)
6Client ──POST──▶ /mcp (tout passe par un seul endpoint)Un seul endpoint. Les requêtes arrivent en POST, le serveur répond en JSON classique ou upgrade dynamiquement en flux SSE si nécessaire (streaming, notifications).
Pourquoi c'est mieux
Compatibilité infrastructure. Un POST sur un endpoint unique traverse les load balancers, proxies, WAF, CDN sans problème. Les connexions SSE persistantes, c'est une autre histoire.
Scaling horizontal. Pas de session entre les requêtes. Chaque POST est autonome. Tu scales derrière un load balancer classique.
Sécurité. Chaque requête porte son token dans le header Authorization. Les outils standard (OAuth 2.1, WAF, rate limiting) fonctionnent nativement.
Stateless possible. La spec permet un Mcp-Session-Id pour les serveurs stateful, mais un serveur peut fonctionner en mode complètement stateless : chaque POST crée un transport éphémère, pas de session en mémoire, scaling horizontal sans coordination.
L'écosystème remote en 2026
Claude.ai et mobile supportent les serveurs MCP remote depuis mi-2025 (page "Connectors"). L'app iOS et Android depuis juillet 2025.
OpenAI a adopté MCP pour ChatGPT en mars 2025. Google pour Gemini en avril. Cursor, Windsurf, Cline suivent.
MCP a rejoint la Linux Foundation en décembre 2025 (Agentic AI Foundation, co-fondée par Anthropic, Block et OpenAI).
La roadmap 2026 confirme : l'effort est concentré sur Streamable HTTP (métadonnées .well-known, pas de nouveau transport prévu).
Avant / après en pratique
Stdio : tu installes un serveur MCP sur ton PC, tu configures Claude Desktop pour le lancer en subprocess. Ça marche sur ce PC, avec ce client. Pour y accéder ailleurs, tu montes un tunnel Tailscale. Pour le partager, tu dupliques le setup.
Remote : tu déploies le serveur derrière une URL HTTPS. Tous les clients compatibles s'y connectent via OAuth. Un seul déploiement sert tout le monde.
1┌──────────────┐
2│ Claude.ai │──┐
3│ (web) │ │
4├──────────────┤ │ ┌──────────────────┐ ┌─────────────┐
5│ Claude │──┼───▶│ MCP Server │────▶│ Stockage │
6│ (mobile) │ │ │ (Streamable HTTP)│ │ (S3, DB...)│
7├──────────────┤ │ └──────────────────┘ └─────────────┘
8│ Claude Code │──┤ ▲
9│ (terminal) │ │ │ OAuth 2.1
10├──────────────┤ │ │
11│ Cursor │──┘ ┌──────────────┐
12│ (IDE) │ │ Auth Server │
13└──────────────┘ └──────────────┘Anatomie d'un serveur MCP remote
Trois briques : transport HTTP, authentification, stockage distant.
Transport : un endpoint, des POST
Le serveur expose /mcp. Chaque interaction (discovery, appel de tool, résultat) passe par un POST JSON-RPC.
1import express from "express";
2import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
3import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
4
5const app = express();
6app.use(express.json());
7
8app.post("/mcp", async (req, res) => {
9 const transport = new StreamableHTTPServerTransport({
10 sessionIdGenerator: undefined, // stateless
11 });
12 const server = new McpServer({ name: "my-server", version: "1.0.0" });
13
14 server.tool("ping", "Health check", {}, async () => ({
15 content: [{ type: "text", text: "pong" }],
16 }));
17
18 await server.connect(transport);
19 await transport.handleRequest(req, res, req.body);
20});
21
22app.listen(3000);Authentification : OAuth 2.1
La spec MCP s'appuie sur OAuth 2.1 avec trois mécanismes :
Discovery. Le client tente un appel sans token, reçoit un 401, et découvre le serveur d'autorisation via .well-known :
1GET https://example.com/.well-known/oauth-protected-resource
2→ { "authorization_servers": ["https://auth.example.com"] }
3
4GET https://auth.example.com/.well-known/oauth-authorization-server
5→ { "registration_endpoint": "...", "authorization_endpoint": "...", "token_endpoint": "..." }Dynamic Client Registration (DCR). Le client s'enregistre automatiquement et obtient un client_id sans passer par un dashboard.
PKCE. Le flow d'autorisation est sécurisé sans secret côté client. Le client génère un code_verifier, en dérive un code_challenge (SHA256), et les utilise pour l'échange du code contre un token.
En pratique : l'utilisateur colle une URL MCP dans Claude, un écran de consent s'affiche, il clique "Autoriser", et c'est fini. Le flow complet est détaillé dans l'article sur l'authentification MCP (à venir).
Stockage : accessible par le réseau
Un serveur remote ne lit pas ~/Documents. Il accède à un backend réseau :
| Backend | Cas d'usage | Exemples |
|---|---|---|
| S3-compatible | Fichiers, notes, documents | AWS S3, Scaleway, R2, MinIO |
| Base de données | Données structurées | PostgreSQL, Supabase |
| API tierce | Proxy vers un service | GitHub, Linear, Notion, Slack |
Bonnes pratiques pour les tools
Quelques principes pour des tools efficaces dans un contexte remote :
Minimiser les tokens. Un list_files qui renvoie 10 000 résultats d'un coup gaspille le contexte. Pagination et filtrage par path prefix, c'est le minimum.
Granularité fine. Plutôt qu'un seul tool edit_file qui remplace tout, des tools spécialisés (patch ciblé, remplacement d'une occurrence, ajout en fin de fichier) permettent à l'agent de choisir l'opération la plus efficace.
Descriptions précises. Les descriptions de tools sont du prompt engineering. Le LLM les lit pour décider quel tool appeler. Une description avec des exemples de paramètres et des cas d'usage guide mieux qu'une ligne vague.
Pourquoi la majorité des serveurs sont encore en local
L'inertie. Les premiers exemples, tutos et templates étaient tous en stdio. C'est le chemin de moindre résistance.
La complexité. Un serveur remote demande du déploiement, de l'auth, de l'infra. Un serveur stdio, tu lances npx et c'est parti.
Le besoin local suffit souvent. Pour du dev perso, stdio fonctionne. Le remote n'émerge qu'avec le besoin multi-device, multi-utilisateur, ou SaaS.
Mais ça bouge. Cloudflare Workers, Koyeb, AWS proposent du hosting MCP. Les entreprises déploient des serveurs remote derrière des gateways OAuth. Le remote n'est plus l'exception, c'est la direction.
Ce qu'il faut retenir
Si tu construis un serveur MCP aujourd'hui :
- Pars en Streamable HTTP. SSE est déprécié, stdio c'est pour le dev local.
- Implémente OAuth dès le début si d'autres que toi l'utiliseront.
- Pense multi-client : web, mobile, terminal, IDE, agents.
- Optimise tes tools pour le LLM : tokens minimaux, descriptions claires, granularité fine.
Pour voir ces principes appliqués à un cas concret, j'ai détaillé la construction de Vaulken, un serveur MCP remote pour fichiers S3 avec BYOB, 16 tools optimisés et recherche sémantique.