Fondamentaux de MCP : hôtes, clients, serveurs et le format de transmission JSON-RPC

Les modèles de langage sont devenus véritablement utiles pour les entreprises dès qu’ils ont pu agir, et non seulement répondre. La difficulté n’a jamais résidé dans le modèle lui-même ; elle a toujours été liée à son intégration aux bases de données, aux API et aux outils internes où le travail a réellement lieu, ainsi qu’à l’installation de ces connexions une seule fois plutôt que pour chaque application et pour chaque fournisseur de modèle. Le Model Context Protocol (MCP) constitue une tentative de standardiser ces connexions. Cet article explique le problème que résout MCP, les rôles de ses composants, ce qui est transmis via ces connexions, et en quoi les deux protocoles de transmission standards diffèrent, afin que vous puissiez déterminer où un serveur MCP s’intègre dans votre propre architecture.

Où les LLM créent de la valeur : en prenant des actions

Autrefois, une grande partie de l’automatisation était inatteignable simplement parce que les logiciels ne pouvaient pas interpréter des requêtes à structure lâche. Les modèles de langage éliminent cet obstacle ; une fois connectés à des outils, ils peuvent gérer des workflows en plusieurs étapes qui exigeaient auparavant que quelqu’un se déplace d’un système à l’autre.

Prenons l’exemple d’un assistant chargé de trouver et de réserver un train de Casablanca à Rabat. Comprendre la demande n’est que la première étape : l’assistant doit rechercher dans un service d’horaires, choisir une heure de départ, appeler une API de réservation et confirmer le résultat. Chacune de ces étapes correspond à une appel à un outil. Lorsque ces outils sont mis à disposition via un serveur MCP, n’importe quel agent compatible peut effectuer l’intégralité du processus.

Le cas d’affaires en découle directement : moins d’étapes manuelles par tâche signifie des coûts opérationnels plus faibles et un délai de traitement plus rapide. Il y a aussi l’argument lié à l’expérience utilisateur. Les employés doivent gérer régulièrement de nombreux tableaux de bord et interfaces, chacun avec sa propre logique. Une interface conversationnelle connectée à ces systèmes backend peut cacher une grande partie de cette complexité derrière une seule interface.

Le problème d’intégration que MCP résout

L’utilisation d’outils n’est pas une nouveauté. Chaque SDK majeur pour LLM le prend en charge, mais chacun le fait selon ses propres conventions pour déclarer un outil, décrire les paramètres et retourner des résultats. En pratique, le même outil est implémenté plusieurs fois, une fois par fournisseur de modèle. Changer de modèle ou en prendre en charge deux en même temps signifie de devoir reporter ce code d’intégration, ce qui ralentit les équipes et rend plus difficile l’extension des produits.

Omettre les SDK ne résout pas complètement ce problème. Vous pouvez créer votre propre couche d’intégration qui associe les intentions aux actions, appelle des points de terminaison, collecte des paramètres, gère les erreurs et enregistre des données analytiques. Cela ajoute de la complexité, mais elle reste gérable. Le problème plus fondamental est que ce type de couche se trouve généralement à l’intérieur d’une seule application. Lorsqu’une deuxième application a besoin des mêmes outils, l’équipe doit reconstruire cette même couche. La logique d’intégration est alors liée à l’application utilisatrice plutôt qu’au système qui possède la capacité en question.

Qu’est-ce que MCP ?

MCP est une norme ouverte qui offre aux applications d’intelligence artificielle un moyen standardisé de se connecter à des sources de données et à des outils. Elle ne permet pas ce qui était strictement impossible auparavant ; elle rend ces connexions plus simples et plus cohérentes. La documentation du protocole disponible sur modelcontextprotocol.io constitue la référence officielle.

Le changement clé réside dans l’endroit où se trouve la logique des outils. Avec MCP, un service backend tel qu’une base de données, une API ou un outil interne publie ses capacités via un serveur MCP. L’analogie souvent utilisée est celle d’un port USB-C : le service expose un socket standard, et toute application compatible peut s’y connecter. L’application d’intelligence artificielle ne contient plus les connaissances nécessaires pour utiliser chaque outil ; elle a simplement besoin de maîtriser le protocole.

