Transport stdio MCP — pour Claude Desktop, Claude Code, agents locaux

De quoi il s'agit

Le transport stdio du MCP relie un serveur Model Context Protocol à un client — Claude Desktop, Claude Code, ou un script d'agent local — en faisant transiter des messages JSON-RPC 2.0 délimités par des sauts de ligne sur l'entrée et la sortie standard du processus. Le client démarre le serveur comme processus enfant ; le serveur lit les requêtes depuis stdin, écrit les réponses sur stdout, et envoie chaque ligne de journal ou message de débogage exclusivement vers stderr. Cette frontière n'est pas une préférence de style, elle est structurelle : une seule instruction d'affichage égarée, ou un simple message de console atterrissant sur stdout, corrompt la trame JSON-RPC et bloque ou fait planter la session sur-le-champ. La première ligne de défense de tout auteur de serveur consiste à router toute sortie de diagnostic vers stderr dès la toute première ligne de code.

Pourquoi c'est important

• Claude Desktop et Claude Code utilisent stdio par défaut car l'OS gère l'isolation des processus et l'authentification est implicite — zéro configuration réseau à gérer.
• Ne passez à HTTP que si le serveur doit être partagé entre clients/machines, est persistant indépendamment d'un client, cible un conteneur sans lancement de processus enfant, ou a besoin de TLS/bearer auth fins.
• Une erreur fréquente est de basculer vers HTTP pour un « effet production » sur une boîte à outils personnelle, perdant la simplicité du stdio sans raison.

Points clés

• Transport stdio — l'hôte lance le serveur en processus enfant ; messages JSON-RPC 2.0 séparés par sauts de ligne sur stdin/stdout.
• Modèle de confiance — la frontière de processus OS est la frontière de sécurité ; l'hôte qui lance le serveur est de confiance par l'utilisateur.
• Cas d'usage — Claude Desktop, Claude Code, Cursor, Continue, tout IDE-agent local ; boucle de productivité d'un seul développeur.
• Discipline de logs — stderr seul ; écrire sur stdout corrompt le flux JSON-RPC et déconnecte l'hôte.
• Mono-client par construction — migrez vers Streamable HTTP (C227) dès qu'il faut plus d'un opérateur sur le serveur.
• Aucune couche OAuth, par conception de la spec (2026-07-28) — les implémentations stdio NE DEVRAIENT PAS du tout suivre le modèle d'autorisation HTTP ; les identifiants viennent de l'environnement (le bloc env de mcpServers), pas d'un flux de token.
• Les extensions sont indépendantes du transport — Elicitation et l'extension Tasks (C225, C227) fonctionnent sur stdio exactement comme sur Streamable HTTP ; un serveur local peut toujours suspendre un appel pour demander quelque chose à l'utilisateur ou renvoyer un taskId durable pour un job local lent.

Termes employés sur cette page

stdio transport

Format de communication MCP où l'hôte lance le serveur comme processus enfant et échange des messages JSON-RPC 2.0 via son stdin/stdout ; le mode de déploiement le plus simple.

claude_desktop_config.json

Fichier de configuration JSON par utilisateur où Claude Desktop enregistre les serveurs MCP ; liste command + args + env pour chaque serveur.

JSON-RPC 2.0

Protocole léger d'appel de procédure distante sur JSON ; l'encodage de communication de chaque message MCP quel que soit le transport.

Single-client constraint

Propriété architecturale de stdio : un seul processus hôte possède les flux d'E/S du serveur ; un second client nécessite le transport HTTP.

stdio et autorisation (spec 2026-07-28)

La spécification actuelle indique explicitement que les implémentations utilisant un transport stdio NE DEVRAIENT PAS suivre la spécification d'autorisation HTTP et devraient plutôt récupérer les identifiants depuis l'environnement — formalisant ce que cette fiche traite déjà comme modèle de confiance.

Elicitation sur stdio

La fonctionnalité côté client (spec 2026-07-28, voir C225) qui permet à un serveur de suspendre une tâche en cours pour demander une information supplémentaire à l'utilisateur ; elle est indépendante du transport, donc un serveur stdio peut l'utiliser exactement comme un serveur HTTP, à condition que l'hôte déclare le support à l'initialisation.

Négociation d'extension

Le mécanisme général de MCP (spec 2026-07-28) par lequel un client et un serveur déclarent chacun, à l'initialize / server/discover, quelles extensions optionnelles (Tasks, fonctionnalités liées à l'Elicitation, Skills) ils prennent en charge ; s'applique de façon identique que le transport sous-jacent soit stdio ou Streamable HTTP.

Sources

1. Model Context Protocol specification — stdio transport
2. Anthropic — MCP TypeScript SDK + stdio examples
3. Anthropic — Claude Desktop MCP configuration reference
4. Model Context Protocol — stdio transport specification (2026-07-28)
5. Model Context Protocol — Authorization specification (2026-07-28), stdio exemption
6. Model Context Protocol — Tasks extension overview (spec 2026-07-28)
7. Model Context Protocol — Extensions client-matrix (host support tracker)
8. Model Context Protocol — Build a server, develop guide (spec 2026-07-28)
9. Model Context Protocol — Security Best Practices tutorial (spec 2026-07-28)
10. Model Context Protocol — Specification versioning documentation (2026-07-28)
11. Model Context Protocol — Local Server Security (stdio trust model, isolation, credentials and egress)
12. Model Context Protocol — Debugging (stdio logging, Claude Desktop logs and common issues)
13. Model Context Protocol — Connect to local MCP servers (Claude Desktop configuration and approval flow)
14. AWS Machine Learning Blog — Add secure Web Search to Claude Desktop with Amazon Bedrock AgentCore (remote managed MCP server with JWT auth, 2 Oct 2026)
15. Google Cloud Blog — Empower your agents with the Google Cloud CLI remote MCP server (CLI behind remote MCP instead of local binaries, 1 Oct 2026)
16. NVIDIA Technical Blog — Add Runtime Controls to AI Agents with NVIDIA OpenShell (runtime permission enforcement outside the agent, 28 Sep 2026)