Contrats d'outil : Pourquoi les Agents omettent vos outils

L’exécution d’évaluation qui a lancé ce document semblait saine au premier abord. J’effectuais des évaluations sur un jeu de référence (gold-set) pour un agent de niveau production, dans le cadre d’une preuve de valeur en entreprise : un ensemble de tâches sélectionnées, chacune avec une séquence attendue d’appels d’outils, rejouées contre l’agent et notées automatiquement. Les traces de raisonnement étaient vraiment bonnes. Le modèle décomposait correctement les problèmes, planifiait de manière sensée et rédigeait des réponses finales claires. Et il omettait d’appeler des outils qu’il était censé utiliser dans plus de 20 % des cas. Il ne s’agissait pas d’échecs d’appels. Ni d’appels avec de mauvais arguments. Il répondait simplement de sa propre initiative, comme si l’outil n’existait pas.

Mon premier réflexe fut le même que d’habitude : changer le modèle, puis réécrire le prompt système. Aucune de ces actions n’a beaucoup fait bouger les chiffres. Un modèle plus coûteux a réduit de quelques points le taux d’omission, mais pour un coût 13 fois supérieur. Une “chirurgie” du prompt (“vous DEVEZ utiliser les outils disponibles”) a produit l’échec inverse, l’agent a commencé à appeler des outils dont il n’avait pas besoin. Ce qui a finalement résolu le problème était ennuyeux : j’ai réécrit les descriptions d’outils. J’ai précisé quand chaque outil devait être utilisé, quand il ne devait pas l’être, et ce qu’il retournait. J’ai déplacé les contraintes du texte libre vers le schéma. Le taux d’omission est tombé à un chiffre bas. Même modèle, même prompt système, même jeu d’évaluation.

Ce résultat s’est répété pour chaque agent que j’ai évalué par la suite, et cela a changé ma façon de penser aux échecs d’appels d’outils. La cause dominante n’est pas une faiblesse du modèle. Ce sont des contrats d’outils (tool contracts) sous-spécifiés : des descriptions vagues, des outils qui se chevauchent, des schémas qui acceptent n’importe quoi, des contraintes qui n’existent que dans la tête d’un développeur. Les équipes rédigent des spécifications d’outils pour des développeurs qui peuvent lire le code source. Le lecteur réel est un modèle probabiliste qui voit exactement le JSON que vous avez enregistré et rien d’autre. Ce guide présente ce que je fais maintenant à ce sujet, y compris le linter déterministe que j’ai construit pour le rendre applicable en CI.

Une taxonomie des échecs d’appels d’outils

Lorsque j’évalue les transcriptions d’évaluation, chaque échec lié à un outil tombe dans l’une des cinq catégories. La discipline utile consiste à remonter chaque catégorie jusqu’au défaut de spécification qui l’a causée, car cela vous indique ce qu’il faut corriger. Blâmer “le modèle” ne vous donne aucune information exploitable.

Mode d’échec	Ce à quoi cela ressemble dans la transcription	Cause première dans la spécification	Comment le détecter dans les évaluations
Omission	Pas d’appel d’outil là où un était requis ; l’agent répond à partir de connaissances paramétriques ou devine	La description ne dit pas quand l’outil s’applique, ou n’établit pas que ses données sont à jour et faisant autorité	La trace de référence (golden trace) attend l’outil X ; la transcription ne contient aucun appel à X. Signaler les omissions par outil, pas seulement globalement
Mauvais outil	L’agent appelle un voisin plausible : search_documents au lieu de search_customer_accounts	Outils qui se chevauchent avec des descriptions quasi identiques et sans clause de désambiguïsation	Outil A attendu, outil B observé. Regrouper les confusions dans une matrice ; les paires qui se chevauchent apparaissent immédiatement
Arguments malformés	L’appel échoue à la validation du schéma ou l’API retourne 400 ; l’agent réessaie aveuglément ou abandonne	Le schéma est trop lâche : paramètres non typés, pas de tableau required, champs de chaîne libre là où des formats existent	Compter les échecs de validation de schéma et les réponses 4xx par outil dans les traces
Arguments hallucinés	Les arguments sont syntaxiquement valides mais inventés : un ID de compte qui n’apparaît nulle part dans la conversation	La spécification manque de contraintes et d’exemples, donc le modèle comble les lacunes avec des valeurs plausibles	Comparer les valeurs des arguments avec les valeurs réellement présentes dans la conversation ou les résultats d’outils précédents
Réponse prématurée	L’agent produit une réponse finale confiante sans appeler les outils qui la fondent	La description ne dit pas au modèle que ses connaissances sont obsolètes ici (“les données de compte changent quotidiennement ; appelez ceci même si vous pensez savoir”)	Réponse finale présente, appels requis absents ; vérifier si les affirmations de la réponse sont traçables à la sortie de l’outil

