Ce qu'est un serveur MCP, et ce qu'il n'est pas

Connecter un modèle de langage à un système d'entreprise n'est pas une question de modèle. C'est un travail d'intégration. Le Model Context Protocol (MCP) existe pour standardiser précisément cette couche. Cette note traite MCP comme un protocole plutôt que comme un produit : ce qu'il spécifie, ce qu'il renonce délibérément à spécifier, et quelle case il occupe dans une architecture d'entreprise. Chaque affirmation technique ci-dessous s'appuie sur la spécification officielle. Les révisions de la spécification utilisent un identifiant AAAA-MM-JJ et ne sont incrémentées que lorsqu'un changement incompatible arrive. Cette note se fonde sur la révision 2025-11-25. La révision 2026-07-28, attendue le 28 juillet 2026, rend le protocole sans état, retire la poignée de main initialize et l'identifiant de session, sort Tasks du cœur vers une extension séparée, et marque Roots, Sampling et Logging comme dépréciés avec une fenêtre de retrait de douze mois. Les détails de session et de primitives ci-dessous changent dans cette révision.

Avant le protocole : un pont par paire

Avant MCP, relier une application d'IA à une source de données signifiait écrire du code sur mesure pour cette paire application-source précise. L'annonce d'origine le formule clairement : chaque nouvelle source de données demande sa propre implémentation, ce qui rend difficile la mise à l'échelle de systèmes véritablement connectés. Le raccourci du secteur pour cela est le N×M — N applications, M systèmes, N×M ponts écrits à la main entre les deux. Ce nom n'est pas une terminologie officielle, mais la situation qu'il décrit l'est. L'échange que propose MCP est direct : remplacer des intégrations fragmentées par un seul protocole, chaque côté ne l'implémentant qu'une fois.

MCP a été annoncé et ouvert par Anthropic le 25 novembre 2024, créé par David Soria Parra et Justin Spahr-Summers. La première publication est arrivée en trois parties : la spécification et les SDK, la prise en charge des serveurs MCP locaux dans les applications Claude Desktop, et un dépôt open source de serveurs prêts à l'emploi pour des systèmes comme Google Drive, Slack, GitHub, Postgres et Puppeteer.

Le 9 décembre 2025, Anthropic a fait don de MCP à l'Agentic AI Foundation (AAIF), un fonds dirigé sous l'égide de la Linux Foundation. Elle a été cofondée par Anthropic, Block et OpenAI, avec le soutien de Google, Microsoft, AWS, Cloudflare et Bloomberg. MCP en est un projet fondateur aux côtés de goose et d'AGENTS.md. La structure de maintenance a été reprise telle quelle : le conseil de gouvernance gère le budget, les adhésions et l'approbation des nouveaux projets, tandis que chaque projet conserve une pleine autonomie sur sa direction technique. Décrire MCP aujourd'hui comme simplement le protocole d'Anthropic est donc incomplet. La formulation exacte : né et ouvert chez Anthropic, et gouverné depuis décembre 2025 au sein de l'AAIF à la Linux Foundation. La documentation officielle cite Claude, ChatGPT, Visual Studio Code, Cursor et MCPJam parmi les clients qui le prennent en charge.

Architecture : hôte, client, serveur

MCP suit une architecture client-serveur et définit trois rôles distincts. L'hôte MCP est l'application d'IA qui coordonne un ou plusieurs clients MCP — Claude Code ou VS Code, par exemple. Un client MCP est le composant qui maintient une connexion vers un seul serveur et obtient du contexte pour le compte de l'hôte. Un serveur MCP est un programme qui fournit du contexte aux clients MCP. Le détail qui compte à l'exploitation : l'hôte crée un objet client distinct par serveur, et chaque client détient une connexion dédiée vers son propre serveur. Les serveurs ne se voient pas entre eux.

