Comment fonctionne le Model Context Protocol en interne

Le problème que le MCP cherche à résoudre

Avant le MCP, chaque assistant IA qui voulait appeler un outil externe devait implémenter sa propre couche d'intégration. OpenAI proposait le function calling. Anthropic avait tool use. LangChain disposait de sa propre abstraction. Chacune obligeait le développeur d'outil à écrire un adaptateur distinct, et chacune posait des hypothèses légèrement différentes sur les schémas, la gestion d'erreurs et la transmission du contexte.

Le Model Context Protocol, publié par Anthropic fin 2024, est une tentative de standardiser cette interface. Pas uniquement pour Claude, mais pour tout agent IA qui souhaite consommer des capacités externes. L'objectif est un monde où un outil construit une seule fois fonctionne avec n'importe quel hôte conforme, sans réécrire l'intégration pour chacun d'eux.

L'ambition est raisonnable. Sa réussite dépend entièrement de la conception technique du protocole, et cette conception mérite d'être comprise en détail.

L'architecture client-serveur

Le MCP repose sur une séparation claire entre client et serveur. L'hôte est l'application IA, par exemple Claude Desktop, Cursor, ou un agent personnalisé que vous avez construit. Le client est un composant à l'intérieur de cet hôte qui gère la connexion à un serveur MCP. Le serveur est le processus externe qui expose des outils, des ressources ou des prompts.

Cette séparation a son importance car elle implique que l'application hôte ne dialogue pas directement avec votre base de données ou votre API. Elle dialogue avec un serveur MCP local ou distant, qui joue le rôle d'intermédiaire contrôlé. Le serveur définit précisément ce qu'il expose, et le client négocie ce qu'il utilise effectivement.

Un même hôte peut se connecter simultanément à plusieurs serveurs MCP. Un développeur qui utilise Cursor peut très bien faire tourner en parallèle un serveur MCP pour son intégration GitHub, un autre pour son système de documentation interne, et un troisième pour un outil de requêtes Postgres, le tout géré au travers de la même couche protocolaire.

JSON-RPC comme socle de transport

Le format de transport du MCP est JSON-RPC 2.0. Si vous avez déjà travaillé avec des language servers (le protocole LSP qui alimente les fonctionnalités d'IDE comme « aller à la définition »), cela vous semblera familier. JSON-RPC est un protocole d'appel de procédure distante léger qui encode les appels de méthode et les réponses sous forme d'objets JSON.

Une requête MCP de base ressemble à ceci :

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "sql": "SELECT * FROM orders WHERE status = 'pending'"
    }
  }
}

La réponse suit la même structure d'enveloppe, avec soit un champ result en cas de succès, soit un champ error contenant un code et un message en cas d'échec. Le champ id rattache les requêtes aux réponses, et c'est ainsi que le protocole gère les appels concurrents sans mélanger les résultats.

Le MCP prend en charge deux mécanismes de transport principaux. Le transport stdio exécute le serveur MCP comme sous-processus et communique via l'entrée et la sortie standard. C'est le réglage par défaut pour les outils locaux et c'est ce qu'utilise la plupart des serveurs MCP que vous trouverez sur les registres. Le HTTP avec Server-Sent Events (SSE) constitue l'option de transport distant : le client envoie ses requêtes via POST HTTP et reçoit les réponses en streaming par SSE. Un troisième transport, Streamable HTTP, a été introduit dans la révision de spécification de mars 2025 pour rationaliser une partie de la complexité de SSE.

L'approche stdio est simple et sûre pour un usage local. L'approche HTTP rend possibles les serveurs MCP hébergés, et c'est là que les choses deviennent plus intéressantes pour les déploiements en entreprise.

La poignée de main d'initialisation et la négociation de capacités

Lorsqu'un client se connecte à un serveur MCP, la première chose qui se produit est une poignée de main structurée. Ce n'est pas un cérémonial optionnel ; c'est ainsi que les deux parties s'accordent sur ce qu'elles peuvent réellement faire ensemble.

Le client envoie une requête initialize qui inclut sa version de protocole et un objet capabilities déclarant les fonctionnalités qu'il prend en charge :

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": {
      "name": "my-agent",
      "version": "1.0.0"
    }
  }
}

Le serveur répond avec sa propre déclaration de capacités, listant ce qu'il prend en charge. Outils, ressources, prompts, journalisation et fonctionnalités expérimentales disposent chacun de leurs propres drapeaux de capacités. Si le serveur prend en charge les outils, il le déclare. S'il prend en charge les abonnements aux ressources (le client peut alors surveiller une ressource pour détecter ses changements), il le déclare également.

