Serveurs MCP : ce que le Model Context Protocol standardise vraiment

Toutes les explications de MCP commencent par la même phrase : c'est l'USB-C de l'IA. L'analogie n'est pas une invention marketing, elle vient de la spécification elle-même, et elle est bonne. Mais elle s'arrête exactement là où commencent les questions utiles. Que livre réellement un serveur ? Qui parle à qui ? Et qu'est-ce que la dernière révision a discrètement retiré des tutoriels que vous vous apprêtez à recopier ?

Ce qu'est MCP, dans les termes de la spécification

La documentation officielle définit MCP comme un standard open source permettant de connecter des applications d'IA à des systèmes externes. Grâce à lui, des applications comme Claude ou ChatGPT peuvent se connecter à des sources de données, des outils et des workflows, ce qui leur permet d'accéder à de l'information et d'accomplir des tâches.

Vient ensuite l'analogie que tout le monde reprend : voyez MCP comme un port USB-C pour les applications d'IA. De la même façon que l'USB-C offre une manière standardisée de connecter des appareils électroniques, MCP offre une manière standardisée de connecter des applications d'IA à des systèmes externes.

Ce qu'il faut retenir de cette comparaison, c'est ce qu'elle exclut. Un standard de connecteur ne dit rien des appareils. La documentation pose d'ailleurs la même restriction noir sur blanc : MCP porte 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. Si vous espériez que MCP vous dise comment construire votre agent, il ne le fera pas. Il vous dit comment y brancher des choses.

Hôte, client, serveur : trois rôles constamment confondus

C'est là que la plupart des discussions d'architecture dérapent, parce que dans le langage courant « le client MCP » et « l'application » semblent désigner la même chose. Dans la spécification, non :

Hôte MCP. L'application d'IA qui coordonne et gère un ou plusieurs clients MCP. Claude Desktop et Visual Studio Code sont des hôtes.

Client MCP. Un composant qui maintient une connexion vers un serveur MCP et en obtient du contexte pour l'hôte. C'est un objet de connexion à l'intérieur de l'hôte, pas un logiciel que vos utilisateurs installent.

Serveur MCP. Un programme qui fournit du contexte aux clients MCP.

La relation entre les deux derniers est strictement de un à un. L'hôte crée un client MCP pour chaque serveur MCP, et chaque client maintient une connexion dédiée avec le serveur correspondant. Connectez VS Code à un serveur Sentry et à un serveur de système de fichiers, et le runtime instancie deux objets clients distincts. Il n'y a aucun canal multiplexé partagé à raisonner, ce qui simplifie considérablement le débogage.

Les trois choses qu'un serveur peut exposer, et pourquoi la distinction compte

Les primitives sont le cœur de MCP, et se tromper de primitive est l'erreur de conception la plus fréquente sur un premier serveur. La spécification en définit trois côté serveur :

Les outils. Des fonctions exécutables que les applications d'IA peuvent invoquer pour agir, par exemple des opérations sur des fichiers, des appels d'API ou des requêtes en base. Un outil fait quelque chose.

Les ressources. Des sources de données qui fournissent de l'information contextuelle, par exemple le contenu de fichiers, des enregistrements en base ou des réponses d'API. Une ressource se lit.

Les prompts. Des modèles réutilisables qui aident à structurer les interactions avec les modèles de langage, par exemple des prompts système ou des exemples few-shot.

L'exemple donné par la documentation elle-même est le meilleur test pour savoir si vous avez bien choisi. Pour un serveur exposant une base de données, elle suggère des outils pour interroger la base, une ressource contenant le schéma, et un prompt avec des exemples few-shot pour se servir des outils. Même base, trois primitives différentes, chacune répondant à une question différente. Si vous vous surprenez à exposer votre schéma comme un outil, c'est le signe que vous avez confondu « une donnée que le modèle doit lire » et « une action que le modèle peut déclencher ».

Chaque type de primitive dispose de méthodes de découverte, et les clients utilisent les méthodes de liste pour savoir ce qui existe avant de s'en servir. C'est ce qui rend les listings dynamiques plutôt que figés dans le client à la compilation.

Deux transports, et la question de sécurité qui en découle

MCP comporte deux couches : une couche de données définissant le protocole fondé sur JSON-RPC, et une couche de transport définissant les mécanismes de communication. Le protocole utilise JSON-RPC 2.0, et le même format de message circule sur tous les transports, raison pour laquelle le choix du transport ne change pas la façon d'écrire vos handlers.

