- Claude Developer Platform ajoute trois nouvelles fonctionnalités, offrant une architecture avancée d’utilisation d’outils permettant au modèle d’explorer, d’appeler et d’apprendre efficacement des milliers d’outils externes
- Tool Search Tool ne charge les définitions d’outils qu’au moment nécessaire, ce qui permet de réduire l’usage de tokens jusqu’à 85 % et d’améliorer la précision de 74 à 88 % dans les grands environnements MCP
- Programmatic Tool Calling permet d’appeler des outils en parallèle dans un environnement d’exécution de code, avec à la clé une réduction des tokens (37 %), une baisse de la latence et une amélioration de la précision
- Tool Use Examples permet d’apprendre des schémas d’utilisation d’outils et des relations entre paramètres qui ne peuvent pas être exprimés en JSON Schema, grâce à des exemples d’appels réels
- Ces trois fonctionnalités fournissent une base d’orchestration efficace pour les agents IA à grande échelle et constituent des composants clés de l’automatisation de workflows complexes
Étendre l’utilisation d’outils par les agents IA
- Les agents IA du futur devront exploiter de façon intégrée des centaines à des milliers d’outils
- Exemples donnés : assistants IDE, coordinateurs d’exploitation, et intégrations avec Slack, GitHub, Jira, Google Drive, etc.
- Les approches existantes exigent de précharger toutes les définitions d’outils, ce qui consomme rapidement la fenêtre de contexte (context window)
- La nouvelle approche consiste à explorer et charger les outils au moment voulu, tout en gagnant en efficacité grâce aux appels basés sur le code et à l’apprentissage par exemples
Tool Search Tool
- Dans les environnements MCP existants, connecter de nombreux serveurs peut faire occuper plus de 100 000 tokens par les seules définitions d’outils
- Exemple : GitHub (26K), Slack (21K), Jira (17K), etc., pouvant dépasser au total 134K tokens
- Tool Search Tool recherche et charge les outils à la demande
- Environ 500 tokens seulement lors du chargement initial, puis chargement additionnel des seuls outils nécessaires
- L’usage total tombe à environ 8.7K tokens, soit 95 % d’économie de contexte
- D’après les tests internes, la précision d’évaluation MCP progresse à Opus 4 : 49 %→74 %, Opus 4.5 : 79.5 %→88.1 %
- Le paramètre
defer_loading: true permet un chargement différé des outils
- Les outils fréquemment utilisés restent toujours chargés, les autres ne sont appelés qu’au moment de la recherche
- Des outils de recherche fondés sur les regex et BM25 sont fournis par défaut, avec possibilité d’une recherche personnalisée basée sur des embeddings
- Conditions d’adoption recommandées : plus de 10 outils, plus de 10K tokens de définitions, ou environnement sujet à des erreurs fréquentes de sélection
Programmatic Tool Calling
- Les appels traditionnels en langage naturel sont inefficaces à cause de l’accumulation des résultats intermédiaires et de multiples passes de raisonnement
- Exemple : lors de l’analyse d’un log de 10MB, l’ensemble des données entre dans le contexte et gaspille des tokens
- Programmatic Tool Calling (PTC) appelle les outils en parallèle dans un environnement d’exécution de code
- Claude peut exécuter en Python des boucles, conditions et transformations de données
- Les résultats intermédiaires ne sont pas inclus dans le contexte du modèle, seul le résultat final est renvoyé
- Exemple : pour identifier les dépassements budgétaires trimestriels, seul un résultat de 1KB entre dans le contexte au lieu de 2 000 éléments
- Effets
- Usage de tokens : 43,588→27,297 (baisse de 37 %)
- Réduction de la latence (19 inférences supprimées sur 20 appels)
- Gain de précision : recherche interne 25.6→28.5 %, benchmark GIA 46.5→51.2 %
- Conditions d’adoption recommandées
- Résumés de gros volumes de données, appels dépendants sur plus de 3 étapes, tâches nécessitant une exécution parallèle
- Peu efficace pour un appel unique ou de petites réponses
Tool Use Examples
- JSON Schema ne définit que la structure et ne peut pas exprimer les schémas d’usage, règles de format ou relations entre paramètres
- Exemples : format de date, règles d’ID, moment où utiliser des objets imbriqués, etc.
- Tool Use Examples ajoute des exemples d’entrée réels (
input_examples) à la définition de l’outil
- Ces exemples permettent à Claude d’apprendre le format de date (YYYY-MM-DD), les règles d’ID (USR-XXXXX) ou les combinaisons de paramètres optionnels
- Les tests internes montrent une amélioration de la précision sur la gestion de paramètres complexes de 72 % à 90 %
- Conditions d’adoption recommandées
- Outils avec structures imbriquées ou nombreux paramètres optionnels
- API dont les règles métiers ne peuvent pas être exprimées dans le Schema
- Cas où il faut distinguer des outils similaires
Utilisation combinée des trois fonctionnalités et bonnes pratiques
- Les trois fonctionnalités sont complémentaires
- Tool Search Tool → recherche des outils nécessaires
- Programmatic Tool Calling → exécution efficace
- Tool Use Examples → appel précis
- Priorité d’adoption
- Dépassement de contexte → Tool Search Tool
- Trop de résultats intermédiaires → Programmatic Tool Calling
- Erreurs de paramètres → Tool Use Examples
- Conseils de configuration
- Rédiger clairement les noms et descriptions d’outils pour améliorer la précision de recherche
- Toujours charger les 3 à 5 outils les plus utilisés, et charger les autres de manière différée
- Préciser le format de retour des outils destinés à l’exécution de code
- Rédiger des exemples de données réalistes et concis (1 à 5 exemples)
Premiers pas
- Les trois fonctionnalités sont proposées en version bêta
- Utilisables après ajout du header
betas=["advanced-tool-use-2025-11-20"]
- Outils inclus :
tool_search_tool_regex_20251119, code_execution_20250825, etc.
- La documentation officielle et le cookbook GitHub fournissent des exemples d’API et des guides d’implémentation
- Ces fonctionnalités sont présentées comme une technologie de base faisant évoluer le simple function calling vers une orchestration intelligente
- Elles sont mises en avant comme des composants clés pour réaliser exploration dynamique, exécution efficace et appels précis dans des workflows complexes et des environnements de données à grande échelle
5 commentaires
Mais pour l’instant, j’ai l’impression que c’est surtout la force du modèle. Si Claude s’en sort aussi bien, c’est parce que ce sont les modèles proposés par Claude, mais avec d’autres modèles, je me demande vraiment ce que ça donnerait...
Parmi des entreprises comme Anthropic, Google et OpenAI, j’ai l’impression qu’Anthropic est celle qui se rapproche le plus de l’IA agentique.
Commentaires Hacker News
Je cherche des moyens de réduire l’usage du contexte lors du streaming de plusieurs tool calls
J’externalise une partie du traitement vers l’outil lui-même pour lui faire renvoyer un résumé structuré d’un document Markdown de 200k tokens, mais même ainsi, cette approche peut remplir très vite le contexte du modèle principal
Je pense que le Programmatic Tool Calling est l’étape suivante naturelle
Comme les LLM évoluent vers une manipulation du code comme d’un langage, la définition de ce langage devient importante
En revanche, la recherche d’outils me semble être un surcoût inutile. Il est plus efficace de placer à l’avance dans le contexte les outils nécessaires
Au final, il faut un tool definition language concis, comme une définition de fonctions, et j’aimerais pouvoir mettre des objets dans le contexte pour qu’ils reconnaissent leurs types et les méthodes appelables
.d.tsLa maintenance et les tests seraient aussi plus simples, et si besoin on pourrait importer quelque chose du style
export * as Foo from '@foo/foo'Comme les LLM savent déjà bien écrire du code, si on leur donne des droits d’écriture, ils pourraient créer ou importer eux-mêmes leurs outils
À terme, une plateforme interactive de collaboration IA↔humain comme Jupyter/Pluto/Mathematica serait probablement plus adaptée
Avec une entrée vocale et une collaboration entre sessions, on arriverait presque à un système de niveau Skynet
L’agent que j’ai conçu fonctionne très bien avec seulement une partie du SDK Python et quelques fonctions personnalisées
Cette structure de pseudo-RPC me paraît relever d’un cérémonial inutile
Smolagents s’en sert pour traiter les sorties d’outils comme des objets (dict)
Je me demande si cette approche ressemble à la direction que j’évoque
Plus de détails dans ce billet de blog Hugging Face
Je me demande si les serveurs MCP incluront des exemples d’usage dans la définition des outils
Si oui, on pourrait aussi y mettre des exemples de code et éviter l’étape de génération de code, mais j’imagine que cela a été bloqué pour des raisons de sécurité
Exécuter du code fourni par un tiers est risqué, donc cette décision de conception se comprend
C’est dommage d’avoir utilisé Python comme wrapper
Avec Bash, la compatibilité entre langages aurait été meilleure, et cela aurait aussi convenu aux workflows qui n’utilisent pas Python
Il est tout aussi capable que Bash d’exécuter des outils externes
L’idée d’un “avenir où le modèle manipule sans friction des centaines, voire des milliers d’outils” me semble erronée
Je pense au contraire que la bonne direction, c’est moins d’outils + une meilleure capacité à les exploiter
À la limite, un seul ShellTool pourrait suffire
L’idéal serait qu’il apprenne à créer et tester lui-même ses outils pour pouvoir leur faire confiance
L’écosystème des connecteurs est facile à comprendre et à marketer, mais au fond cela ressemble à un paradigme erroné
Je pense qu’un petit modèle orchestrateur local serait utile
Dans beaucoup de cas, orchestrer tout le workflow de manière programmatique est peu efficace
Pour réduire la pollution du contexte et gagner en vitesse, l’architecture idéale serait programmatic > tiny local LLM > frontier LLM
Le petit modèle pourrait réinitialiser souvent son contexte et ne transmettre au grand modèle que les résultats nécessaires
Quand on utilise des assistants IA, certains schémas se répètent
Dès qu’on améliore soi-même une méthode inefficace, un nouvel outil sort quelques mois plus tard et rend ce travail inutile
C’est le prix à payer pour suivre l’état de l’art
Un jour, le web tout entier sera probablement composé de milliards d’outils
Google les indexera, et Gemini les sélectionnera dynamiquement pour agir dans le monde
En réalité, c’est ce genre de chose que j’attendais de Gemini 3
La fonctionnalité n°2 mentionnée ici est une implémentation de l’idée récemment discutée consistant à “ne pas appeler directement les outils mais écrire du code pour les appeler”
Elle fonctionne dans un sandbox Python, est aussi accessible via l’API, et expose l’appel d’outils comme un appel d’API classique
Le batch tool calling a déjà considérablement accéléré l’assistant IA de notre produit, et cette nouvelle fonctionnalité ressemble à son évolution
Notre agentic builder n’utilise qu’un seul outil — GraphQL
L’agent écrit des requêtes puis les exécute, et récupère les informations nécessaires via l’introspection
Cela permet de gagner des tokens en ne recevant que le strict minimum de données
Pas besoin de charger plus de 50 outils, et cela résout aussi le problème du N+1 dans les API REST
Grâce au typed schema de GraphQL, l’agent écrit un meilleur code
Avant, je n’aimais pas GraphQL, mais vu l’état actuel de MCP, je pense que c’est l’une des technologies les plus adaptées aux agents IA
J’ai détaillé cela dans cet article
Mon agent n’exécute qu’une seule chose : une requête SPARQL, et tout l’état vit dans une base de données graphe
Comme la plupart des ontologies sont publiques, il n’y a presque pas besoin d’introspection du schéma
Grâce à la sortie structurée, on peut aussi imposer la génération d’un RDF valide uniquement
J’imagine qu’une approche similaire est possible avec GraphQL
Je dois faire de la recherche web, appeler des API locales, intégrer Slack, etc. ; GraphQL seul ne suffit donc pas
Il y a certes des questions d’autorisations, de cache et de mutations, mais cela affecte peu le chargement sélectif du contexte
Les LLM rédigent plutôt bien des requêtes GraphQL conformes au schéma
Même lorsqu’ils se trompent, ils se corrigent vite si les messages d’erreur sont bons
Le raisonnement associé est expliqué dans ce billet de blog
Je trouvais déjà que sonnet 4.5 était plutôt bon,
mais opus 4.5 a l'air encore meilleur. Waouh.
Oui ? Quels aspects, principalement ?