Une fois le serveur ayant répondu, le client envoie une notification initialized pour confirmer la fin de la poignée de main. Ce n'est qu'après cette séquence en trois étapes que la session devient active. Cette conception fait qu'un client peut gérer avec élégance les serveurs qui ne prennent pas en charge certaines fonctionnalités, plutôt que d'échouer à l'exécution lorsqu'il tente d'appeler quelque chose qui n'existe pas.

Le versionnage du protocole est géré par cette même poignée de main. La version stable actuelle, à la mi-2025, est 2024-11-05, avec 2025-03-26 disponible pour les implémentations qui souhaitent les nouvelles options de transport. Si client et serveur ne parviennent pas à s'accorder sur une version compatible, la connexion échoue proprement à l'initialisation plutôt que de produire un comportement indéfini par la suite.

Les trois primitives : outils, ressources et prompts

Les serveurs MCP exposent leurs capacités à travers trois primitives distinctes, et comprendre la différence entre elles est important aussi bien pour construire que pour évaluer un serveur MCP.

Les outils (tools) sont des fonctions appelables. Ils possèdent un nom, une description et un schéma d'entrée défini au format JSON Schema. Lorsqu'un modèle d'IA décide d'utiliser un outil, l'hôte appelle tools/call avec le nom de l'outil et les arguments. Le serveur exécute la fonction et renvoie un résultat. C'est la primitive la plus courante et celle à laquelle la plupart des gens pensent quand on évoque le MCP.

Les ressources (resources) sont des sources de données que le serveur expose pour que le modèle puisse les lire. Une ressource possède un URI, un type MIME et un contenu. Les ressources peuvent être statiques (un fichier de configuration) ou dynamiques (un enregistrement de base de données en direct). Les clients découvrent les ressources disponibles via resources/list et les récupèrent avec resources/read. Certains serveurs prennent en charge resources/subscribe, qui pousse les mises à jour vers le client lorsqu'une ressource change.

Les prompts sont des modèles de prompt réutilisables que les serveurs peuvent exposer. C'est la primitive la moins utilisée à l'heure actuelle, mais elle est utile lorsqu'un serveur veut proposer des manières standardisées d'invoquer ses capacités, des instructions préfabriquées pour des flux de travail courants que l'hôte peut faire remonter à l'utilisateur.

Un seul serveur MCP peut exposer simultanément les trois types. Un serveur MCP pour GitHub peut exposer des outils pour créer des issues et des PR, des ressources pour lire le contenu des fichiers et les métadonnées du dépôt, et des prompts pour des flux de relecture de code courants.

Sampling : quand le serveur s'adresse au modèle

L'une des fonctionnalités les plus intéressantes sur le plan architectural du MCP est le sampling. La plupart des gens supposent que le flux de données est unidirectionnel : le modèle appelle des outils, les outils retournent des données. Le sampling inverse ce schéma.

Avec le sampling, un serveur MCP peut demander à l'hôte d'interroger le modèle de langage pour qu'il génère quelque chose. Le serveur envoie une requête sampling/createMessage au client, qui la transmet au modèle, et la réponse du modèle est ensuite retournée au serveur. Cela autorise des schémas agentiques dans lesquels l'outil lui-même a besoin du raisonnement d'un LLM dans le cadre de son exécution.

Imaginez un serveur MCP qui traite des documents. Il pourrait extraire du texte brut, puis utiliser le sampling pour demander au modèle de classifier le type de document avant de décider comment structurer la sortie. Le serveur orchestre l'appel au modèle sans que l'application hôte ait besoin d'avoir connaissance de cette étape intermédiaire.

Le sampling est une capacité que le client déclare au moment de l'initialisation. Si un client ne le prend pas en charge, les serveurs qui en dépendent le sauront d'emblée et pourront soit dégrader gracieusement, soit refuser la connexion.

Pourquoi cette architecture compte pour l'interopérabilité

La valeur pratique de la conception du MCP devient claire lorsqu'on regarde les chiffres d'adoption. À la mi-2025, Skillful.sh indexe plus de 137 000 serveurs MCP sur plus de 50 répertoires. Cette échelle n'est possible que parce que le protocole offre aux développeurs d'outils une cible unique sur laquelle bâtir.