Deux points concernant ce tableau ont gagné leur place par la répétition. Premièrement, l’omission est l’échec le plus courant et le moins visible. Un appel malformé génère une erreur sur laquelle vous pouvez être alerté. Une omission produit une réponse fluide, confiante, mais erronée, et rien dans vos logs ne la signale. Vous ne voyez les omissions que si vos évaluations encodent les appels d’outils attendus. Deuxièmement, quatre des cinq catégories sont des défauts de spécification. Seule la sélection du mauvais outil dans un ensemble d’outils véritablement bien séparé est plausiblement une limitation du modèle, et même là, la spécification est généralement complice.

Votre description d’outil est un prompt. Elle est injectée dans la fenêtre de contexte à chaque tour. La plupart des équipes passent des semaines à itérer le prompt système et zéro minute sur les quinze prompts qu’elles ont livrés avec.

Ce qu’est réellement un contrat d’outil

J’utilise le mot contrat délibérément. Un outil se situe à la frontière entre deux systèmes très différents : une implémentation déterministe qui fait exactement ce que son code indique, et un appelant probabiliste qui décide si et comment l’invoquer en se basant uniquement sur le texte et le schéma que vous avez enregistrés. Le modèle ne peut pas lire votre code source. Il ne peut pas demander à un collègue. La spécification est l’interface entière, et elle comporte six parties :

1. Nom. Le signal le plus fort pour la sélection d’outils. Les modèles reconnaissent les noms avant de lire un mot de la description.
2. Description. Quand utiliser l’outil, quand ne pas l’utiliser, et ce qu’il retourne. C’est une documentation dont le lecteur est un modèle, ce qui change les règles d’écriture.
3. Schéma. La forme vérifiable par machine de l’entrée : types, champs requis, énumérations, formats, plages.
4. Contraintes. Tout ce que le schéma ne peut pas exprimer structurellement, énoncé explicitement : dépendances d’ordre (“appeler search_customer_accounts d’abord pour obtenir le account_id”), attentes de débit, fraîcheur des données.
5. Exemples. Au moins une invocation concrète et valide. Les modèles généralisent à partir d’exemples de manière beaucoup plus fiable qu’à partir de descriptions abstraites.
6. Sémantique des erreurs. À quoi ressemble un échec et ce que l’appelant doit faire à ce sujet. Un agent qui sait que STATEMENT_NOT_READY signifie “arrêter et informer l’utilisateur” se comporte différemment d’un agent qui regarde une trace de pile.

L’habitude la plus efficace est d’écrire des descriptions orientées comportement plutôt que des descriptions d’implémentation. Une description d’implémentation dit ce que le code fait : “Interroge la base de données clients via le service de comptes.” Une description de comportement dit ce que l’appelant doit faire : “Recherche les comptes clients par nom, e-mail ou numéro de compte. Utilisez ceci lorsque l’utilisateur pose une question sur un client spécifique et que vous n’avez pas déjà son ID de compte.” La première est précise et inutile pour le modèle. La seconde se lit comme une règle de routage, car c’est exactement ainsi que le modèle la consomme. Chaque description que je livre contient maintenant la phrase littérale “Utilisez ceci lorsque” et, pour tout outil ayant un voisin plausible, “N’utilisez pas ceci pour”.

Les règles qui comptent vraiment

Voici les règles que j’applique lors de l’examen des spécifications d’outils, classées approximativement par l’impact de chacune sur les taux d’omission et d’erreur dans mes évaluations. Rien de tout cela n’est exotique. Tout cela est régulièrement absent des serveurs MCP en production.

Une seule tâche par outil, et pas de voisins qui se chevauchent

Si deux outils pouvaient plausiblement gérer la même requête, le modèle répartira ses appels entre eux, et vos évaluations montreront un schéma de confusion diffus plutôt qu’un échec clair. Les pires coupables que je vois sont des paires comme get_customer / fetch_customer_details / lookup_client qui ont évolué organiquement à partir de différentes équipes. Fusionnez-les, ou donnez à chacun une limite nettement distincte et faites référence à l’autre par son nom dans la description (“Pour l’historique des transactions, utilisez list_account_transactions à la place”). Un modèle qui décide entre des outils effectue une tâche de classification ; votre travail est de rendre les classes séparables.