Transport stdio. Utilise les flux d'entrée et de sortie standard pour une communication directe entre processus locaux sur la même machine, avec des performances optimales et aucun surcoût réseau.

Transport Streamable HTTP. Utilise des requêtes HTTP POST pour les messages du client vers le serveur, avec des Server-Sent Events optionnels pour le streaming. C'est lui qui permet la communication avec un serveur distant, et il prend en charge les méthodes d'authentification HTTP standard, notamment les jetons bearer, les clés d'API et les en-têtes personnalisés. La spécification recommande d'utiliser OAuth pour obtenir les jetons.

Notez ce que cela implique, car c'est rarement dit. Un serveur stdio n'a pas d'authentification propre : c'est un processus lancé par l'hôte, qui tourne avec les permissions de ce processus. C'est parfaitement raisonnable pour un serveur de fichiers sur votre propre poste, et c'est le mauvais modèle dès l'instant où le même code est exposé en HTTP. La documentation observe aussi qu'un serveur stdio local sert typiquement un seul client, là où un serveur HTTP distant en sert typiquement plusieurs, ce qui relève autant de la charge et de l'isolation que du réseau.

Ce que la révision 2026-07-28 a déprécié

C'est la section qui vous évitera de recopier un tutoriel périmé, car deux fonctionnalités côté client, présentes dans la plupart des contenus existants sur MCP, ne sont plus la voie recommandée.

Le sampling est déprécié depuis la version de protocole 2026-07-28. Il permettait à un serveur de demander des complétions de modèle à l'application d'IA cliente, ce qui était séduisant : l'auteur d'un serveur restait indépendant du modèle et évitait d'embarquer un SDK de LLM. La documentation oriente désormais les nouvelles implémentations vers une intégration directe aux API des fournisseurs de LLM.

Le logging est déprécié dans la même révision, les nouvelles implémentations devant écrire sur stderr en transport stdio, ou utiliser OpenTelemetry.

Ce qui subsiste côté client est l'elicitation, qui permet à un serveur de demander des informations complémentaires à l'utilisateur. C'est le mécanisme pour poser une question ou faire confirmer une action en cours d'opération, et c'est celui vers lequel se tourner quand un serveur a besoin d'une entrée qu'il ne peut pas deviner.

La même révision explicite aussi l'absence d'état : chaque requête porte la version du protocole et les capacités pertinentes dans son champ meta, si bien que le serveur peut traiter chaque requête isolément. Les serveurs annoncent les versions et capacités qu'ils prennent en charge via une requête de découverte obligatoire, que les clients peuvent envoyer avant toute autre. Concrètement, un serveur MCP n'a pas besoin de se souvenir de son interlocuteur d'un appel à l'autre, ce qui rend la mise à l'échelle horizontale d'un serveur distant nettement moins douloureuse.

Pourquoi cela dépasse la question du protocole

L'enjeu stratégique n'est pas le JSON. C'est que MCP est un protocole ouvert pris en charge par un large éventail de clients et de serveurs, des assistants comme Claude et ChatGPT aux outils de développement comme Visual Studio Code et Cursor, ce qui, selon les termes de la documentation, permet de construire une fois et d'intégrer partout.

Pour une entreprise, cela change la nature de la question d'intégration. Exposer ses systèmes internes via un serveur MCP n'est pas un pari sur l'assistant d'un éditeur particulier. C'est le même travail qui se rentabilise sur chaque hôte parlant le protocole, aujourd'hui et demain. Le profil de risque est très différent de celui d'un plugin sur mesure pour un seul produit, et c'est la principale raison pour laquelle MCP mérite une place dans une feuille de route d'intégration plutôt que dans un dossier de preuves de concept.

Questions fréquentes

Qu'est-ce que le Model Context Protocol en une phrase ?

La spécification le définit comme un standard open source permettant de connecter des applications d'IA à des systèmes externes. Sa propre documentation propose l'analogie que tout le monde reprend : voyez MCP comme un port USB-C pour les applications d'IA, car de la même façon que l'USB-C offre une manière standardisée de connecter des appareils électroniques, MCP offre une manière standardisée de connecter des applications d'IA à des systèmes externes. Ce que l'analogie a d'utile, c'est qu'elle porte sur le connecteur et non sur l'appareil : MCP porte uniquement sur le protocole d'échange de contexte et ne dicte pas comment les applications utilisent les LLM ni comment elles gèrent le contexte reçu.

