MCP Tool Search : comment nous avons différé 120K tokens de schémas d'outils
Vingt-quatre connecteurs MCP consommaient environ 60 % de notre fenêtre de contexte avant même le moindre travail. Activer Tool Search a fait chuter ce chiffre à ~3K tokens. Voici la sortie de /context avant et après, ainsi que les patterns de consolidation qui nous ont aidés.
Le coût caché que nous n’avons pas remarqué pendant des semaines
Quand vous installez un serveur MCP (Model Context Protocol) dans Claude Code, vous obtenez des outils. Beaucoup d’outils. Le serveur MCP GitHub fournit à lui seul 35 outils — pour les issues, pull requests, branches, commentaires, releases, workflow runs, déploiements, alertes de sécurité, et plus encore.
Ce que vous obtenez aussi, par défaut, c’est le schéma JSON complet de chaque outil injecté dans le contexte au démarrage de la session. Noms, descriptions, types de paramètres, valeurs d’enum, exemples — tout cela, avant même que vous n’ayez tapé le moindre prompt.
Nous avons connecté 24 serveurs MCP au cours de la construction de Statnive. Nous n’avons pas pensé au coût jusqu’à ce que nos sessions commencent à se sentir à l’étroit. Puis nous avons exécuté /context pour la première fois.
Ce billet présente l’avant/après, le seul flag qui a fait 85 % du travail, et les trois autres patterns qui ont fini la tâche.
Ce que /context nous a montré
Voici la portion pertinente de notre sortie /context avant toute optimisation :
| Serveur MCP | Outils | Tokens consommés |
|---|---|---|
| GitHub | 35 | ~26 000 |
| Slack | 11 | ~21 000 |
| Jira | ~20 | ~17 000 |
| Playwright (automatisation navigateur) | 21 | ~13 647 |
| Context7 (docs de bibliothèques) | ~15 | ~8 000 |
| 19 autres connecteurs | ~190 | ~50 000 |
| Surcharge MCP totale | ~290 | ~135 000 |
C’est environ 67 % de l’intégralité de la fenêtre de contexte de 200K dépensé en définitions d’outils que nous n’utiliserions peut-être pas durant la session. Le pattern documenté ailleurs par les chercheurs tient : la surcharge MCP moyenne par outil est de ~500 à 710 tokens, et une charge modérée de connecteurs (24 serveurs) consomme régulièrement 48 000 à 120 000 tokens avant le moindre travail. Le cas le plus extrême documenté est le serveur MCP de Docker : 135 outils, ~126 000 tokens à lui seul.
Il nous restait ~65K tokens pour la conversation réelle, le system prompt, les outils intégrés, notre CLAUDE.md, les métadonnées de skills, et le buffer d’auto-compact. Voilà pourquoi tout semblait à l’étroit.
Tool Search : le seul flag qui a fait 85 % du travail
Claude Code v2.1.7 a livré MCP Tool Search. Au lieu d’injecter chaque schéma d’outil au démarrage, Tool Search construit un index léger d’environ 5K tokens contenant les noms et descriptions des outils. Le schéma complet d’un outil donné n’est chargé que lorsque Claude décide réellement de l’appeler. Une fois chargé, il reste en cache pour la session.
Les tests internes d’Anthropic ont montré une réduction de 134K à ~5K tokens — soit une coupe de 85 %. De manière contre-intuitive, la précision sur les évaluations MCP a augmenté, pas baissé : Opus 4 est passé de 49 % à 74 % sur le même benchmark, vraisemblablement parce que le modèle ne se noyait plus dans des schémas d’outils dont il n’avait pas besoin.
Tool Search s’active automatiquement lorsque les descriptions d’outils dépassent environ 10 % de la fenêtre de contexte (~20K tokens). En dessous de ce seuil, il reste désactivé, partant du principe que vous n’en avez pas besoin. Nous sommes largement au-dessus du seuil, donc il est toujours actif chez nous.
Après l’avoir activé, notre /context était radicalement différent :
| Source | Avant | Après |
|---|---|---|
| Schémas d’outils MCP | ~135 000 | ~3 000 (index seul) |
| Schémas d’outils MCP (durant une session ayant utilisé 4 outils) | ~135 000 | ~6 500 (index + 4 schémas chargés) |
| Contexte disponible pour le travail | ~65 000 | ~190 000 |
L’étape de vérification que nous ne sautons jamais : exécuter /context au début de session et confirmer la ligne indiquant que les schémas d’outils sont différés ou que Tool Search est actif. Si ce n’est pas le cas, vous payez pour rien.
Consolider les explosions de CRUD
Tool Search a été le levier unique le plus important, mais il n’aide pas si certains outils ont des descriptions boursouflées ou si vos serveurs exposent des dizaines d’outils quasi identiques.
Nous avons reconstruit l’un de nos serveurs MCP internes en utilisant un pattern documenté dans la recherche sous le nom de consolidation action-paramètre. L’API d’origine à dix outils pour la gestion des issues :
create_issue, update_issue, delete_issue, list_issues, get_issue,
add_comment, update_comment, delete_comment, list_comments, get_commentEst devenue un seul outil :
manage_issues({ action: "create" | "update" | "delete" | "list" | "get",
target: "issue" | "comment", ... })Résultats documentés d’un développeur ayant appliqué ce pattern : 20 outils sont passés de 14 214 tokens à 5 663 tokens — soit une réduction de 60 %. Le modèle continue à router correctement parce que le paramètre d’action est énuméré et que la description de l’outil nomme chaque opération supportée. Nous avons obtenu des résultats similaires sur notre propre consolidation : environ 9 800 tokens descendus à 4 100.
Même avec Tool Search différant les chargements de schémas, le chargement à la demande d’un outil unique « gros » est bien plus petit que celui de dix outils « légers », parce que la surcharge des schémas est dominée par du boilerplate répété (définitions de types, enveloppes d’erreur, patterns de pagination).
Élaguer les descriptions sans pitié
L’autre face de la même médaille. La prose marketing dans les descriptions d’outils coûte de vrais tokens.
Une description du genre :
« Search the web using Tavily Search API. Best for factual queries requiring reliable sources and citations from authoritative web content. Handles complex topics with academic depth and provides comprehensive results with relevance scoring… »
Coûte 87 tokens. Le même signal de routage dans :
« Search using Tavily. Best for factual/academic topics with citations. »
Coûte 12 tokens. Sur 290 outils, une économie moyenne de 50 tokens par description représente ~14 500 tokens.
La règle que nous appliquons : une description doit aider Claude à décider s’il faut appeler cet outil, pas faire la promotion de l’outil. Coupez tout ce qui ne change pas la décision de routage.
Quand nous avons gardé un outil chargé en avance
Un petit nombre d’outils que nous voulons charger en avance car ils se déclenchent à presque chaque session :
- Read, Write, Edit, Grep, Glob, Bash — intégrés, pas MCP, mais le principe est le même : une fréquence d’appel élevée justifie un chargement permanent.
- Deux serveurs MCP que nous utilisons plusieurs fois par session — notre outillage interne de release et notre serveur de récupération de docs. Leurs schémas totalisent ~3 500 tokens combinés ; un chargement à la demande 6 fois ou plus par session coûterait davantage en latence de re-fetch que ce que l’eager load économise.
Tool Search supporte une allowlist d’eager loading par serveur, précisément pour cette raison. Utilisez-la avec précision — chaque outil eager représente une surcharge permanente.
Plafonnez la sortie, sinon elle vous plafonnera
La variable d’environnement MCP MAX_MCP_OUTPUT_TOKENS vaut par défaut 25 000 tokens par réponse d’outil. C’est généreux pour une fenêtre de 200K avec un appel d’outil par tour. Avec 24 connecteurs et des outils qui se ramifient sur plusieurs appels par tour, c’est une manière garantie de remplir le contexte avec des réponses d’API brutes.
Nous avons plafonné le nôtre à 4 000 et avons exigé que les serveurs les plus verbeux supportent une pagination côté serveur et des formes de réponse « résumé d’abord ». Un appel GitHub list-issues retourne maintenant les 20 premières avec un marqueur has_more: true et un token de continuation, au lieu de déverser 200 issues dans le contexte. Le modèle peut en demander davantage si nécessaire ; en général il ne le fait pas.
Pour les workflows complexes multi-outils, Programmatic Tool Calling (Claude écrit un code d’orchestration qui s’exécute dans un environnement sandboxé, avec seulement les résultats finaux entrant dans le contexte) a montré une réduction de tokens de ~37 % dans les tests internes d’Anthropic sur des tâches à forte composante recherche. Nous l’utilisons pour un workflow — un agent Q&A qui interroge 6 serveurs de documentation — et les économies tiennent.
CLI > MCP pour les outils à usage occasionnel
Contre-intuitif mais bien réel : pour les outils que vous utilisez rarement, une commande shell est moins chère qu’un serveur MCP. gh, aws, gcloud, sentry-cli, wp — ils s’exécutent via l’outil Bash sans aucune surcharge persistante de contexte. La description de l’outil Bash (déjà chargée) est tout le contexte que vous payez. Le texte d’aide du binaire CLI ne se charge que si Claude le lit.
Nous avons retiré trois serveurs MCP rarement utilisés et les avons remplacés par un usage CLI. Cela à lui seul a économisé ~12 000 tokens de surcharge de base.
Le seuil de rentabilité est en gros : cet outil se déclenche-t-il plus d’une fois par session typique ? Si oui, MCP. Si non, CLI.
Ce que nous n’avons pas optimisé
MAX_MCP_OUTPUT_TOKENSest par appel, pas par session. Un serveur qui se comporte mal peut toujours inonder le contexte sur de nombreux tours. Nous n’avons pas encore de plafonds par session — c’est une demande de fonctionnalité pour Claude Code, pas quelque chose que nous pouvons corriger localement.- Tool Search est tout ou rien. Nous ne pouvons pas hiérarchiser les serveurs MCP comme nous hiérarchisons les skills. Nos 24 serveurs passent tous par Tool Search uniformément. Pour un serveur que nous utilisons à presque chaque session, l’eager loading serait en réalité plus efficace — mais nous ne pouvons pas charger en avance les schémas d’un seul serveur sans désactiver Tool Search globalement.
- Nous n’avons pas mesuré soigneusement la précision de routage sur nos propres charges de travail. Le 49 % → 74 % d’Anthropic sur Opus 4 est encourageant, et nous n’avons pas constaté d’échecs de routage en pratique, mais nous n’avons pas de suite de benchmarks pour prouver que le chargement différé fonctionne aussi bien pour les tâches spécifiques à Statnive que ne le ferait l’eager loading.
Les étapes pratiques si vous faites cela aujourd’hui
- Exécutez
/contextdans une session fraîche. Voyez ce qui est réellement chargé. - Si les schémas d’outils MCP dépassent ~20K tokens (10 % de la fenêtre), Tool Search devrait être actif automatiquement. Vérifiez-le depuis la sortie
/context. - Auditez vos trois connecteurs les plus lourds. La courbe de Pareto est brutale — généralement 3 serveurs consomment plus de 60 % de la surcharge MCP.
- Consolidez les explosions de CRUD dans tout serveur MCP que vous contrôlez.
- Élaguez les descriptions de tout outil dont la description ressemble à du copy marketing.
- Déplacez les outils à usage occasionnel de MCP vers CLI.
- Plafonnez
MAX_MCP_OUTPUT_TOKENSà une limite raisonnable par appel (nous utilisons 4 000).
Si vous voulez la vue d’ensemble — comment cela s’articule avec l’optimisation de CLAUDE.md et la hiérarchisation des skills pour livrer des économies multiplicatives — commencez par le billet phare de cette série.
Essayez Statnive
Analytics WordPress respectueux de la vie privée, livré par une équipe qui prête attention à où va chaque token. Installez Statnive gratuitement depuis WordPress.org — vos données restent sur votre serveur.