Serveur MCP distant ou local : stdio, Streamable HTTP, et lequel votre équipe devrait choisir

Les deux transports définis par la spécification MCP

Le Model Context Protocol encode chaque message en JSON-RPC. La spécification (révision 2025-11-25) définit exactement deux transports standard pour véhiculer ces messages, et dit que les clients devraient prendre en charge le premier chaque fois que possible :

1. stdio. Le client lance le serveur comme sous-processus. Le serveur lit les messages JSON-RPC sur l'entrée standard et les écrit sur la sortie standard, un par ligne. Il peut journaliser sur la sortie d'erreur, et ne doit rien écrire d'autre sur stdout.
2. Streamable HTTP. Le serveur est un processus indépendant à un unique endpoint HTTP, tel que https://example.com/mcp, qui accepte POST et GET. Chaque message du client est un POST. Le serveur répond soit par un seul objet JSON, soit en ouvrant un flux Server-Sent Events quand il a plusieurs messages à envoyer. Il a remplacé l'ancien transport HTTP+SSE de la révision 2024-11-05, désormais déprécié.

« Local » et « distant » sont les noms courants de ces deux-là. Un serveur local est presque toujours en stdio ; un serveur distant est toujours en Streamable HTTP. On peut faire tourner un serveur Streamable HTTP sur localhost, et la spécification précise que ces serveurs ne devraient écouter que sur 127.0.0.1, mais les formes courantes sont les deux ci-dessus. La section transports de la spécification contient les règles complètes ; l'entrée du glossaire sur les serveurs distants en est la version courte.

Comment fonctionne un serveur local

Vous installez quelque chose, en général un petit programme en Node, Python ou Go, et vous l'ajoutez à la configuration de votre application d'IA avec la commande qui le lance. Au démarrage, l'application crée le processus. Le serveur lit typiquement une clé d'API ou un chemin de base de données dans l'environnement que l'application lui transmet. Quand vous fermez l'application, le processus meurt.

C'est la forme d'origine de MCP, et elle reste la bonne pour une large classe de serveurs :

• Un serveur de système de fichiers qui lit les dossiers que vous lui indiquez.
• Un serveur de base de données avec une chaîne de connexion gardée dans votre profil shell.
• Une enveloppe autour d'un outil en ligne de commande déjà installé sur votre machine.
• Tout ce que vous prototypez en un après-midi.

Ses forces sont la simplicité et la localité. Pas de réseau, pas de certificat TLS, pas de connexion, pas de multi-tenant : le serveur sert une personne, celle qui l'a lancé. La spécification dit que les serveurs stdio ne devraient pas utiliser le flux d'autorisation OAuth et devraient prendre leurs identifiants dans l'environnement.

Ses faiblesses sont les mêmes faits vus du côté de l'équipe. Chaque personne installe et met à jour sa propre copie. Chaque copie a besoin de sa propre clé. Une clé dans un fichier de configuration sur un portable est une clé qui peut être copiée, commitée par accident, ou laissée derrière quand quelqu'un part. Et rien de central ne sait qui a appelé quoi.

Comment fonctionne un serveur distant

Un serveur distant est un service web. Vous l'ajoutez à votre application par son URL. Au premier appel, le serveur répond 401 Unauthorized avec un pointeur vers ses métadonnées ; l'application découvre le serveur d'autorisation, ouvre un navigateur, vous vous connectez et approuvez un ensemble de scopes, et dès lors chaque requête porte un jeton bearer dans l'en-tête Authorization. Le client MCP dans l'application gère toute cette chorégraphie ; la personne ne voit qu'un écran de consentement.

Streamable HTTP ajoute quelques mécanismes que vous remarquerez comme utilisateur ou exploitant :