Le terme serveur MCP ne dit rien du lieu d'exécution du code ; il peut être local ou distant. En pratique, les serveurs locaux en stdio servent en général un seul client, tandis que les serveurs distants en Streamable HTTP en servent plusieurs. Le protocole se divise en deux couches : une couche de données (messagerie JSON-RPC 2.0, cycle de vie, primitives, notifications) et une couche de transport (établissement de connexion, découpage des messages, autorisation). MCP est un protocole à état. Une session s'ouvre par initialize, où les capacités sont négociées, et le client et le serveur doivent s'accorder sur une seule version du protocole.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": { "name": "example-host", "version": "1.0.0" }
  }
}

La spécification définit deux transports standard : stdio et Streamable HTTP. Les clients devraient prendre en charge stdio dès que possible, et les transports personnalisés sont permis tant qu'ils préservent le format de message JSON-RPC et les exigences du cycle de vie. Streamable HTTP expose un seul chemin de point d'entrée MCP prenant en charge POST et GET ; le serveur peut, en option, diffuser les réponses en SSE. L'ancien transport HTTP+SSE de la révision 2024-11-05 a été remplacé par Streamable HTTP et il est déprécié. En HTTP, les clients doivent envoyer un en-tête MCP-Protocol-Version sur toutes les requêtes qui suivent initialize, et la valeur envoyée devrait être la version négociée pendant initialize ; un serveur qui ne reçoit aucun en-tête suppose 2025-03-26. Un serveur peut émettre un MCP-Session-Id à l'initialisation et l'attendre sur les requêtes suivantes.

La spécification indique explicitement que MCP s'inspire en partie du Language Server Protocol. L'analogie tient : LSP a standardisé la jointure entre un éditeur et un langage ; MCP standardise la jointure entre une application d'IA et un système externe.

Ce qu'un serveur expose réellement

Les serveurs exposent leurs capacités par trois primitives centrales. Ce qui les sépare n'est pas ce qu'elles font, mais qui les contrôle :

• Tools — des fonctions que le modèle peut invoquer pour agir : écrire dans une base, appeler une API externe, modifier des fichiers. Contrôlées par le modèle. Méthodes : tools/list, tools/call.
• Resources — des sources de données passives, en lecture seule, qui fournissent du contexte : contenus de fichiers, schémas de base, réponses d'API. Contrôlées par l'application. Méthodes : resources/list, resources/templates/list, resources/read, resources/subscribe.
• Prompts — des modèles d'interaction réutilisables et paramétrés. Contrôlés par l'utilisateur ; la spécification attend qu'ils soient invoqués explicitement. Méthodes : prompts/list, prompts/get.

Les entrées des outils sont déclarées en JSON Schema. Cela permet à l'auteur du serveur de faire confiance au schéma plutôt qu'au modèle : un appel entrant est validé contre le schéma avant d'atteindre la moindre logique métier.

{
  "name": "get_order_status",
  "title": "Get order status",
  "description": "Returns the current status of a given order number.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orderNumber": { "type": "string", "pattern": "^[A-Z]{2}-[0-9]{6}$" },
      "verbose": { "type": "boolean", "default": false }
    },
    "required": ["orderNumber"]
  }
}

Côté ressources, chaque ressource porte un URI unique et déclare un type MIME. Au-delà des URI fixes, les serveurs peuvent publier des Resource Templates paramétrés — un modèle prenant une ville et une date, par exemple. Le flux n'est pas à sens unique : les clients exposent eux aussi des primitives aux serveurs. Sampling permet à un serveur de demander une complétion au modèle de l'hôte (sampling/createMessage). Elicitation permet à un serveur de demander à l'utilisateur une saisie ou une confirmation supplémentaire (elicitation/create). Roots permet à un serveur d'interroger la frontière de système de fichiers qui lui a été accordée. Logging complète l'ensemble. Une primitive Tasks pour les opérations longues est marquée expérimentale dans la révision actuelle, elle ne doit donc pas être traitée comme une hypothèse fixe dans un plan de déploiement. Les serveurs dont les capacités changent peuvent émettre des notifications comme notifications/tools/list_changed — mais seulement s'ils ont annoncé listChanged pendant initialize.

Où l'autorisation se joue réellement