L’architecture : hôtes, clients et serveurs

MCP utilise une architecture client-serveur avec trois rôles qui peuvent facilement prêter à confusion :

• Hôte : l’application d’intelligence artificielle elle-même, par exemple un assistant de chat, un IDE doté d’un agent, ou votre propre service d’agent. C’est avec cet élément que l’utilisateur interagit, et il se connecte au monde extérieur à travers un ou plusieurs serveurs MCP.

Client : un composant à l’intérieur de l’hôte qui établit et maintient la connexion avec un seul serveur MCP. C’est le « connecteur » dans l’analogie USB-C.

Serveur : un programme qui offre des fonctionnalités aux clients de manière standardisée.

L’hôte ne communique jamais directement avec un serveur. Il crée un client par serveur et délègue toute la communication à celui-ci, chaque client disposant d’une connexion un-à-un dédiée. Cette séparation est utile en pratique : un hôte connecté à un serveur de système de fichiers, à un serveur de gestion des tickets et à un serveur CRM exécute trois clients indépendants, de sorte qu’une panne ou un problème de permissions sur une connexion n’affecte pas les autres.

Les trois primitives de serveur

Les primitives définissent ce que chaque partie peut offrir. Un serveur expose trois types principaux :

• Outils : opérations que le modèle peut exécuter, telles que l’appel d’une API ou l’écriture d’un enregistrement.
• Ressources : données que le modèle peut lire et utiliser comme contexte, telles que des lignes de base de données ou des documents.
• Prompts : modèles d’instructions prédéfinis qui guident le modèle, similaires en esprit aux prompts système réutilisables.

La distinction entre outils et ressources est importante pour la sécurité et la conception. La lecture d’une ressource ne doit pas entraîner de effets secondaires, tandis que l’invoque d’un outil peut modifier le monde réel ; c’est pourquoi les hébergeurs appliquent souvent des règles d’approbation différentes pour chacun.

JSON et JSON-RPC : le format des messages

JSON (JavaScript Object Notation) représente des données structurées sous forme de texte composé de paires clé-valeur, d’arrays et d’objets imbriqués. Comme ce format est simple et universellement supporté, un émetteur et un récepteur écrits dans des langages différents peuvent s’accorder sur la signification d’un message.

JSON-RPC s’appuie sur ce principe en définissant une structure de message fixe pour les appels de procédures à distance. Une requête indique une méthode, contient des paramètres et inclut un identifiant ; si les deux parties respectent cette structure, le client peut demander au serveur d’exécuter une méthode et recevoir le résultat, ou une erreur, dans un format tout aussi prévisible. L’exemple ci-dessous est une requête JSON-RPC 2.0 demandant à un serveur de rechercher les conditions météorologiques à Casablanca. Notez les quatre champs : la version du protocole, un id de requête utilisé pour correspondre à la réponse, le nom de la méthode et l’objet params.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "get_weather",
  "params": {
     "city": "Casablanca"
   }
}

Cet exemple illustre le JSON-RPC pur. Dans MCP lui-même, les outils ne sont pas invoqués en tant que méthodes de niveau supérieur portant leur nom. Au lieu de cela, le client envoie une requête utilisant la méthode tools/call, en plaçant le nom de l’outil et ses arguments à l’intérieur de params. Cet échappement permet à MCP de définir un vocabulaire fixe de méthodes de protocole, tandis que les serveurs restent libres d’exposer tous les outils qu’ils souhaitent.

La découverte est l’élément manquant

JSON-RPC présente un problème : le client doit déjà connaître quels méthodes propose le serveur. MCP comble cette lacune en standardisant la manière dont les clients découvrent leurs capacités. Un client peut demander à un serveur de lister ses outils, ressources et prompts, recevant ainsi des noms, des descriptions et des schémas d’entrée, qu’il peut ensuite transmettre au modèle. MCP précise également comment la connexion est initialisée et quels mécanismes de transport transmettent les messages.

