☰ Menu

06.10.2026 · Signal Titans Editorial

Comment les applications hôtes font le pont entre Model Context Protocol et les API de LLM

Découvrez comment les applications hôtes MCP gèrent trois traductions de protocole entre les registres d'outils JSON-RPC et les API de LLM.

Illustration éditoriale montrant un pont géométrique en verre au centre reliant deux plateformes métalliques modulaires dotées de douilles en laiton et de ports en acier sombre.

Les applications qui intègrent le Model Context Protocol (MCP) avec des API externes de modèles de langage s'appuient sur une couche d'orchestration appelée hôte pour relier deux normes de communication distinctes. Alors que les serveurs MCP communiquent via des formats JSON-RPC pour exposer et exécuter des outils, les fournisseurs de modèles utilisent des structures d'API personnalisées pour les paramètres d'outils et l'appel de fonctions. Pour mener à bien le cycle de vie d'une seule invocation d'outil, le système hôte opère sur quatre phases — la découverte, la décision, l'exécution et la réponse finale — tout en réalisant trois traductions de protocole distinctes entre ces frontières.

Conversion des schémas lors de la découverte des outils

Pendant la phase initiale de découverte, l'hôte demande les outils disponibles au serveur MCP connecté en effectuant un appel JSON-RPC tools/list. Le serveur MCP renvoie alors des contrats publics contenant les noms des outils, leurs descriptions et leurs schémas d'entrée, tout en conservant les gestionnaires de code exécutable au sein de son propre registre d'outils. Étant donné que les API des fournisseurs imposent leurs propres normes de formatage, l'hôte effectue sa première traduction en convertissant le schéma JSON-RPC du MCP vers la structure de paramètres attendue par le fournisseur du modèle avant de transmettre la requête de l'utilisateur et les définitions d'outils au LLM.

Traduction des décisions du modèle pour l'exécution à distance

Une fois que le modèle sélectionne un outil et génère les valeurs d'entrée, il renvoie à l'hôte un appel de fonction formaté selon l'API du fournisseur. L'hôte réalise ensuite sa deuxième traduction en transformant cette charge utile en un message JSON-RPC MCP tools/call. À la réception de cet appel, le serveur MCP consulte son registre d'outils et valide les arguments générés par le modèle par rapport à son schéma avant d'exécuter le gestionnaire d'outil. Cette étape garantit que les sorties du modèle subissent une validation explicite avant toute exécution de code.

Formatage des résultats pour la réponse du modèle

Après l'exécution de l'outil par le serveur MCP, ce dernier transmet un résultat JSON-RPC au format MCP vers le client. L'hôte procède à sa troisième traduction en convertissant le résultat structuré MCP dans le format de réponse d'outil désigné par le fournisseur. L'hôte achemine ensuite cette charge utile accompagnée du contexte de conversation existant vers le modèle, ce qui permet au LLM d'interpréter le résultat de l'outil et de produire une réponse en langage naturel pour l'utilisateur final.

Illustration éditoriale générée par IA ; ce n’est pas une photographie documentaire.

Source: Two Protocols, Three Translations: How a Host Bridges MCP and an LLM Provider API