C'est la partie que les lecteurs comprennent le plus souvent de travers. Dans MCP, l'autorisation est définie au niveau du transport et elle est optionnelle. Les transports fondés sur HTTP devraient se conformer à la spécification d'autorisation ; les transports STDIO ne devraient pas la suivre et devraient plutôt récupérer les identifiants depuis l'environnement. Chercher un flux OAuth dans un serveur stdio local, c'est regarder la mauvaise couche.

En HTTP, les rôles sont sans ambiguïté. Un serveur MCP protégé agit comme un serveur de ressources OAuth 2.1. Un client MCP agit comme un client OAuth 2.1. Le serveur d'autorisation est une partie distincte — il peut être hébergé à côté du serveur de ressources ou fonctionner de façon entièrement indépendante. C'est cette séparation qui fonde l'affirmation selon laquelle un serveur MCP est une frontière d'autorisation : le serveur ne frappe pas de jetons, il les valide et restreint l'accès en conséquence. Les standards dont cette section revendique le respect sont le brouillon OAuth 2.1, la RFC 8414, la RFC 7591, la RFC 9728 et le brouillon OAuth Client ID Metadata Documents. Séparément, le même document exige la RFC 8707 pour le paramètre resource.

Les exigences qui se traduisent directement en décisions de déploiement :

• Les serveurs MCP doivent implémenter la RFC 9728 (Protected Resource Metadata), et les clients doivent l'utiliser pour découvrir le serveur d'autorisation.
• Les clients doivent implémenter PKCE et utiliser la méthode de défi S256 lorsque c'est techniquement possible ; si la prise en charge de PKCE ne peut pas être vérifiée depuis le champ code_challenge_methods_supported des métadonnées du serveur d'autorisation, le client doit refuser de poursuivre.
• Les serveurs doivent vérifier que les jetons d'accès ont bien été émis pour eux en tant qu'audience prévue, et doivent rejeter ceux qui ne les nomment pas.
• Lorsqu'il appelle une API en amont, le serveur MCP agit comme un client OAuth à part entière et ne doit pas transmettre tel quel le jeton reçu du client MCP. La transmission de jeton est un motif explicitement interdit.
• Les jetons ne doivent pas apparaître dans la chaîne de requête de l'URI ; chaque requête HTTP porte un en-tête Authorization: Bearer, même au sein d'une même session logique.
• Les identifiants de session ne sont pas un mécanisme d'authentification : les serveurs ne doivent pas utiliser les sessions pour authentifier.

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="orders:read orders:write",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         error_description="Write permission required"

Les codes d'état sont également spécifiés : 401 lorsque l'autorisation est requise ou le jeton invalide, 403 en cas de portée insuffisante, 400 pour une requête mal formée. Sur un 403, le serveur annonce les portées nécessaires dans l'en-tête WWW-Authenticate, et le client peut lancer un flux d'autorisation par élévation. La minimisation des portées est officiellement recommandée, et les noms de portée fourre-tout comme *, all ou full-access figurent parmi les méprises d'implémentation courantes.

Ce que MCP n'est pas

MCP n'est pas un modèle. C'est un standard ouvert pour connecter des applications d'IA à des systèmes externes. Il ne contient aucun poids, aucun moteur d'inférence, aucune opinion sur le comportement des modèles. Le modèle que vous exécutez ne regarde pas le protocole.

MCP n'est pas un framework d'agents. La note de périmètre officielle est explicite : MCP se concentre uniquement sur le protocole d'échange de contexte et ne dicte pas comment les applications d'IA utilisent les LLM ni comment elles gèrent le contexte fourni. Planification, contrôle de boucle, mémoire, politique de reprise — tout cela vit dans votre application, pas dans le protocole.

MCP n'est pas un système RAG. La documentation des ressources le dit directement : les applications accèdent à l'information et décident comment l'utiliser, qu'il s'agisse de sélectionner les portions pertinentes, de chercher avec des embeddings ou de tout passer au modèle. Indexation, découpage et recherche vectorielle ne sont définis nulle part dans le protocole. Ce sont des décisions applicatives.

