Les serveurs MCP peuvent consommer des dizaines de milliers de tokens avant même que vous ne tapiez votre premier prompt. Cet article explique comment mesurer ce coût avec /context, supprimer les serveurs inactifs, activer la recherche d’outils, limiter la sortie des outils et utiliser des sous-agents, pour que Claude Code réserve sa fenêtre de contexte à votre travail réel.
Vous ouvrez Claude Code, tapez un prompt court, et la jauge de contexte affiche déjà la moitié. Votre prompt n’y est pour rien. Le coupable est généralement l’accumulation de serveurs MCP que vous avez connectés le mois dernier et oubliés. Chaque serveur remet à Claude une liste de définitions d’outils dès le début de la session, et chaque définition se paie en tokens avant même que le travail commence. Ajoutez quelques réponses d’outils trop volumineuses et la fenêtre de contexte est épuisée bien avant la fin de la tâche. La bonne nouvelle, c’est que c’est l’un des problèmes les plus faciles à corriger de tout le flux de travail. Cet article détaille l’ordre qui fonctionne : mesurer d’abord, puis élaguer les serveurs, activer la recherche d’outils, limiter la sortie et réinitialiser les sessions au bon moment.
Si vous reconnaissez ces symptômes, vous n’êtes pas seul. Des sessions qui paraissent lentes, des réponses qui oublient les consignes données dix minutes plus tôt, et une auto-compaction qui se déclenche au milieu d’un refactoring pointent toutes vers la même cause : trop de surcharge fixe et trop peu de place pour le travail lui-même.
Le Model Context Protocol (MCP) permet à Claude Code de communiquer avec des bases de données, des navigateurs, des outils de suivi de tickets, des outils de design et des générateurs d’images. Chaque connexion est réellement utile. Le prix à payer : Claude doit connaître ce que fait chaque outil, donc le nom, la description et le schéma JSON complet de chaque outil sont chargés dans le prompt.
La surcharge MCP provient de quatre sources, dont seules certaines sont évidentes.
| Source | Moment du chargement | Impact typique | Qui la contrôle |
|---|---|---|---|
| Définitions d’outils | Au démarrage de la session | Des centaines de tokens par outil, des milliers par serveur | Vous, en choisissant les serveurs |
| Réponses des outils | À chaque appel | De quelques centaines à des dizaines de milliers de tokens | Le serveur et votre limite de sortie |
| Fichiers de mémoire comme CLAUDE.md | Au démarrage de la session | Augmente avec chaque règle ajoutée | Vous |
| Historique de conversation | Se construit pendant toute la session | Augmente à chaque échange | La compaction et l’effacement |
L’article technique d’Anthropic sur la recherche d’outils décrit une configuration avec 58 outils répartis sur cinq serveurs qui ont consommé environ 55K tokens avant même le début de la conversation. Cela représente environ 950 tokens par outil. Un serveur comptant 35 outils, comme une intégration complète d’hébergement de code, peut à lui seul absorber une part à deux chiffres d’une fenêtre de contexte standard.
💡 Calcul rapide : si vos outils pèsent en moyenne 900 tokens chacun et que vous en connectez 40, vous avez dépensé environ 36 000 tokens pour un menu dans lequel Claude ne commandera peut-être jamais.
Les outils inactifs nuisent de deux façons. La première est l’espace pur : une fenêtre qui démarre remplie à 30 % dispose de 30 % de place en moins pour le code, les journaux et le raisonnement. Le cache de prompt atténue le prix de cette surcharge fixe lors des tours suivants, mais il ne fait rien pour la place qu’elle occupe.
La seconde est le bruit décisionnel. Lorsque cinq serveurs exposent des outils de recherche ou de récupération qui se chevauchent, le modèle a davantage de quasi-doublons parmi lesquels choisir. Les propres tests d’Anthropic sur le chargement à la demande des outils ont montré qu’exposer moins d’outils dès le départ améliorait aussi la fiabilité avec laquelle le bon outil était choisi. Moins d’outils, ce n’est pas seulement moins cher, c’est souvent plus précis.
Ne commencez pas à supprimer des serveurs au hasard. Mesurez, changez une seule chose, puis mesurez à nouveau.
Ouvrez une session neuve dans votre projet et lancez /context avant d’envoyer le moindre prompt. Claude Code affiche une répartition de la fenêtre par catégorie : prompt système, outils système, outils MCP, fichiers de mémoire, messages et espace libre. Comme vous n’avez encore rien tapé, la ligne messages est proche de zéro et tout le reste n’est que surcharge.
Lancez ensuite /mcp pour lister les serveurs connectés et leur statut. Depuis un terminal classique, claude mcp list donne le même inventaire. Notez le nombre d’outils MCP indiqué par /context. C’est votre référence de départ.
Il n’existe aucun seuil officiel, mais cette règle empirique fonctionne bien en pratique :
| Part des outils MCP dans la fenêtre | Verdict | Que faire |
|---|---|---|
| Moins de 5 % | Saine | Ne touchez à rien |
| De 5 % à 15 % | À surveiller | Supprimez les serveurs que vous utilisez moins d’une fois par semaine |
| Plus de 15 % | Un vrai problème | Élaguez fortement et activez la recherche d’outils |
Vérifiez aussi la ligne des fichiers de mémoire. Un CLAUDE.md devenu un mur de règles coûte des tokens à chaque session, tout comme un serveur MCP bavard.
Le token le moins cher est celui qui n’est jamais chargé. L’hygiène des serveurs bat tous les réglages astucieux.
Ouvrez le menu /mcp et désactivez tout ce dont vous n’avez pas besoin pour la tâche du jour. Selon votre version, vous pouvez activer ou désactiver un serveur sans perdre sa configuration. Lorsque vous êtes sûr qu’un serveur ne sert plus à rien, supprimez-le définitivement avec claude mcp remove <name>.
Posez-vous trois questions au sujet de chaque serveur :
Un « non » honnête suffit pour le désactiver.
Les serveurs MCP peuvent être ajoutés à trois niveaux : local, projet et utilisateur. Un serveur de niveau projet est enregistré dans un fichier .mcp.json à la racine du dépôt, ainsi il ne se charge que là où il est utile :
claude mcp add --scope project my-db -- npx my-db-mcp-server
Gardez votre niveau utilisateur presque vide. Placez le serveur de base de données dans le dépôt qui contient une base de données, et le serveur de design dans le dépôt qui contient des designs. Pour les sessions ponctuelles, vous pouvez aussi démarrer Claude Code avec uniquement les serveurs nommés dans un fichier de configuration :
claude --strict-mcp-config --mcp-config ./mcp/docs-only.json
Cette session ignore tous les autres serveurs configurés, ce qui la rend idéale pour une tâche ciblée ou pour une comparaison nette avant et après.
Si un outil existe déjà sous forme de programme en ligne de commande, comme git, gh, docker, psql ou aws, Claude peut l’exécuter via le shell. Cela ne coûte aucun token de définition d’outil, puisque le modèle connaît déjà le fonctionnement de ces commandes.
Anthropic a poussé cette idée plus loin dans son article sur l’exécution de code avec MCP. Présenter les serveurs comme des API de code que l’agent appelle depuis un script, plutôt que comme des outils individuels, a fait passer un exemple de flux de travail d’environ 150 000 tokens à environ 2 000, soit une réduction de 98,7 %. Vous n’avez pas besoin de reconstruire votre environnement pour profiter de cette leçon.
MCP reste le meilleur choix dans certains cas :
Pour tout le reste, essayez d’abord la CLI.
Il arrive que vous ayez vraiment besoin de disposer de dizaines d’outils. C’est là que le chargement différé prend tout son intérêt.
Au lieu de coller chaque définition d’outil dans le prompt, le client charge un petit outil de recherche ainsi qu’une liste de noms d’outils. Lorsque Claude estime avoir besoin de quelque chose, il effectue une recherche, et seules les définitions correspondantes sont chargées. Dans les versions récentes de Claude Code, cela s’active automatiquement dès que les définitions des outils MCP occuperaient une part importante de la fenêtre, environ 10 % au moment de la rédaction.
Anthropic a fait état d’une baisse d’environ 85 % des tokens de définition d’outils dans son propre exemple. L’idée est celle d’un fichier de bibliothèque : on n’emporte pas chaque livre à son bureau, on emporte l’index et on va chercher ce dont on a besoin.
Le comportement est contrôlé par la variable d’environnement ENABLE_TOOL_SEARCH :
# Default: only kicks in when MCP tools get large
export ENABLE_TOOL_SEARCH=auto
# Lower the trigger point (percent of the window)
export ENABLE_TOOL_SEARCH=auto:5
Les noms et les seuils ont changé d’une version à l’autre. Vérifiez donc la documentation de la version que vous avez installée.
💡 Relancez toujours
/contextaprès un changement. Si la ligne des outils MCP n’a pas diminué, le réglage ne fait pas ce que vous pensez.
Il y a un compromis. La première utilisation d’un outil différé coûte une étape de recherche supplémentaire. Si vous appelez les mêmes trois outils à chaque session, gardez ce petit serveur chargé directement et laissez la recherche d’outils gérer la longue traîne.
Les définitions sont un coût fixe. Les réponses constituent le coût variable, celui qui surprend le plus.
Claude Code avertit lorsqu’un seul résultat d’outil MCP dépasse environ 10 000 tokens et le tronque par défaut à 25 000. Vous pouvez abaisser ce plafond avec une variable d’environnement :
export MAX_MCP_OUTPUT_TOKENS=10000
Une limite est un filet de sécurité, pas une conception. La meilleure solution consiste à utiliser un serveur qui renvoie moins de données dès le départ. Si vous créez ou configurez des serveurs, privilégiez ces schémas :
| Schéma | Problème | Meilleure approche |
|---|---|---|
| Renvoyer un tableau entier | Des dizaines de milliers de lignes dans le contexte | Filtrer, trier et limiter côté serveur |
| Intégrer une image en base64 | Des milliers de tokens par image | Renvoyer une URL hébergée |
| Renvoyer le HTML brut d’une page | Le balisage domine le contenu | Extraire le texte d’un seul sélecteur |
| Interroger un statut avec la charge complète | Le volume se répète à chaque interrogation | Renvoyer uniquement un champ de statut jusqu’à la fin du traitement |
Les images sont facturées selon leur taille, environ largeur × hauteur divisé par 750 en tokens d’entrée. Une image de 1 000 × 1 000 pixels coûte environ 1 300 tokens, et une capture d’écran en pleine résolution coûte plusieurs fois ce montant. Les serveurs qui génèrent des images ou des clips doivent renvoyer une URL courte et un statut, jamais les pixels eux-mêmes.
La génération d’images et de vidéos est le premier domaine où cela se voit. Le connecteur MCP de PicassoIA fonctionne de la bonne façon : un appel de génération renvoie tout de suite un identifiant de prédiction, puis vous interrogez le statut jusqu’à ce qu’une URL hébergée apparaisse. Si vous choisissez un générateur à appeler depuis un agent, des modèles texte vers image comme P-Image et Flux 2 Pro s’associent bien à ce schéma, et un modèle vidéo comme Seedance 2.5 Lite suit la même boucle création, interrogation, récupération.
Même une configuration allégée se remplit au cours d’une longue session. Le dernier niveau de défense, c’est la structure.
Un sous-agent s’exécute dans sa propre fenêtre de contexte et ne renvoie qu’un résumé. Il est donc idéal pour les travaux bruyants : automatisation de navigateur, recherches volumineuses, boucles de génération d’images. Un fichier de sous-agent dans .claude/agents/ comporte un nom, une description, une liste blanche tools et un model, ce qui permet de le restreindre aux deux ou trois outils dont il a exactement besoin.
Pensez-y comme à la mise en place : chaque bol contient un seul ingrédient, et rien d’autre ne touche le plan de travail. Pour les tâches mécaniques, un petit modèle comme Claude 4.5 Haiku suffit souvent, et il laisse votre session principale libre pour la réflexion qui requiert un modèle plus puissant. Les versions récentes permettent aussi à un sous-agent de déclarer ses propres serveurs MCP, afin que les plus lourds ne touchent jamais la conversation principale.
/compact remplace la conversation en cours par un résumé, et vous pouvez l’orienter :
/compact keep the failing test names, file paths and the final design decision
Lancez-la aux points de rupture naturels : une fonctionnalité vient d’aboutir, les tests viennent de passer au vert, vous vous apprêtez à entamer une nouvelle étape. N’attendez pas l’auto-compaction. Elle se déclenche lorsque la fenêtre est presque pleine, ce qui peut tomber en plein milieu d’une modification délicate.
Si vous passez à une tâche sans rapport, ne compactez pas. Effacez. Un ancien contexte sur un autre bogue n’est pas un atout, c’est du bruit qui oriente les réponses de travers. Après /clear, chargez uniquement ce dont la nouvelle tâche a besoin.
💡 Les faits durables vont dans CLAUDE.md, mais gardez-le court. Il se charge à chaque session, donc chaque paragraphe en trop est une taxe que vous payez éternellement. Relisez-le chaque mois et supprimez les règles que le modèle suit déjà sans qu’on les lui demande.
Voici une façon sans risque de réduire le côté entrée de vos sessions avant même qu’elles n’atteignent Claude Code. Claude Sonnet 5 sur PicassoIA est conçu pour les tâches de programmation et d’utilisation d’outils, ce qui en fait un bac à sable pratique pour condenser un CLAUDE.md trop chargé, résumer un long journal ou rédiger un prompt plus serré. Collez le résultat dans Claude Code plutôt que ce fouillis brut.
low, qui désactive la réflexion pour des réponses plus rapides et moins coûteuses. Augmentez-le uniquement pour un raisonnement vraiment complexe.max_tokens est fixé par défaut à 8 192. Pour un résumé, une valeur bien plus basse garde la réponse concise.max_image_resolution est fixée par défaut à 0,5 mégapixel et réduit les images avant qu’elles n’atteignent le modèle, ce qui fait gagner du temps et de l’argent.| Réglage | Valeur par défaut | Geste d’économie |
|---|---|---|
effort | low | Gardez low pour les résumés et les réécritures |
max_tokens | 8192 | Abaissez-le pour correspondre à la taille de la réponse souhaitée |
max_image_resolution | 0,5 mégapixel | Gardez-le bas, sauf si les détails fins comptent |
system_prompt | vide | Définissez une règle de format courte une fois et réutilisez-la |
Pour les tâches de raisonnement plus complexes, comme planifier un refactoring sur de nombreux fichiers, Claude Fable 5 et Claude Opus 4.7 sont disponibles sur la même plateforme, ce qui vous permet de comparer la façon dont chacun traite la même entrée allégée.
Voici l’ensemble du plan sur une page, classé par effort et gain :
| Correctif | Effort | Gain typique |
|---|---|---|
Lancer /context et noter une référence | 2 minutes | Montre où partent les tokens |
| Désactiver ou supprimer les serveurs inactifs | 5 minutes | Souvent le gain le plus important |
Limiter les serveurs avec .mcp.json | 10 minutes | Empêche les serveurs globaux de se charger partout |
| Remplacer les serveurs légers par des CLI | 15 minutes | Supprime totalement les définitions |
| Activer la recherche d’outils | 2 minutes | Forte réduction pour les grands ensembles de serveurs |
Abaisser MAX_MCP_OUTPUT_TOKENS | 1 minute | Protège contre les réponses incontrôlées |
| Sous-agents pour les travaux bruyants | 20 minutes | Garde la fenêtre principale propre |
/compact aux points de rupture, /clear entre les tâches | En continu | Empêche le dépassement en pleine tâche |
Commencez par les deux premières lignes aujourd’hui. Elles prennent moins de dix minutes et libèrent souvent une place étonnante.
Une fois votre fenêtre de nouveau dégagée, mettez-la au service de quelque chose de créatif. Ouvrez PicassoIA, choisissez un modèle d’image comme GPT Image 2 ou P-Image, et générez votre première image à partir d’une simple phrase. Animez-la ensuite avec Seedance 2.5 Lite ou PicassoIA Video. Testez votre propre idée, modifiez un détail du prompt et observez à quel point le résultat change. C’est le moyen le plus rapide de voir ce que ces modèles savent faire, et chaque essai est une bonne raison de garder votre contexte léger.
Choisissez votre langue
