Lazy MCP loading : arrêtez de payer pour des outils inactifs

Qu'est-ce que le lazy MCP loading ?

Le lazy MCP loading consiste à différer le manifeste d'outils d'un serveur MCP — chaque nom d'outil, description et schéma de paramètres — jusqu'au moment où l'agent veut réellement appeler l'un de ses outils, au lieu d'injecter le manifeste entier dans le context window à chaque tour. Le comportement par défaut est « eager » (avide) : dès que vous connectez un serveur, son manifeste complet voyage avec chaque message que vous envoyez, que vous touchiez ces outils ou non. Le lazy loading inverse cela. L'agent voit un index léger au départ et ne récupère le schéma complet d'un outil que lorsqu'il décide de l'utiliser. Je passe l'essentiel de ma journée dans Claude Code avec une poignée de serveurs connectés, et ce qui me dérangeait — une fois que j'ai commencé à vraiment compter les tokens — c'était combien je payais pour des outils qui restaient simplement là. Vous connectez GitHub parce que vous relisez des PR deux fois par semaine, puis vous payez son manifeste sur chaque prompt, y compris les trois cents où vous êtes juste en train d'éditer une fonction. C'est le problème que le lazy loading existe pour résoudre. C'est une ramification de la question plus large : comment réduire la consommation de tokens d'un agent de coding IA. Si vous voulez le menu complet des leviers, commencez par là. Cet article porte sur un seul levier, fait correctement.

Pourquoi l'eager MCP loading coûte-t-il aussi cher ?

L'eager loading coûte aussi cher parce que le manifeste est une surcharge fixe payée à chaque tour, et les tours s'additionnent vite. Une session de coding n'est pas une grande requête unique — ce sont des dizaines ou des centaines d'allers-retours à mesure que l'agent lit des fichiers, exécute des commandes et réagit à la sortie. Chacun de ces allers-retours renvoie le system prompt et le manifeste d'outils complet pour chaque serveur connecté. Voici la partie qui surprend les gens : le manifeste d'un gros serveur peut être volumineux. Le serveur GitHub MCP embarque de l'ordre de 90 outils et plus, et les mesures de son manifeste l'estiment à environ 50 000 tokens — environ un quart du context window de 200K de Claude, payé avant même que vous ayez tapé un mot. Connectez deux ou trois serveurs comme celui-là et vous avez dépensé une part significative de votre fenêtre sur du texte que le modèle ignore le plus souvent. Maintenant, multipliez par les tours et par le prix. Avec Claude Opus 4.8 à 5 $ par million de tokens d'entrée, 50 000 tokens de manifeste représentent 0,25 $ d'input — une fois. Mais s'ils voyagent sur 150 tours dans une session, cela fait 37,50 $ d'input juste pour le privilège d'avoir un outil connecté que vous n'appellerez peut-être jamais. Le prompt caching aide beaucoup ici, car les cache reads tournent à environ 10 % du prix d'input, ce qui ramène cela à quelques dollars — mais le caching ne fonctionne que tant que le préfixe est stable et que le cache est chaud, et un manifeste que vous n'utilisez jamais reste des tokens que vous n'aviez jamais besoin d'envoyer. Sur Sonnet 4.6 (3 $ / 15 $ par MTok) ou Haiku 4.5 (1 $ / 5 $), les chiffres absolus rétrécissent, mais le ratio ne change pas : vous payez en continu pour une capacité que vous utilisez par intermittence. Les chiffres derrière tout cela sont rassemblés dans notre analyse des coûts en tokens des agents de coding IA.

Comment le lazy loading fonctionne-t-il réellement ?

Le lazy loading fonctionne en scindant le manifeste en un index bon marché et un corps coûteux, et en n'envoyant le corps qu'à la demande. La mécanique est simple une fois que vous la voyez :

À la connexion, l'agent reçoit un descripteur minimal par serveur — assez pour savoir que le serveur existe et grosso modo ce qu'il couvre — plutôt que le schéma complet de tous ses outils.
Lorsque le modèle décide qu'il a besoin d'un outil, le loader résout le schéma complet de cet outil spécifique (ou de ce groupe d'outils) et l'injecte pour les tours où il est pertinent.
Lorsque le travail est terminé, le schéma peut ressortir du contexte actif, de sorte qu'il n'est pas renvoyé sur les deux cents tours suivants sans rapport.

Le résultat, c'est que le plancher par tour — le coût que vous payez avant d'avoir dit quoi que ce soit d'utile — s'effondre vers zéro pour les serveurs que vous n'utilisez pas actuellement. Vous gardez la capacité ; vous arrêtez de la prépayer. C'est le même type de mouvement que l'output filtering (compacter les résultats d'outils bruyants avant qu'ils n'atteignent le contexte) et la semantic code search (récupérer le bon code par le sens plutôt que de déverser des fichiers entiers) — levier différent, même principe : seuls les octets qui méritent leur place devraient atteindre le modèle. Cela se marie naturellement avec le prompt caching plutôt que de le concurrencer. Le caching rend les octets que vous envoyez effectivement moins chers à renvoyer ; le lazy loading garantit que vous n'alliez de toute façon pas en envoyer la plupart en premier lieu. Empilez les deux et les économies se cumulent.

