Contexte MCP dans Claude Code : garder l'outil ou lancer une commande ?
Une procédure réversible pour estimer l'effet d'un serveur MCP sur le contexte de Claude Code sans inventer d'économie fixe de tokens.
Sommaire
Contexte MCP dans Claude Code : garder l’outil ou lancer une commande ?
Un serveur MCP est utile quand Claude Code doit atteindre un système hors du répertoire de travail : tickets, API interne, base de données ou données d’observabilité. Il ajoute aussi à la session les noms d’outils, leurs descriptions, schémas d’entrée et actions possibles. La bonne question n’est donc pas « MCP coûte-t-il des tokens ? », mais : cette tâche a-t-elle besoin d’un accès externe répété, ou une action locale courte suffit-elle ?
Ne désactivez pas tous les serveurs après une réponse trop longue. Prenez une tâche courte, répétable et sans effet externe, mesurez-la, puis retirez ou réduisez un seul serveur. Le nombre de tours, les appels réellement nécessaires et le résultat vérifiable sont plus utiles qu’une impression de contexte trop chargé.
Si vous testez un workflow API Claude Code distinct, ouvrez le guide BetterToken à jour, exécutez deux fois le même prompt avec le même modèle, puis comparez immédiatement dans le Dashboard l’heure, le modèle, le statut, les tokens d’entrée/sortie/cache et la consommation affichée. Un doute sur le contexte devient ainsi un test A/B vérifiable. Commencez par une tâche read-only et ne stockez pas la clé API dans le dépôt.
D’où peut venir le contexte supplémentaire
La documentation MCP de Claude Code présente MCP comme une connexion à des outils et données externes. Pour le modèle, il ne s’agit pas seulement du résultat d’un appel : avant même cet appel, il doit pouvoir prendre en compte le rôle des outils, leurs paramètres et leurs limites. Un serveur très large, dont beaucoup d’outils restent visibles sans filtre, augmente donc l’interface à considérer.
Il n’existe pas pour autant de « coût MCP » fixe. Le résultat dépend du serveur, des outils activés, du prompt, du modèle, de l’historique de session et des données renvoyées. Distinguez au moins ces situations :
- de nombreux schémas sont proposés alors qu’aucun outil ne sert à la tâche ;
- un appel renvoie un résultat long que les tours suivants doivent interpréter ;
- un résultat trop large provoque de nouvelles recherches ou lectures ;
- en supprimant un outil, on perd une vérification externe et l’agent se met à supposer.
Aucune de ces observations ne prouve à elle seule l’origine de tous les tokens. La taille du dépôt, le prompt et l’historique changent aussi la mesure.
Choisir la plus petite interface utile
| Situation | Premier choix | Pourquoi |
|---|---|---|
| Lire et mettre à jour des tickets plusieurs fois | MCP de suivi étroit | La tâche demande un modèle d’objets externe réutilisable. |
| Vérifier une fois un état local | commande locale ou fichier d’état | Le fait demandé existe déjà dans l’espace de travail. |
| Lire une API interne dans beaucoup de tâches | outils MCP read-only à portée réduite | L’accès reste répétable et contrôlable. |
| Ouvrir un document du dépôt | recherche puis lecture du fichier | Un catalogue d’outils externe n’apporte rien. |
| Modifier un système externe | contrôle manuel ou read-only d’abord | Autorisation, idempotence et vérification restent nécessaires. |
Le choix dépend de la fréquence et de la frontière des données, pas de la popularité d’un serveur. Pour un unique état Git, une commande suffit souvent. À l’inverse, une commande ne remplace pas une interface sûre lorsqu’il faut effectuer plusieurs opérations liées sur des données externes structurées.
Mesurer une tâche réellement comparable
Choisissez une tâche sans effet de bord : trouver le responsable d’un fichier modifié, vérifier l’état local ou lire des éléments ouverts dans un projet de test. Ne comparez pas deux tâches différentes et ne tirez pas de conclusion générale d’une session exceptionnellement longue.
- Notez le prompt, le répertoire et le résultat attendu. Par exemple : « affiche les fichiers modifiés et propose une étape suivante sans modifier le dépôt ».
- Exécutez la tâche avec le profil MCP actuel. Conservez uniquement les observations sûres : nombre de tours, outils utilisés, résultat et heure. N’enregistrez ni clé API, ni
.env, ni sortie complète sensible. - Dans
/mcp, désactivez un seul serveur. Sa configuration est conservée et le serveur est marqué désactivé. Fermez la session, ouvrez-en une nouvelle, vérifiez dans/mcpqu’il reste listé mais non connecté, puis répétez exactement le prompt. - Comparez d’abord le fait obtenu. L’agent a-t-il récupéré le même élément nécessaire ou a-t-il remplacé un appel utile par une supposition ?
- Réactivez le serveur dans
/mcp, ouvrez une nouvelle session et vérifiez son état. Restaurez-le si son absence impose une copie manuelle ou retire une validation importante. Gardez la configuration réduite si le résultat reste le même avec moins d’appels inutiles.
Une session neuve est indispensable : l’ancienne contient déjà des résultats d’outils. Ce test ne mesure pas les performances universelles de Claude Code ; il éclaire votre flux de travail courant.
Une commande vraiment équivalente
Ne remplacez pas MCP par une commande arbitraire. Pour le même fait local, une commande read-only peut servir de comparaison :
git status --shortDans les deux variantes, demandez seulement la liste des fichiers modifiés et une étape suivante sans écriture. Gardez le même prompt et la même liste attendue. Vérifiez d’abord la liste, puis les tours, appels et tokens. Si MCP apportait un fait externe absent de git status, le remplacement n’est pas équivalent : gardez un MCP read-only étroit ou une commande documentée vers le même système.
Réduire l’interface avant de retirer un serveur
Un serveur large peut exposer beaucoup de commandes alors que le projet n’en utilise régulièrement qu’une ou deux. Commencez par réduire cette surface :
- activez seulement les outils read-only pour le premier test ;
- désactivez les intégrations inutiles à ce dépôt ;
- séparez les profils développement, support et administration ;
- ne placez ni secrets, ni longs logs, ni historique de conversation dans une description d’outil ;
- documentez les opérations rares par une commande courte et son résultat attendu.
MCP peut lire des données externes ou déclencher des actions ; sa présence ne remplace ni la vérification du scope ni le contrôle du résultat. Une réponse textuelle du modèle ne prouve pas qu’une opération externe a bien réussi.
Comparer usage et coût correctement
Pour un test API, vous pouvez configurer Claude Code avec votre propre clé BetterToken en suivant le guide Claude Code. BetterToken est un accès API distinct, pas un abonnement Claude. La clé est créée et gérée dans le compte de l’utilisateur ; elle ne doit pas apparaître dans le dépôt, un handoff ou les notes d’essai.
Le Dashboard BetterToken affiche l’heure, le modèle, le statut, les tokens d’entrée, de sortie et de cache ainsi que la consommation associée. Pour chaque exécution, enregistrez model, date et heure, input, output, cache, coût affiché et nombre de tours. Conservez le même modèle et le même prompt dans les deux exécutions.
Si le Dashboard affiche le coût, calculez différence observée = coût avec MCP − coût sans MCP. Si seuls les tokens sont visibles, ouvrez d’abord la page de prix actuelle, notez la date, le modèle et les règles de cache, puis utilisez coût = input/1 000 000 × Pinput + output/1 000 000 × Poutput + cache/1 000 000 × Pcache uniquement si le cache a un tarif séparé. Une valeur vide ou ambiguë n’est pas zéro et un ancien tarif ne doit pas être réutilisé. Cette différence décrit deux exécutions, pas un prix fixe de MCP.
Vérifier la décision dans le bon ordre
- Fait externe requis. Le remplacement doit obtenir réellement le ticket, statut, enregistrement API ou document requis, sans le deviner.
- Exactitude et limite d’accès. Comparez le résultat attendu et gardez le test read-only, sans nouveau secret ni scope plus large.
- Validation préservée. Vérifiez que le remplacement n’a pas supprimé un contrôle réalisé auparavant par l’outil ; une réponse de modèle n’est pas une preuve externe.
- Coût seulement ensuite. Comparez tours, appels, tokens input/output/cache et coût Dashboard avec le même prompt dans une session neuve.
Si l’un des trois premiers points échoue, une consommation plus faible n’améliore pas le flux : les tâches ne sont plus comparables ou une personne porte la validation perdue.
Quand réexaminer le choix
Réactivez un serveur si son absence empêche d’obtenir un fait externe requis, produit des suggestions non vérifiées ou force à recopier les mêmes données dans chaque prompt. Gardez le profil plus étroit si le résultat requis reste vérifié avec moins d’appels inutiles. Un bon profil MCP est souvent discret : chaque outil actif a une tâche récurrente ; pour le reste, il existe une commande courte, un document ou une vérification manuelle.