Avant le MCP, un développeur qui construisait une intégration Notion devait écrire un adaptateur pour Claude, un autre pour le function calling de GPT-4, un autre pour Gemini, et ainsi de suite. Avec le MCP, il écrit un seul serveur qui fonctionne avec tout hôte conforme. Claude Desktop, Cursor, Zed, Continue et une liste croissante d'agents personnalisés parlent tous le même protocole.

Les implications de sécurité de cette architecture sont également significatives. Les serveurs MCP étant des processus séparés avec des déclarations explicites de capacités, il est possible d'analyser ce qu'un serveur fait réellement avant de s'y connecter. L'analyse statique peut vérifier si les outils déclarés par un serveur correspondent au comportement effectif de son code. Les risques d'injection de prompt, lorsqu'un serveur malveillant tente de détourner le comportement du modèle via les réponses d'outils, peuvent être détectés en examinant les motifs de réponse. C'est la base sur laquelle reposent les systèmes de notation de sécurité qui évaluent les serveurs MCP en fonction de leur profil de risque réel et non de leur seule documentation.

Le socle JSON-RPC fait également que le MCP est inspectable. Vous pouvez journaliser chaque message entre client et serveur, rejouer des sessions pour le débogage, et valider la conformité au protocole avec des outils standards. C'est un avantage non négligeable par rapport aux intégrations opaques fondées sur des SDK où la couche de communication est enfouie dans le code de la bibliothèque.

Là où la spécification actuelle a encore des aspérités

Le MCP est encore en phase de maturation, et plusieurs zones laissent voir les coutures. L'authentification en fait partie. La spécification 2025-03-26 a ajouté la prise en charge d'OAuth 2.1 pour les serveurs distants, mais les serveurs stdio locaux n'ont pas de mécanisme d'authentification standardisé. Pour les déploiements en entreprise où vous exécutez des serveurs MCP qui accèdent à des systèmes internes sensibles, cela signifie qu'il faut implémenter votre propre contrôle d'accès au niveau du serveur.

Le modèle d'abonnement aux ressources est puissant, mais il n'est pas universellement implémenté. De nombreux serveurs MCP qui prétendent prendre en charge les ressources n'implémentent en réalité que les opérations de lecture de base, pas les abonnements. Les clients qui s'appuient sur les mises à jour push pour des données en temps réel constateront un comportement incohérent d'un serveur à l'autre.

La validation des schémas d'outils est elle aussi laissée largement à la charge du serveur. Le protocole exige des serveurs qu'ils déclarent un JSON Schema pour les entrées d'outils, mais n'impose pas de validation stricte des arguments avant exécution. Un serveur mal écrit peut accepter des entrées malformées et produire des erreurs confuses plutôt que de propres échecs de validation. Lorsque vous évaluez un serveur MCP pour un usage en production, il vaut la peine de tester explicitement les cas limites dans la gestion des arguments d'outils.

Bâtir sur le MCP : ce qu'il faut savoir avant de commencer

Si vous construisez un serveur MCP, les SDK officiels TypeScript et Python prennent en charge la mécanique du protocole, ce qui fait que vous écrivez essentiellement la logique métier de vos outils et ressources. Le SDK TypeScript a en particulier une bonne ergonomie pour définir des schémas d'outils avec Zod et gérer le cycle de vie d'initialisation.

Si vous construisez une application hôte qui consomme des serveurs MCP, le SDK client gère l'état de la connexion, la négociation de capacités et le routage des requêtes. La principale décision à prendre est de savoir si vous vous connectez à des serveurs stdio locaux, à des serveurs HTTP distants, ou aux deux, car la configuration du transport diffère.

Pour évaluer un serveur MCP existant avant de l'intégrer, la conception de la négociation de capacités fait que vous pouvez inspecter ce qu'un serveur déclare par rapport à ce qu'il fait réellement. Les serveurs qui déclarent des capacités minimales mais qui disposent dans leur code d'un large accès au système de fichiers ou au réseau sont un signal d'alerte qui mérite enquête. Le recoupement des indicateurs d'adoption d'un serveur, de sa présence dans les répertoires et de sa note de sécurité vous donne un signal raisonnable sur la pertinence de l'effort d'intégration.

Le protocole est suffisamment précis pour être utile et suffisamment souple pour accueillir une grande variété de types d'outils. Cet équilibre est ce qui en fait un socle crédible pour l'interopérabilité des outils IA : pas une garantie, mais un point de départ solide pour l'écosystème qui se construit par-dessus.

Lectures complémentaires

Parcourez les serveurs MCP sur Skillful.sh. Cherchez plus de 137 000 outils IA sur Skillful.sh.