Comment appliquer le lazy MCP loading dès aujourd'hui

Vous pouvez obtenir l'essentiel du bénéfice dès aujourd'hui avec un mélange de discipline et d'outillage. Par ordre d'effort approximatif :

Auditez ce qui est connecté. Listez vos serveurs MCP actifs et, pour chacun, demandez-vous honnêtement : est-ce que j'appelle celui-ci sur la plupart des sessions, ou une fois par semaine ? Le coût du manifeste est payé quotidiennement quelle que soit la fréquence. Notre classement des meilleurs serveurs MCP pour Claude Code note chaque serveur courant exactement sur ce point — le coût en tokens, pas seulement l'utilité.
Élaguez sans pitié. Le token le moins cher est celui que vous n'envoyez jamais. Un serveur que vous utilisez chaque semaine vaut généralement mieux connecté à la demande que laissé en permanence. C'est la version manuelle du lazy loading, et c'est gratuit.
Ne gardez qu'un ou deux serveurs toujours actifs. Choisissez ceux qui se déclenchent sur la plupart des tours. Tout le reste est candidat à un traitement lazy.
Laissez une couche le faire automatiquement. L'élagage manuel est un vrai travail et vous vous tromperez. C'est là qu'intervient Tokenade : il se place entre votre agent et ses serveurs et charge les manifestes d'outils de manière lazy — le schéma complet n'est récupéré que lorsque l'agent réclame cet outil — de sorte qu'une configuration à quatre ou cinq serveurs coûte à peu près ce qu'une configuration à un serveur coûtait. Il fait de même pour la sortie bruyante (il compacte avant le contexte) et les lectures de codebase (semantic search au lieu de déversements de fichiers entiers), et vous montre les économies sur un dashboard pour que vous puissiez voir le plancher par tour effectivement baisser.

Une vérification rapide avant de vous engager dans quoi que ce soit : lancez une session normale et regardez combien de tokens d'entrée atterrissent avant votre première véritable instruction. Si une grande partie de cela est constituée de manifestes d'outils que vous n'avez pas touchés, le lazy loading est de l'argent gratuit. Vous pouvez vérifier des chiffres approximatifs avec le token counter et le calculateur de coût en tokens LLM.

Ce qui tourne mal (anti-patterns)

Les modes de défaillance ici concernent surtout la confusion entre « connecté » et « gratuit ». Quelques-uns à surveiller :

Thésauriser les serveurs. Connecter chaque serveur MCP intéressant « au cas où » est l'habitude la plus coûteuse à elle seule. Chacun ajoute une surcharge fixe par tour, qu'il se déclenche ou non. Si vous ne paieriez pas un abonnement mensuel pour un outil que vous utilisez une fois par quinzaine, ne payez pas non plus une taxe par tour pour lui.
Supposer que le caching le rend gratuit. Le prompt caching réduit le coût de renvoi à environ 10 % de l'input, ce qui est excellent — mais il n'aide pas sur un cache froid, ne survit pas à un changement de manifeste et ne bat jamais le simple fait de ne pas envoyer les octets. Le caching est une remise sur une facture que vous pouvez en grande partie éviter.
Lazy loader les mauvais outils. Si un outil se déclenche réellement sur la plupart des tours, le différer ne fait qu'ajouter un aller-retour pour résoudre le schéma à chaque fois. Le lazy loading est pour la longue traîne — les serveurs que vous sollicitez occasionnellement — pas pour le ou les deux dans lesquels vous vivez.
Estimer à l'œil au lieu de mesurer. « Ça semble plus léger » n'est pas un chiffre. Suivez le plancher d'input par tour avant et après, sur une charge de travail réelle. Si vous ne pouvez pas voir les économies, vous ne pouvez pas les régler.

Le résumé honnête : la plupart d'entre nous avons connecté trop de serveurs MCP, n'avons jamais compté ce qu'ils coûtaient, et avons laissé le prompt caching masquer la facture. Le lazy loading est la correction structurelle — payer pour les outils quand vous les utilisez, pas quand vous les connectez. C'est une idée plus petite que le context engineering dans son ensemble, mais c'est l'une de ses pièces à plus fort effet de levier, et contrairement à la plupart de cette discipline, c'est quelque chose qu'un outil peut simplement faire pour vous.

Voir aussi :