• Sessions. Un serveur peut renvoyer un en-tête MCP-Session-Id à l'initialisation, et le client doit ensuite l'envoyer à chaque requête. Le serveur peut mettre fin à la session à tout moment, après quoi le client en démarre une nouvelle.
• Streaming. Pour un appel d'outil long, le serveur peut ouvrir un flux SSE, envoyer des notifications de progression et terminer par la réponse. Si la connexion tombe, le client peut se reconnecter avec Last-Event-ID et le serveur peut rejouer ce qui a été manqué.
• Validation de l'Origin. Les serveurs doivent valider l'en-tête Origin sur chaque connexion et rejeter les mauvais avec 403, pour empêcher une page web malveillante de parler à un serveur via le navigateur.
• Authentification à chaque appel. Le jeton va dans l'en-tête de chaque requête, jamais dans l'URL, et le serveur doit vérifier qu'il a été émis pour ce serveur précisément.

Le gain : un seul déploiement sert tout le monde. Personne n'installe rien. L'accès est accordé par personne, limité à ce qu'elle a approuvé, et révocable côté serveur. Chaque appel peut être audité par rapport à la personne derrière le jeton.

Le coût : vous exploitez désormais un service : hébergement, TLS, disponibilité, limites de débit, isolation des tenants, et un serveur d'autorisation OAuth ou une intégration avec un. Pour un serveur que vous seul utilisez, c'est beaucoup de machinerie.

Serveur MCP distant et local, côte à côte

Lequel utiliser ?

Posez-vous trois questions.

À qui sont les données ? Si le serveur lit vos propres fichiers ou une base que vous seul touchez, local. S'il lit un système partagé par plusieurs personnes, avec des enregistrements qui appartiennent à l'entreprise et des permissions différentes par personne, distant. Un serveur local n'a aucun moyen d'exprimer « Priya peut voir la valeur des deals et Tom non » ; il tourne avec la clé qu'on lui a donnée.

Qui doit l'installer ? Si la réponse est « moi, une fois », local convient. Si la réponse est « chaque collègue, et le maintenir à jour », un serveur distant supprime toute la corvée. Nous avons vu la version locale échouer en moins d'une semaine : la configuration de l'un a une vieille clé, celle de l'autre un chemin qui ne marche que sur sa machine.

Que se passe-t-il quand quelqu'un part ? Avec un serveur local, sa clé vit dans un fichier que vous ne voyez pas. Avec un serveur distant adossé à OAuth, révoquer son compte met fin à tous les jetons qu'il a créés, dès l'appel suivant.

Une règle raisonnable pour une petite équipe : des serveurs locaux pour l'outillage de développement sur le portable de chacun ; des serveurs distants pour chaque produit dans lequel l'équipe travaille vraiment.

Quand une équipe devrait héberger son propre serveur distant

La plupart des équipes se connecteront à des serveurs distants exploités par des éditeurs. Parfois, en héberger un soi-même a du sens : un système interne sans éditeur, une base que vous voulez voir interrogée par des assistants avec des permissions par personne, ou une API que vous avez construite. Avant de le faire, budgétez les parties qui ne sont pas les outils eux-mêmes :

1. Un serveur d'autorisation. La spécification d'autorisation MCP attend OAuth 2.1 avec PKCE et découverte de métadonnées. Vous pouvez en exploiter un ou placer devant le serveur un fournisseur d'identité qui le prend en charge.
2. La validation du jeton à chaque requête, y compris vérifier que le jeton a été émis pour votre serveur et non pour une autre ressource.
3. L'isolation des tenants. Le jeton d'une requête doit borner ce qu'elle peut voir. Construisez le serveur de sorte qu'une instance, ou un contexte, soit créé par requête autour de ce jeton, et que rien ne soit mis en cache entre personnes.
4. Limites de débit et audit. Un client très actif ne doit pas affamer les autres, et vous voudrez savoir après coup qui a lancé quel outil.
5. Exploitation. TLS, disponibilité, versionner la liste d'outils sans casser les clients.

Si cette liste paraît lourde pour votre besoin, gardez le serveur local, ou attendez l'éditeur.

Pourquoi Atrix est distant uniquement