Dites quand NE PAS l’utiliser

Les descriptions positives définissent une région floue. Les clauses négatives définissent ses bords. La description qui a réduit les taux d’omission dans mon exemple d’introduction ne disait pas seulement ce que l’outil faisait ; elle disait “Utilisez ceci même si vous pensez déjà connaître la réponse ; les données de portefeuille changent quotidiennement”. Cette seule phrase s’attaque directement aux échecs d’omission et de réponse prématurée, car l’hypothèse par défaut du modèle est que ses connaissances paramétriques sont adéquates. Inversement, les clauses “N’utilisez pas ceci pour X” s’attaquent à la sélection du mauvais outil. Les deux directions sont importantes.

Mettez les contraintes dans le schéma, pas dans le texte libre

Les contraintes en texte libre sont des suggestions. Les contraintes de schéma sont vérifiables, et les modèles les respectent plus fidèlement car elles sont structurelles. Chaque fois que vous écrivez “doit être une date valide” dans une description, vous auriez pu écrire un pattern ou format dans le schéma. Voici un avant et après d’une vraie révision, généralisé :

{
  "name": "get_statement",
  "description": "Gets a statement. Date should be in the right format and not in the future.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "date": { "type": "string" },
      "acct": { "type": "string" }
    }
  }
}

Tout ce qui est faux ici est invisible jusqu’à une exécution d’évaluation : pas de tableau required (donc le modèle peut omettre les deux champs), pas de format pour date (j’ai observé “last month”, “2026/05/01” et des millisecondes d’époque dans les traces), et acct ne donne au modèle aucune base, ce qui est l’origine des ID de compte hallucinés. La réécriture :

{
  "name": "get_monthly_statement",
  "description": "Retrieves one closed monthly account statement as a PDF link. Use this after you have an account_id from search_customer_accounts. Do not use this for real-time balances; use get_account_balance. Returns error code STATEMENT_NOT_READY if the requested month is not yet closed; do not retry, tell the user when it will be available.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "account_id": {
        "type": "string",
        "pattern": "^ACC-[0-9]{8}$",
        "description": "Account identifier, e.g. ACC-00417233. Obtain via search_customer_accounts; never guess this value."
      },
      "month": {
        "type": "string",
        "pattern": "^[0-9]{4}-(0[1-9]|1[0-2])$",
        "description": "Statement month as YYYY-MM, e.g. 2026-05. Must be a fully closed month, not the current month."
      }
    },
    "required": ["account_id", "month"],
    "additionalProperties": false
  },
  "annotations": { "readOnlyHint": true }
}

Les énumérations méritent une mention spéciale. Tout paramètre avec un ensemble fini de valeurs légales devrait être une énumération, point final. Une chaîne libre avec “une des valeurs suivantes : active, dormant, closed” dans la description finira par recevoir “inactive”, et votre backend fera ce qu’il veut avec cela.

Soyez honnête sur ce qui est requis ou optionnel

Deux directions d’échec. Marquer un champ réellement requis comme optionnel invite à des appels qui l’omettent, et le modèle apprend alors du message d’erreur, gaspillant un tour. Marquer un champ optionnel comme requis force le modèle à inventer une valeur, ce qui est une hallucination que vous avez créée par décret. Je vois constamment le second cas dans les spécifications générées à partir de DTOs backend où chaque champ était requis pour la base de données, et non pour l’appelant. La règle : required reflète ce dont l’outil a besoin pour effectuer un travail utile, et la description de chaque champ optionnel indique ce qui se passe lorsqu’il est omis (“Omettre pour rechercher tous les statuts”).

Échouez avec des codes, pas du texte libre

Les messages d’erreur font partie du contrat car l’agent les lit et décide quoi faire ensuite. Une trace de pile brute ou une erreur générique “internal error” donne au modèle deux options : réessayer aveuglément ou s’excuser. Un code d’erreur déterministe avec une indication exploitable par machine lui donne une branche à prendre. Le modèle que j’utilise : un champ code stable, un message lisible par l’humain en une phrase, et le cas échéant une directive (retry_after_seconds, “obtenir un account_id valide d’abord”). Dans les évaluations, cela convertit une classe de transcriptions sans issue en récupérations, et cela rend les assertions d’échec dans votre suite de tests triviales à écrire.

