Le modèle était bon. La spécification de l'outil était le bug.

Une évaluation sur un agent configuré pour la production a révélé un taux d’omission d’outil supérieur à 20 %. L’agent disposait du bon outil, en avait besoin, et ne l’a pas appelé silencieusement. L’instinct général était de mettre à niveau le modèle.

Nous avons réécrit les descriptions d’outils à la place. Le taux d’omission s’est effondré.

Cette découverte s’est transformée en habitude, puis en outillage. Une spécification d’outil est un contrat entre un système déterministe et un appelant probabiliste, et la plupart des spécifications sont écrites pour le mauvais lecteur : elles décrivent l’implémentation pour un développeur au lieu de la décision pour un modèle. « Interroge le service interne de tarification v2 » ne dit rien à un agent. « Utilisez ceci lorsque l’utilisateur demande le coût de quelque chose ; ne l’utilisez pas pour les prix historiques » modifie un comportement que vous pouvez mesurer.

Parce que l’échec est textuel, il est lintable. Cela est devenu Tool Credit Score, un linter déterministe qui note les spécifications d’outils MCP de 0 à 100 pour leur aptitude agent et corrige automatiquement les échecs courants. Déterministe volontairement : la révision des spécifications a sa place dans la CI, et la CI ne devrait pas avoir besoin d’un LLM pour vous dire qu’une description fait trois mots.

La méthode complète, incluant la taxonomie des échecs (omission, mauvais outil, arguments mal formés, arguments hallucinés, réponse prématurée) et les exemples avant/après, se trouve dans le guide de terrain des contrats d’outils.