MCP : comment un agent se connecte à vos outils

Une cliente cherche une veste bleue en taille M. La vendeuse interroge son assistant IA : « Est-ce qu’il en reste dans notre magasin de Lyon ? »

Pour répondre, l’assistant doit identifier le produit, consulter le stock du bon magasin et lire le résultat. Son modèle de langage sait interpréter la question. La quantité disponible, elle, se trouve dans le logiciel du commerce.

C’est le point de départ de MCP : donner à une application d’IA un moyen commun de découvrir et d’utiliser les capacités d’un autre logiciel.

Le problème : relier l’assistant au logiciel métier

Le commerce possède déjà une API qui permet de consulter son stock. Une équipe peut donc programmer une connexion pour son assistant : choisir la bonne route, transmettre les identifiants et traiter la réponse.

Puis le commerce veut rendre cette fonction accessible dans une seconde application d’IA. Si celle-ci attend une autre façon de déclarer et d’appeler les outils, une partie de l’intégration doit être adaptée. À mesure que les applications et les services se multiplient, ces adaptations s’accumulent.

Le besoin est de partager une interface de connexion, tout en conservant les logiciels métier existants.

L’arrivée de MCP

Le 25 novembre 2024, Anthropic présente et publie en open source le Model Context Protocol. Son objectif est de standardiser les échanges entre les applications d’IA et les systèmes qui détiennent leurs données ou exécutent leurs actions. Annonce originale d’Anthropic

Dans notre commerce, une équipe crée un serveur MCP qui expose la consultation du stock. Une application compatible peut alors découvrir cet outil et l’appeler selon les règles du protocole. L’API du commerce reste derrière le serveur et continue de fournir les données.

Le fonctionnement technique : qui fait quoi ?

Reprenons la question de la vendeuse. Trois rôles se répartissent le travail :

• L’application hôte est l’assistant qu’elle utilise. Elle affiche la conversation, sollicite le modèle et pilote l’exécution des outils.
• Le client MCP est un composant de cette application. Il envoie les demandes au serveur au format MCP et reçoit ses réponses. La vendeuse ne l’utilise pas séparément.
• Le serveur MCP est le programme qui expose les outils du commerce. Pour consulter_stock, il appelle l’API de stock et renvoie le résultat. Le logiciel métier reste responsable des quantités et des règles d’accès. Architecture MCP

Dans cet exemple, le modèle propose un appel ; l’application décide de l’exécuter selon ses règles. Le client transporte cet appel, et le serveur le réalise auprès du logiciel du commerce.

Une question de stock, de bout en bout

À la connexion, le client récupère le catalogue des outils avec tools/list. Pour la question de la vendeuse, l’application présente au modèle la description de consulter_stock et ses paramètres. Elle transmet ensuite l’appel proposé avec tools/call. Spécification des outils

Le choix local ou distant concerne l’endroit où tourne le serveur et la façon de lui transmettre les messages. En local, l’application peut lancer un processus et utiliser ses entrées et sorties standard (stdio). À distance, elle peut joindre un serveur via HTTP. Les rôles expliqués ci-dessus restent les mêmes. Transports MCP

Les avantages pour ce commerce

• Réutilisation. Le même serveur peut servir plusieurs applications compatibles, avec leur configuration et leurs autorisations propres.

• Préservation de l’existant. L’équipe peut exposer une fonction de l’API sans réécrire son logiciel de stock.

• Choix des capacités proposées à l’agent. Pour aider la vendeuse, on peut commencer par la recherche de produits et la lecture du stock. La modification du catalogue peut faire l’objet d’une intégration distincte, avec ses propres contrôles. Ce choix relève de la conception du serveur.

Les limites à prévoir lors de l’implémentation

• Les droits restent à gérer. Une vendeuse autorisée à consulter Lyon ne doit pas accéder à tous les magasins. MCP prévoit un cadre d’autorisation pour HTTP, mais le serveur et le service métier doivent appliquer les permissions effectives. Autorisation MCP

• Le contrat doit être précis. « Stock disponible » peut désigner le stock physique ou le stock restant après réservations. Le développeur doit expliquer ce que renvoie l’outil et comment il signale une donnée indisponible.

• L’intégration doit être exploitée et maintenue. Il faut traiter les délais d’attente, les pannes de l’API, les journaux d’appels et la compatibilité entre versions du client et du serveur.

• Le contexte du modèle reste limité. Proposer des centaines d’outils exige de sélectionner ceux qui sont utiles. Le protocole ne garantit ni cette sélection ni l’exactitude de la réponse finale.

Une première mise en œuvre pourrait donc se limiter à la consultation du stock, puis être testée sur des produits ambigus, des accès refusés et des pannes du service avant d’ouvrir des actions de modification.

Pour poursuivre : comparer MCP, API et CLI et bien écrire ses tools.