Notre propre serveur MCP illustre ce choix. Atrix est un espace de travail partagé : les projets, documents, clients, calendrier et dossiers du personnel d'une équipe y vivent, et ce que chacun peut voir diffère. Un serveur local devrait tourner avec une clé aussi puissante que la personne qui l'a créée, sur chaque portable, et le serveur ne saurait jamais qui pose réellement la question.

Le serveur Atrix est donc un unique endpoint distant, https://atrix.dev/api/mcp, en Streamable HTTP. Il n'y a aucun paquet à installer. Dans Claude Code, toute la configuration tient en une ligne, claude mcp add --transport http atrix https://atrix.dev/api/mcp, suivie de /mcp puis Authenticate ; le navigateur s'ouvre, vous choisissez un espace de travail et approuvez des scopes, et le client stocke un jeton d'accès de courte durée avec un jeton de rafraîchissement à rotation. Le serveur construit une instance neuve par requête autour du jeton présenté, donc rien n'est partagé entre requêtes ni entre espaces de travail, et chaque appel est audité par outil, résultat et sujet. Il expose 85 outils et figure dans le Registre MCP officiel et sur Glama. La page de la fonctionnalité détaille ce que font les outils.

Les limites sont réelles. Pas de mode hors ligne, ni de moyen de l'utiliser sans compte Atrix. Les limites de débit sont de 120 appels et 30 écritures par minute et par jeton. Et comme les scopes ne peuvent que restreindre ce qu'une personne peut déjà faire, un assistant connecté via le compte de quelqu'un ne voit jamais plus que cette personne ; s'il vous faut un serveur qui atteint tout, ce n'est pas celui-ci, et nous pensons que c'est le bon compromis.

FAQ

Quelle est la différence entre un serveur MCP distant et un serveur local ?

Un serveur local tourne sur votre machine en sous-processus et parle en stdio, avec des identifiants issus de l'environnement. Un serveur distant tourne à une URL HTTPS en Streamable HTTP, authentifie chaque personne par OAuth et sert de nombreux utilisateurs depuis un seul déploiement.

stdio ou Streamable HTTP, lequel est le meilleur ?

Aucun n'est meilleur en général. La spécification définit les deux et demande aux clients de prendre en charge stdio quand c'est possible. stdio est plus simple et sans exposition réseau ; Streamable HTTP est la seule option quand le serveur est partagé ou hébergé hors de la machine de l'utilisateur.

Peut-on faire tourner un serveur Streamable HTTP en local ?

Oui. La spécification dit que les serveurs HTTP locaux ne devraient écouter que sur localhost et doivent valider l'en-tête Origin pour prévenir le DNS rebinding. Cela reste une forme moins courante que stdio pour un serveur mono-utilisateur.

Les serveurs MCP distants ont-ils besoin d'OAuth ?

La spécification d'autorisation MCP dit que les implémentations à transport HTTP devraient la suivre, et elle repose sur OAuth 2.1. Certains serveurs acceptent à la place un jeton bearer collé à la main, plus simple et plus faible : le jeton a une longue durée de vie, vit dans un fichier de configuration et n'est pas borné par un écran de consentement.

Qu'est devenu le transport HTTP+SSE ?

Il a été défini dans la révision 2024-11-05 et remplacé par Streamable HTTP dans la révision 2025-03-26. La spécification actuelle le marque comme déprécié et décrit comment clients et serveurs peuvent rester compatibles avec l'ancienne forme.

Le serveur MCP d'Atrix existe-t-il en local ?

Non. Il est distant uniquement, à https://atrix.dev/api/mcp, parce que les données de l'espace de travail sont partagées et que les permissions par personne doivent être appliquées par le serveur à chaque appel.

Prochaine étape

Si vous connectez un assistant à Atrix, la vue d'ensemble développeurs donne les étapes exactes pour Claude Code, Claude Desktop, ChatGPT et Cursor, et la page MCP liste les outils. Si vous décidez comment construire votre propre serveur, lisez d'abord les entrées client MCP et serveur MCP distant.