MCP ne remplace pas une passerelle d'API. Un serveur MCP n'est pas un passe-plat transparent devant des API en amont. Le jeton d'accès utilisé en amont est un jeton distinct émis par le serveur d'autorisation en amont, et le serveur ne doit pas retransmettre celui qu'il a reçu. Le serveur porte sa propre identité et sa propre frontière d'autorisation. Limitation de débit, quotas, traduction de protocoles et routage en périphérie restent l'affaire de la passerelle.

L'analogie officielle est bonne : voyez MCP comme un port USB-C pour les applications d'IA. Le port ne définit pas ce qui se trouve à l'autre bout du câble, ni ce que l'appareil connecté fait de la connexion.

Où se place le serveur dans un déploiement on-premise

La section sécurité de la spécification énumère quatre principes : consentement et contrôle de l'utilisateur, confidentialité des données, sûreté des outils, et contrôles de l'échantillonnage par le LLM. La même section ajoute une réserve : MCP ne peut pas imposer ces principes au niveau du protocole, il revient donc aux implémenteurs de le faire. Cette seule réserve explique pourquoi les décisions d'architecture pèsent autant ici. L'essentiel du contrôle ne vit pas dans le protocole mais dans l'identité de qui exploite le serveur et dans le lieu où il tourne.

Les exigences de sécurité de la spécification font de l'hébergement on-premise un choix naturel. Les serveurs qui tournent localement devraient n'écouter que sur 127.0.0.1 plutôt que sur toutes les interfaces. Les serveurs en Streamable HTTP doivent valider l'en-tête Origin et renvoyer 403 sur une valeur invalide, ce qui constitue la défense contre le DNS rebinding. L'authentification est recommandée sur toutes les connexions. Un serveur local est un processus qui exécute du code sur la machine hôte : la spécification recommande que le client exécute ce processus dans un bac à sable avec des privilèges par défaut minimaux, et qu'un serveur local restreigne l'accès à stdio ou à un canal IPC contraint tel qu'un socket de domaine unix. Les clients MCP qui récupèrent des URL de découverte OAuth devraient bloquer les requêtes vers les plages d'adresses privées et réservées, et les déploiements de clients MCP côté serveur devraient envisager un proxy de sortie — la partie qui couvre la falsification de requête côté serveur, où un serveur dirige un client vers des adresses réseau internes. Les serveurs mandataires qui utilisent des identifiants clients statiques doivent obtenir le consentement de l'utilisateur pour chaque client enregistré dynamiquement — la règle qui referme le cas du député embrouillé. L'isolation d'audience des jetons dit la même chose dans un autre vocabulaire : le serveur est la frontière.

Mis bout à bout, le tableau est celui-ci. Le serveur MCP est l'endroit par lequel passent les données et les actions de l'entreprise. Même lorsque le modèle tourne ailleurs, le serveur détermine quels outils existent, quelles ressources sont lisibles, et quelle identité porte quel appel en amont. Si ce serveur se trouve dans votre réseau et sous votre contrôle, toutes ces décisions restent quelque part où vous pouvez les auditer. La spécification note aussi que les descriptions et annotations d'outils devraient être considérées comme non fiables à moins de venir d'un serveur de confiance — et celui qui définit la confiance est celui qui trace la frontière.

La façon la plus courte de situer MCP : la majeure partie du code que vous écriviez pour connecter un modèle à un système d'entreprise n'a jamais porté sur le modèle. Elle portait sur la découverte, les schémas, l'identité, l'autorisation, la forme des états et le cycle de vie. MCP standardise cette partie et se tient à l'écart du reste. C'est pourquoi les questions de conception d'un serveur MCP ne sont pas du tout des questions de protocole : quelles actions deviennent des outils, quelles données deviennent lisibles comme ressources, et quelle identité atteint quel système en amont avec quelle portée. Le protocole clarifie où ces questions se posent. Y répondre reste un travail d'architecture.

Sources

• Model Context Protocol — specification, 2025-11-25 revision
• MCP specification — Authorization section (OAuth 2.1 roles, RFC 9728, error codes)
• MCP specification — Versioning and feature lifecycle
• MCP Blog — The 2026-07-28 MCP Specification Release Candidate
• MCP Blog — MCP joins the Agentic AI Foundation (9 December 2025)
• Anthropic — Introducing the Model Context Protocol (25 November 2024)