Publié le 19 octobre 2026 · Publication originale
Un agent dispose de centaines d'outils MCP.
Pour choisir lequel appeler, il ne relit pas nécessairement tout le catalogue à chaque requête. Les noms, descriptions, paramètres et capacités peuvent être encodés dans un index sémantique.
Puis le catalogue évolue.
Un outil est renommé.
Un paramètre change.
Une capacité disparaît.
Une description prend un autre sens.
L'API peut toujours répondre.
Mais l'agent raisonne avec une représentation devenue obsolète.
En août 2026, Sai Kiran Paidi et Venkata Rama Krishna Bonagiri formalisent ce problème à IEEE SmartIoT sous le nom de "tool drift".
Ils distinguent trois dérives: schéma, sémantique et capacité.
Puis ils construisent ToolDriftBench: 150 tâches, trois domaines d'entreprise et six niveaux de dérive allant jusqu'à 60%.
À ce niveau maximal, le taux de réussite tombe à 39,2%.
Le modèle n'a pourtant pas nécessairement changé.
Le prompt non plus.
C'est la carte des outils qui ne correspond plus au territoire.
ULTRA®
Leur réponse, ToolDriftGuard, évite de reconstruire tout l'index après chaque modification.
Le système surveille les manifests MCP, identifie les entrées modifiées, caractérise leur dérive puis ne ré-encode que les vecteurs concernés dans l'index FAISS.
À 60% de dérive, le taux de réussite remonte de 39,2% à 83,6%, à 6,4 points d'une reconstruction complète.
La latence de réindexation diminue de 93 à 99%.
Mais une limite compte pour les systèmes critiques.
Si une API conserve exactement le même schéma et la même description tout en changeant silencieusement son comportement réel, surveiller le manifest ne suffit pas.
Il faut ajouter une seconde couche: des tests comportementaux sur des appels sentinelles et leurs résultats attendus.
Une description d'outil devient ainsi un contrat versionné.
Son comportement doit aussi devenir testable.
LI!GHT WORKFORCE ©
Plus une organisation délègue d'actions à des agents, plus la maintenance du catalogue d'outils devient une fonction d'infrastructure.
Le travail humain se déplace vers le versionnage, les tests de non-régression, les permissions et le traitement des exceptions.
Un agent peut appeler parfaitement la bonne fonction avec les bons paramètres et prendre malgré tout une mauvaise décision.
La compatibilité syntaxique n'est plus une preuve de compatibilité opérationnelle.
ARGOS
Un agent n'est fiable que tant que la carte qu'il utilise décrit encore le territoire où il agit.
Sources
Paidi & Bonagiri, "ToolDriftBench: Detecting and Recovering from MCP Tool Index Staleness in Agentic Systems", IEEE SmartIoT 2026
#AIAgents #MCP #AIInfrastructure #LLMOps #AIGovernance #LightWorkforce #VOCEAssociation