MCP : approches pratiques et compromis pour la conception d'outils
Meta a publié une analyse détaillée sur la conception des outils utilisant le protocole MCP (Model Context Protocol), destiné à connecter des modèles de langage à des systèmes agentiques externes. Le constat de départ est simple: de nombreuses équipes se contentent d'exposer une API existante telle quelle via MCP, en laissant le modèle se débrouiller pour l'utiliser correctement. Cette approche fonctionne pour des cas simples, mais échoue souvent dans la pratique, provoquant des appels d'outils ratés, des paramètres erronés et des tentatives répétées qui consomment du contexte et dégradent les performances. Pour illustrer ces problèmes et leurs solutions, l'équipe a construit plusieurs exemples simulant une API de recherche de contenu éducatif K-12, testables localement via l'outil en ligne de commande Kiro CLI. Deux causes principales expliquent ces échecs. La première est la surcharge de contexte: chaque définition d'outil se charge dans la fenêtre de contexte du modèle à chaque appel, qu'elle soit utilisée ou non, et la connexion de plusieurs serveurs MCP peut saturer cette fenêtre avant même que l'utilisateur ait posé sa première question. La seconde est la confusion: à mesure que le contexte se remplit, le raisonnement du modèle se dégrade, ce qui le conduit à choisir le mauvais outil ou des paramètres incorrects, les tentatives de correction aggravant encore la surcharge. Des noms d'outils ambigus, une similarité sémantique entre plusieurs fonctions et un trop grand nombre d'options amplifient ce phénomène. Enrichir les descriptions d'outils avec des exemples d'usage plus clairs aide à réduire la confusion, mais accroît mécaniquement la surcharge, créant un équilibre délicat à gérer. Ces observations rejoignent des travaux publiés par Anthropic sur l'ingénierie du contexte, qui consiste à façonner précisément ce que le modèle voit et à quel moment, afin d'optimiser la qualité de ses réponses. Parmi les leviers concrets identifiés: limiter par défaut le nombre de champs renvoyés par un outil, quitte à proposer une option distincte pour obtenir une vue détaillée à la demande, ce qui permettrait selon les recherches d'Anthropic de réduire d'environ deux tiers le volume de tokens de réponse. Autre levier: soigner les messages d'erreur, qui doivent orienter précisément la tentative suivante du modèle plutôt que de se limiter à un simple "aucun résultat" qui ne donne aucune piste d'amélioration. Des contraintes de schéma, comme des valeurs par défaut et des énumérations, permettent également d'éliminer certaines approximations dès la conception, sans attendre que le modèle échoue pour corriger le tir. Pour les équipes qui déploient des agents IA en production, ces recommandations offrent une méthode concrète pour éviter que la multiplication des outils connectés ne finisse par nuire à la fiabilité même du système.