Quelle différence entre hôte, client et serveur MCP ?

Ce sont trois rôles distincts, et les confondre est la source la plus fréquente d'erreurs d'architecture. La spécification définit l'hôte MCP comme l'application d'IA qui coordonne et gère un ou plusieurs clients MCP, le client MCP comme le composant qui maintient une connexion vers un serveur MCP et en obtient du contexte pour l'hôte, et le serveur MCP comme un programme qui fournit du contexte aux clients MCP. La relation est d'un client par serveur : l'hôte crée un client MCP pour chaque serveur MCP, et chaque client maintient une connexion dédiée.

Qu'un serveur MCP peut-il réellement exposer ?

Trois primitives, qui ne sont pas interchangeables. Les outils sont des fonctions exécutables que les applications d'IA peuvent invoquer pour agir, par exemple des opérations sur des fichiers, des appels d'API ou des requêtes en base. Les ressources sont des sources de données qui fournissent de l'information contextuelle, par exemple le contenu de fichiers, des enregistrements en base ou des réponses d'API. Les prompts sont des modèles réutilisables qui aident à structurer les interactions avec les modèles de langage. Chaque primitive dispose de méthodes de découverte, et les clients utilisent les méthodes de liste pour savoir ce qui est disponible avant de s'en servir, ce qui rend les listings dynamiques.

Un serveur MCP local diffère-t-il d'un serveur distant ?

Par le transport seulement, pas par nature. La spécification précise que serveur MCP désigne le programme qui sert les données de contexte, quel que soit l'endroit où il s'exécute. Ce qui change est le transport : stdio utilise les flux d'entrée et de sortie standard pour une communication directe entre processus locaux sur la même machine, sans surcoût réseau, tandis que Streamable HTTP utilise des requêtes HTTP POST avec des Server-Sent Events optionnels et permet la communication à distance. La documentation note qu'un serveur stdio local sert typiquement un seul client, là où un serveur HTTP distant en sert typiquement plusieurs.

MCP gère-t-il l'authentification ?

Elle est traitée au niveau du transport, et seul le transport HTTP en a besoin. La spécification indique que le transport Streamable HTTP prend en charge les méthodes d'authentification HTTP standard, notamment les jetons bearer, les clés d'API et les en-têtes personnalisés, et que MCP recommande d'utiliser OAuth pour obtenir les jetons. Un serveur stdio, lui, hérite des permissions du processus qui l'a lancé : c'est une propriété de sécurité qu'il vaut mieux énoncer clairement avant d'en exposer un.

Qu'est-ce que la révision 2026-07-28 a changé ?

Deux choses à connaître avant de recopier un tutoriel ancien. Le sampling, qui permettait à un serveur de demander des complétions de modèle au client, est déprécié depuis la version de protocole 2026-07-28, et la documentation oriente désormais les nouvelles implémentations vers une intégration directe aux API des fournisseurs de LLM. Le logging est déprécié dans la même révision, les nouvelles implémentations devant écrire sur stderr en transport stdio ou utiliser OpenTelemetry. Le protocole est par ailleurs sans état : chaque requête porte la version du protocole et les capacités pertinentes dans son champ meta, si bien que le serveur peut traiter chaque requête isolément.

La définition de MCP, l'analogie de l'USB-C, l'énoncé selon lequel MCP porte uniquement sur le protocole d'échange de contexte, les définitions de l'hôte, du client et du serveur, la relation d'un client par serveur, les définitions des outils, des ressources et des prompts, les deux transports et leurs propriétés, la recommandation OAuth, la dépréciation du sampling et du logging depuis la version de protocole 2026-07-28, et l'absence d'état du protocole proviennent tous de la documentation officielle du Model Context Protocol, consultée au moment de la rédaction. Le protocole est révisé : vérifiez sur la révision que vous visez.

L'accompagnement ZAX sur MCP et l'intégration IA

Notre équipe construit des serveurs MCP qui exposent les systèmes internes aux applications d'IA, et les intègre à des produits existants.

Audit et cadrage. Un audit IA gratuit de 30 minutes établit quels de vos systèmes méritent d'être exposés, quelle primitive convient à chacun, et si stdio ou HTTP est le bon transport au vu de vos contraintes.

Développement et intégration. Conception du serveur, modélisation des primitives, authentification sur le transport HTTP, et tests d'intégration contre de vrais hôtes.

Contactez-nous pour discuter de l'exposition de vos systèmes via MCP.