Mécanismes de transport : comment les messages voyagent

JSON-RPC définit le vocabulaire ; le transport définit la manière dont les octets se déplacent entre le client et le serveur. Au moment de la rédaction, MCP spécifie deux transports standard. Vérifiez la spécification actuelle avant de vous fier aux détails, car le protocole continue d’évoluer.

stdio pour les outils locaux

Avec le transport stdio, le client lance le serveur MCP en tant que processus enfant. Le serveur lit les messages reçus depuis sa sortie standard et écrit les réponses vers son entrée standard. Chaque processus reçoit automatiquement ces canaux du système d’exploitation, de sorte qu’aucun socket réseau ni port n’est nécessaire.

Cela rend stdio particulièrement adapté aux outils qui s’exécutent sur la même machine que l’hôte, par exemple un serveur qui crée des dossiers dans le système de fichiers local. Un avantage supplémentaire est l’isolation : le serveur n’existe que tant que l’hôte le maintient en cours d’exécution et il n’est pas accessible depuis le réseau.

Streamable HTTP pour des serveurs partagés à distance

Avec Streamable HTTP, le serveur est un processus indépendant qui fonctionne en tant que service HTTP et peut servir de nombreux clients en même temps. Les messages sont échangés via des requêtes HTTP ordinaires.

Ce type de transport permet le streaming. Au lieu d’attendre une réponse complète, le serveur peut envoyer des données progressivement, ce qui est avantageux pour les appels à des outils longs. Le streaming s’obtient grâce aux événements envoyés par le serveur (SSE), un canal unidirectionnel dans lequel une réponse HTTP de longue durée contient une séquence d’événements envoyés par le serveur. Le trafic dans l’autre direction reste constitué de demandes HTTP ordinaires émises par le client. Le comportement détaillé dépend de l’implémentation et de la version HTTP utilisée.

Règle pratique : choisissez stdio lorsque l’outil est utilisé uniquement sur la machine d’un utilisateur, et choisissez Streamable HTTP lorsque des fonctionnalités doivent être partagées entre utilisateurs ou équipes, avec les mécanismes d’authentification et de contrôle réseau nécessaires aux services partagés.

Pourquoi un protocole est plus important qu’un autre SDK

Les protocoles existent afin que des systèmes développés par différentes équipes, en langages différents et selon des calendriers de publication variés puissent encore interagir de manière prévisible. Un protocole est un ensemble d’ règles convenues définissant la manière dont des composants indépendants communiquent, interprètent les messages des uns et des autres et établissent une confiance mutuelle.

La valeur de la standardisation de l’accès aux outils est principalement économique. Lorsque le coût d’intégration d’un nouveau modèle ou d’une nouvelle application tend vers zéro, l’expérimentation devient peu coûteuse, et des expériences bon marché permettent des itérations plus rapides. L’équipe en charge d’un système peut publier un seul serveur MCP, et toutes les applications d’IA actuelles et futures de l’organisation peuvent l’utiliser sans avoir besoin de code d’intégration sur mesure. Pour voir comment cela fonctionne au sein d’un framework d’agents, consultez notre article sur la standardisation de l’intégration des outils dans LangGraph avec MCP.

Points clés

• Les LLM offrent le plus de valeur lorsqu’ils peuvent interagir avec des systèmes réels, et le goulot d’étranglement réside dans l’intégration, non dans l’intelligence.
• En l’absence de norme, le même outil doit être réimplémenté pour chaque SDK de modèle et pour chaque application ; MCP déplace cette logique vers un serveur géré par le système qui fournit la fonctionnalité.
• Un hôte exécute un client par serveur, et chaque client maintient une connexion dédiée ; les serveurs fournissent des outils, des ressources et des prompts.
• JSON-RPC définit la structure des messages, tandis que MCP ajoute un vocabulaire de méthodes fixes, comme tools/call, ainsi que des mécanismes de découverte des capacités.
• Utilisez stdio pour les outils locaux à usage unique et Streamable HTTP pour les services distants partagés, et vérifiez les détails de transport conformément à la spécification en vigueur.