Nommez pour l’appelant, pas pour la base de code

Verbe-objet, snake_case, pas de jargon interne. search_customer_accounts est préférable à queryCustDB, cst_lkp_v2 et CustomerAccountSearchServiceEndpoint. Les noms de systèmes internes sont particulièrement coûteux : le modèle n’a aucune idée que “Falcon” est votre moteur de tarification, donc query_falcon pourrait tout aussi bien être sans étiquette. Le nom devrait permettre à un modèle sans aucun contexte organisationnel de prédire ce que l’outil fait. Cela semble cosmétique. Ce n’est pas le cas ; les noms sont le filtre de première passe dans la sélection d’outils, et dans les matrices de confusion, je peux observer des outils mal nommés perdre des appels au profit de voisins mieux nommés qui font la mauvaise chose.

Respectez le budget de longueur

La longueur de la description a un point idéal. En dessous d’une dizaine de mots, l’outil est sous-spécifié et est omis ou mal utilisé. Au-delà de quelques centaines de mots, le signal se noie : la clause “quand utiliser” est enfouie au quatrième paragraphe et le modèle a quinze autres descriptions d’outils qui se disputent l’attention dans la même fenêtre de contexte. Dans mes révisions, les descriptions les plus performantes font trois à six phrases : ce qu’il fait, quand l’utiliser, quand ne pas l’utiliser, ce qu’il retourne, le comportement en cas d’erreur. Si vous avez besoin de plus, l’outil fait probablement trop de choses (voir la règle un) ou le matériel supplémentaire appartient au schéma.

Évaluer les spécifications de manière déterministe

Après suffisamment de ces révisions, j’ai remarqué que j’appliquais la même liste de contrôle à chaque fois, et une liste de contrôle que vous appliquez à la main est un linter que vous n’avez pas encore écrit. J’en ai donc construit un : Tool Credit Score, qui fait partie d’Agent Contract Studio, open source et disponible en ligne sur agentic-contract-studio.vercel.app. Vous collez une spécification d’outil MCP (ou l’importez de GitHub, ou la découvrez à partir d’un serveur MCP en cours d’exécution), et il note chaque outil de 0 à 100 selon une grille déterministe, puis corrige automatiquement ce qu’il peut.

La grille comporte cinq catégories pondérées, qui correspondent directement à la taxonomie des échecs ci-dessus :

Catégorie	Poids	Ce qu’il vérifie	Mode d’échec ciblé
Description	25%	Présente, 10+ mots, commence par un verbe d’action, moins de 200 mots	Omission, réponse prématurée
Paramètres	25%	Le schéma est type: object ; chaque paramètre a un type et une description ; un tableau required existe et est honnête	Arguments malformés et hallucinés
Bonnes pratiques	20%	Annotations MCP (readOnlyHint, destructiveHint, idempotentHint) ; additionalProperties: false ; la description mentionne les retours et les erreurs	Mauvais outil, gestion des erreurs sans issue
Nommage	15%	snake_case, préfixe verbal, moins de 64 caractères	Mauvais outil
Exemples	15%	Au moins une invocation d’exemple valide	Arguments malformés et hallucinés

Les scores sont convertis en une note (90+ est un A, moins de 60 est un F), et l’auto-correcteur gère les réparations mécaniques de manière déterministe : renommage en snake_case avec un préfixe verbal, ajout des types de paramètres manquants, échafaudage d’exemples et d’annotations. Il existe une passe optionnelle de polissage LLM pour la formulation des descriptions, mais elle est exactement cela, optionnelle, locale uniquement, et elle ne touche jamais aux noms de paramètres, aux types ou à la structure du schéma. Le pipeline principal n’a besoin d’aucun modèle ni de clé API.

Cette dernière décision de conception est le point essentiel, et elle mérite d’être défendue car “demander simplement à un LLM de réviser la spécification” est l’alternative évidente. J’ai choisi le linting déterministe pour la CI pour quatre raisons. Il est reproductible : la même spécification obtient le même score à chaque exécution, donc une régression de score dans une pull request signifie que la spécification a changé, pas l’humeur du juge. Il est rapide et gratuit, vous pouvez donc l’exécuter sur chaque commit sans discussion sur le budget de tokens. Il est explicable : chaque point déduit correspond à une règle nommée avec une correction concrète, ce qui est ce que vous voulez dans un commentaire de revue de code. Et il ne peut pas être contesté, ce qui est plus important qu’il n’y paraît ; j’ai vu des équipes rediscuter le verdict d’un juge LLM pendant une heure, et personne ne discute avec une regex.

