Gonflement du contexte MCP : coûts réels et solution pratique pour les utilisateurs de Claude Code

Un utilisateur de Reddit exécutant 9 serveurs MCP dans Claude Code pendant quatre mois a détaillé les coûts cachés et la dégradation des performances rencontrés, ainsi qu'un correctif concret. Le post est une lecture incontournable pour quiconque utilise MCP en production.

Les chiffres

Avec 9 serveurs (filesystem, GitHub, Stripe, Linear, Notion, Postgres, Sentry, AWS et un serveur personnalisé) exposant 142 outils au total, le démarrage à froid consomme 38k tokens de prompt système + schémas d'outils à chaque tour. À raison de 200 tours/jour, cela représente 7,6M tokens d'entrée par jour. Au tarif Sonnet (~15 $/M en sortie, ~3 $/M en entrée), cela fait ~23 $/jour soit ~700 $/mois rien que pour les définitions d'outils MCP, avant tout travail réel. Le cache n'aide que sur des préfixes identiques ; faire tourner un serveur MCP l'invalide.

Ce qui pose problème

• La sélection d'outils se dégrade : Avec 142 outils en contexte, Claude a commencé à choisir le mauvais outil pour des requêtes évidentes (par exemple, utiliser linear_search_issues quand on lui demandait de lire un fichier).
• Énumération lente : Les serveurs avec beaucoup de schémas comme AWS mettent 4 à 6 secondes à lister les outils.
• Propagation silencieuse des erreurs : Un outil mal décrit peut fausser le classement pour toutes les requêtes connexes.

Le correctif : Modèle de passerelle avec BM25

L'utilisateur est passé à un modèle de passerelle utilisant Ratel, une bibliothèque Rust open source, intégrée au processus, avec classement BM25. Claude ne voit plus que trois outils : search_tools, invoke_tool et auth. Tout le reste est classé à la demande. Résultats :

• Le démarrage à froid est passé de 38k à ~4k tokens.
• La sélection du mauvais outil a été presque éliminée car le modèle ne voit jamais que les 5 premiers classés par requête.
• La configuration a pris 10 minutes (une seule commande pour l'import Claude Code).

L'auteur note que la plupart des startups d'« optimiseur MCP » ne sont que de la recherche BM25 déguisée. Les descriptions d'outils sont courtes, structurées et pleines de correspondances de mots-clés — pas besoin de base vectorielle ni de LLM dans la boucle. BM25 sur une projection plate du nom + description obtient 90% du gain de manière déterministe, en microsecondes, hors ligne.

Leçon clé : « remplacer » bat « suggérer ». Si votre passerelle donne 5 outils au modèle au lieu de 142, le calcul tient. Si elle en suggère 5 à côté de 142, le modèle charge toujours 142 et vous n'avez rien économisé.