La mise en garde honnête : un linter vérifie la forme, pas le sens. Tool Credit Score détectera un tableau required manquant à chaque fois ; il ne peut pas vous dire que deux de vos outils se chevauchent sémantiquement, ou que votre clause “quand utiliser” est factuellement erronée concernant votre propre système. Ces défauts n’apparaissent que dans les évaluations (taux d’omission et de confusion mesurés) ou lors d’une révision humaine. Le travail du linter est de s’assurer que les défauts mécaniques et peu coûteux n’atteignent jamais ce stade, de sorte que l’effort de révision coûteux soit dirigé là où il est réellement nécessaire.

Un Tool Credit Score de 90+ ne garantit pas que les agents utiliseront bien vos outils. Un score inférieur à 60 garantit presque qu’ils ne le feront pas. Le linting est un plancher, pas un plafond.

Où les serveurs MCP concentrent ces échecs

MCP a rendu les outils portables, ce qui est vraiment utile, et il a également rendu les mauvaises spécifications portables. Trois schémas expliquent la plupart des serveurs mal notés que j’ai examinés.

Serveurs générés à partir d’OpenAPI. Pointez un convertisseur vers un document OpenAPI et vous obtenez un serveur MCP en quelques minutes : un outil par endpoint, des noms de paramètres tirés directement du backend, des descriptions écrites pour des développeurs lisant la documentation de référence de l’API, si elles ont été écrites du tout. Le résultat est une surface de spécification qui ressemble à votre base de données, pas aux tâches de vos utilisateurs. Un agent confronté à post_v2_accounts_search, get_accounts_by_id et get_accounts_search_legacy produira exactement la matrice de confusion que vous prédiriez. Les serveurs générés sont un bon point de départ ; ils ne constituent pas un contrat livrable. Prévoyez une passe de curation qui fusionne les outils en forme d’endpoint en outils en forme de tâche.

Serveurs “fourre-tout”. Un serveur qui encapsule un produit SaaS entier et expose 80 outils parce que l’API a 80 capacités. Chacune de ces définitions d’outils est injectée dans le contexte du modèle à chaque tour, vous payez donc pour toute la surface en tokens, que cette conversation en ait besoin ou non, et la précision de la sélection d’outils se dégrade à mesure que l’ensemble des candidats augmente, surtout lorsque les candidats partagent un vocabulaire. Mon budget de travail : maintenir les outils réellement exposés à un agent pour une tâche donnée en dessous d’environ 20. Ce nombre est une observation de mes évaluations, pas une loi, et de meilleurs modèles continuent de le pousser vers le haut. La direction de l’effet s’est maintenue pour chaque modèle que j’ai testé.

Pas de divulgation progressive. La solution pour le “fourre-tout” n’est pas de supprimer des capacités, mais d’échelonner leur exposition. Exposez un petit ensemble de base pour le chemin commun. Pour les capacités de longue traîne, utilisez un modèle de découverte : un outil de type search_tools qui retourne des contrats complets à la demande, un chargement de schéma différé là où votre client le supporte, ou des sous-agents dédiés qui ne voient chacun que leur tranche de l’ensemble d’outils. La conception de MCP le supporte : les clients choisissent les outils à exposer, et le filtrage côté serveur des outils par contexte de tâche est simple à implémenter. La discipline du contrat s’applique toujours à chaque couche ; un outil découvert avec une description vague échoue de manière identique à un outil préchargé, juste un tour plus tard.

Le bloc annotations de MCP (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) mérite d’être plus utilisé qu’il ne l’est. Au-delà de la valeur de sécurité, les annotations permettent à un client d’appliquer une politique générale (approuver automatiquement les outils en lecture seule, bloquer les outils destructeurs derrière une confirmation) sans analyser les descriptions, et elles constituent l’une des améliorations de score les moins chères dans le linter.

Boucler la boucle avec les évaluations

Aucune des règles ci-dessus n’a beaucoup de valeur en tant qu’opinions. Elles ont beaucoup de valeur en tant que deltas mesurés, et la discipline de mesure est la même que celle que j’ai décrite dans Évaluer les systèmes agentiques : un jeu de tâches de référence (gold set) avec des séquences d’appels d’outils attendues, rejouées contre l’agent, et notées automatiquement. La boucle spécifique pour les contrats d’outils :

1. Baseline. Exécutez le jeu de référence (gold set) avec les spécifications actuelles. Enregistrez le taux d’omission par outil, les confusions de mauvais outil et les échecs de validation d’arguments. Le “par outil” est important : un taux d’omission agrégé de 8 % peut cacher un outil qui est omis la moitié du temps.
2. Corrigez les spécifications. Linting d’abord (défauts mécaniques), puis appliquez les règles sémantiques : limites, clauses “quand ne pas utiliser”, contraintes de schéma.
3. Réexécutez le même jeu de référence (gold set). Le modèle, le prompt et les tâches n’ont pas changé, donc le delta est attribuable à la spécification. C’est le A/B le plus propre que vous obtiendrez jamais en ingénierie d’agents, et c’est ainsi que je sais que les réécritures de descriptions ont réduit un taux d’omission de plus de 20 % à un chiffre bas dans l’engagement qui a lancé ce guide.
4. Intégrez-le en CI. Les spécifications d’outils sont du code. Versionnez-les, comparez-les (diff), et traitez un changement de description comme un changement de comportement, car c’en est un ; cela modifie un prompt qui s’exécute à chaque tour. Mon pipeline échoue une pull request si le Tool Credit Score d’un outil tombe en dessous du seuil, et signale toute différence de spécification pour une nouvelle exécution d’évaluation avant la fusion.

Le même engagement en gestion de patrimoine a produit l’autre chiffre que je cite constamment : une fois les contrats d’outils corrigés, un modèle de milieu de gamme a égalé la précision du modèle premium sur notre jeu de référence (gold set) pour environ 1/13e du coût, avec des taux d’omission d’outils mesurés plutôt qu’assumés. Les mauvaises spécifications ne causent pas seulement des échecs. Elles gonflent silencieusement votre facture de modèle, car la capacité supplémentaire du modèle coûteux était dépensée à compenser des contrats que le modèle bon marché aurait pu exécuter s’ils avaient été correctement écrits.

Ce que je ferais encore différemment : mes jeux de référence (gold sets) sont des conversations rejouées, pas des utilisateurs en direct, et les vrais utilisateurs formulent des requêtes de manière à solliciter la sélection d’outils plus fortement que ne le font les tâches sélectionnées. Les taux d’omission en production sont supérieurs aux taux d’omission d’évaluation pour chaque agent que j’ai déployé. Considérez le chiffre d’évaluation comme une limite inférieure et continuez à échantillonner les traces de production par rapport à la même taxonomie.

La version en un paragraphe

La plupart des échecs d’appels d’outils chez les agents en production sont des défauts de spécification, et non des défauts de modèle : les omissions, les sélections de mauvais outils, les arguments malformés, les arguments hallucinés et les réponses prématurées remontent tous à des contrats écrits pour des développeurs au lieu du modèle qui les lit réellement. Corrigez le contrat : une seule tâche par outil sans voisins qui se chevauchent, des descriptions orientées comportement avec des clauses explicites “quand utiliser” et “quand ne pas utiliser”, des contraintes exprimées sous forme d’énumérations, de formats et de plages dans le schéma plutôt que dans le texte libre, un tableau required honnête, au moins un exemple, des codes d’erreur déterministes sur lesquels un agent peut se baser, et des noms verbe-objet exempts de jargon interne. Linting tout cela de manière déterministe en CI (mon Tool Credit Score open source le fait, de 0 à 100 avec auto-correction) car les scores reproductibles sont préférables aux révisions jugées par LLM pour la validation, puis prouvez les corrections sémantiques avec des évaluations en mesurant les taux d’omission par outil avant et après. Dans mes travaux d’évaluation en entreprise, cette boucle a réduit un taux d’omission d’outils de plus de 20 % à un chiffre bas sans toucher au modèle ni au prompt système, et c’est la raison pour laquelle un modèle de milieu de gamme a égalé un modèle premium pour environ 1/13e du coût.

Références

• Spécification du Model Context Protocol, incluant les définitions d’outils et les annotations
• Anthropic : documentation sur l’utilisation des outils, la référence pratique sur la façon dont les modèles consomment les spécifications d’outils
• Ingénierie Anthropic : écrire des outils efficaces pour les agents
• Agent Contract Studio (Tool Credit Score), le linter déterministe de spécifications MCP décrit ci-dessus, disponible en ligne sur agentic-contract-studio.vercel.app
• Évaluer les systèmes agentiques, mon guide pratique sur le harnais d’évaluation d’où proviennent les mesures de ce document