La taxe sur les tokens MCP réévaluée : deux descriptions d’outils ont provoqué cette augmentation.

Entre le 9 et le 22 septembre 2026, la somme des définitions de outils de neuf serveurs MCP populaires est passée de 36 320 à 38 738 tokens. Cela représente une augmentation de 2 418 tokens, soit 6,7 %, dont 2 094 tokens proviennent d’un seul serveur. Le nombre d’outils lui-même a à peine changé, passant de 108 à 109. Ce qui a augmenté, c’est la longueur du texte décrivant les outils déjà existants.

Les chiffres clés

Une nouvelle mesure effectuée treize jours après la première, avec un script identique, a donné les résultats suivants :

• Le bloc des outils de tous les neuf serveurs a augmenté de 2 418 tokens, soit une hausse de 6,7 %.
• firecrawl-mcp est passé de la version 3.24.0 à 3.25.2 et a conservé exactement 27 outils, tout en contribuant avec 2 094 tokens.
• Dans ce serveur, 2 225 tokens proviennent de définitions plus détaillées d’outils déjà présents. Deux outils ont été retirés et deux autres ajoutés, ce qui représente un changement net de moins 131. Le bilan est exactement équilibré : 892 ajoutés, 1 023 supprimés, 2 225 en augmentation.
• Deux outils sont responsables de presque toute cette augmentation. firecrawl_scrape et firecrawl_search expliquent 2 108 des 2 225 tokens, et seule la description de firecrawl_scrape est passée de 1 110 caractères à 4 458.
• Le coût est concentré : notion-mcp-server pèse 17 409 tokens (44,9 %) et firecrawl-mcp 11 088 (28,6 %). Ensemble, ils représentent 73,5 % du total, tandis que les sept autres serveurs se partagent les 26,5 % restants.
• Cinq serveurs n’ont publié aucune mise à jour pendant cette période, et ils ont été réexaminés pour obtenir des comptages identiques au niveau des octets. Ce résultat inchangé sert de contrôle, ce qui permet de considérer la différence comme fiable.

Pourquoi cette question est importante maintenant

Les critiques envers MCP se font entendre ces derniers temps, et l’une des principales plaintes est que les serveurs augmentent silencieusement le contexte que l’agent transporte. Une référence datant du 9 septembre existait déjà, couvrant neuf serveurs, 108 outils et 36 320 tokens, ce qui permettait de répéter la même étude le 22 septembre. La consommation actuelle est de 38 738 tokens, et presque toute cette augmentation provient d’un seul serveur dont le nombre d’outils est resté stable, mais dont les descriptions existantes se sont allongées. Telle est l’allégation des critiques, étayée par des chiffres et une méthode publiée.

Qu’est-ce que la taxe sur les tokens

La taxe sur les tokens correspond au budget de contexte consommé par les définitions d’outils avant même que l’utilisateur n’entre quoi que ce soit. Chaque serveur connecté répond à une requête tools/list, et cette réponse est intégrée dans le prompt du modèle. Pour les neuf serveurs populaires surveillés, le total s’élevait à 38 738 tokens le 22 septembre 2026, contre 36 320 le 9 septembre. Sur une fenêtre de 200 000 tokens, environ 19 % ont déjà été utilisés avant même le premier message, ce qui correspond à un ensemble d’outils que n’importe quel développeur pourrait facilement installer.

Snapshot pris le 22 septembre 2026 à 18:29 UTC : 9 serveurs, 109 outils et 38 738 tokens. Pour le reproduire, examinez chaque spécification de package npm, puis comptez les éléments nom, description et inputSchema avec le tokenizer o200k_base.

Comment fonctionne la mesure

Chaque serveur a été démarré via stdio à l’aide de npx. La procédure envoie d’abord « initialize », puis « tools/list », et stocke la réponse brute. Pour chaque outil, seuls les trois champs réellement reçus par l’API « a tool-use » sont conservés : le nom, la description et inputSchema. L’objet est normalisé avec des clés triées, les outils sont triés par nom, et le résultat serialisé est compté avec o200k_base. La version du 9 septembre précédent utilisait cette même définition stricte, et chaque serveur a été testé avec sa dernière version publiée le 22 septembre 2026.

Le serveur en cours d’exécution est sondé au lieu que son code source soit lu, et la différence est réelle. Plusieurs serveurs composent leur liste d’outils en temps de exécution, en cachant certains outils derrière un indicateur ou en générant une description à partir d’un modèle. L’array qui parvient à un modèle peut donc différer de celui présent dans le répertoire, et une lecture du code source fournirait un chiffre crédible que aucun modèle ne voit jamais. La sonde présente également ses propres limites : un serveur nécessitant des identifiants peut afficher à un client non authentifié une liste plus courte que celle qu’il montre à un utilisateur connecté. Tous les neuf ont cette fois renvoyé une liste complète, mais cette méthode ne peut pas l’exclure de manière générale.

Pourquoi une différence de treize jours est crédible

Cinq serveurs n’ont publié rien durant cette période, ce qui les sert de contrôle intégré. Il s’agissait du serveur de fichiers, du serveur de mémoire, du serveur exa-mcp, de tavily-mcp et du serveur de raisonnement séquentiel ; ils sont tous revenus exactement à leurs valeurs de référence : 1 668, 907, 415, 1 666 et 867 tokens respectivement. Pas près, mais exactement à ces valeurs. Une sonde ou un tokeniseur en dérive aurait modifié les cinq valeurs, donc toute l’augmentation de 2 418 provient des quatre serveurs qui ont libéré des données.

Le serveur responsable

firecrawl-mcp, avec trois mises à jour du 12 août au 22 septembre, est à l’origine de 2 094 tokens ajoutés. @playwright/mcp a contribué avec 324 tokens grâce à deux mises à jour ainsi qu’à un nouvel outil. Deux autres serveurs ont été déployés : @upstash/context7-mcp (deux mises à jour) et @notionhq/notion-mcp-server (une), et la taille de leurs blocs d’outils est restée exactement la même. Publier du code et modifier ce qui est transmis n’est pas la même chose, et ce dernier phénomène ne se produit que de temps en temps.

Plus performant, ou simplement plus lourd ?

En général, il s’agit simplement d’une augmentation de poids, facteur souvent ignoré dans la plupart des débats. firecrawl-mcp disposait de 27 outils avant et de 27 après. Il a simplement remplacé deux outils par deux autres, ce qui a entraîné une perte de 131 tokens. Les 2 225 tokens supplémentaires proviennent du fait que les outils existants ont obtenu des descriptions plus longues ainsi que des schémas d’entrée plus volumineux pour les mêmes fonctionnalités. Les utilisateurs ont donc dû payer 2 225 tokens de plus pour les mêmes vingt-cinq outils qu’ils possédaient déjà.

Les deux changements les plus importants méritent des chiffres précis : firecrawl_scrape a gagné 721 tokens de description et 462 tokens de schéma, tandis que firecrawl_search a gagné 691 tokens et 234 tokens. Au total, cela représente 2 108 tokens sur les 2 225. Sept autres outils n’ont connu qu’une variation de 117 tokens au total, et seize n’ont pas du tout changé. Il ne s’agit donc pas d’un écosystème en progression constante, mais plutôt de deux définitions d’outils réécrites en détail.

Le fait que cela soit considéré comme du gaspillage dépend d’un élément qui n’a pas été mesuré. Une description plus longue constitue souvent une réparation légitime : un outil que le modèle continuait d’utiliser de manière erronée est clarifié, et les jetons améliorent la fiabilité. Néanmoins, 4 458 caractères équivalent à peu près à une section entière de prose, associée à une fonction et transmise avec chaque requête. Le coût a été correctement mesuré. Les avantages restent inconnus.

Où vont réellement les jetons

Le schéma observé est celui de la concentration plutôt que de l’ampleur. Classés par part dans le total de 38 738 :

• Le serveur Notion prend de loin la tête avec 17 409 jetons, soit 44,9 % du total, répartis sur 24 outils.
• Firecrawl arrive en deuxième position avec 27 outils et 11 088 jetons (28,6 %).
• Playwright suit avec 3 734 jetons, soit 9,6 %, pour 25 outils.
• Le serveur de système de fichiers de référence utilise 1 668 tokens (4,3 %) pour 14 outils, tandis que Tavily en utilise 1 666 (également 4,3 %) pour seulement 5.
• Context7 consomme 984 tokens (2,5 %) pour 2 outils, le serveur de mémoire 907 tokens (2,3 %) pour 9 outils, et sequential-thinking 867 tokens (2,2 %) pour un seul outil.
• Exa est le plus léger, avec 415 tokens soit 1,1 %, pour 2 outils.

Le nombre d’outils ne permet pas de prédire correctement le coût. @playwright/mcp propose 25 outils pour 3 734 tokens, tandis que notion-mcp-server en propose 24 pour 17 409 tokens. Le nombre d’outils est presque identique, mais la facture est 4,7 fois plus élevée.

Pour ceux qui gèrent plus de deux ou trois serveurs, la question pertinente est de savoir quels d’entre eux ont une structure similaire à Notion.

La critique est-elle justifiée ?

Concernant cette affirmation, dans cet échantillon et dans ce cadre, oui, bien que le mécanisme soit plus restreint que ce que suggère généralement le débat. Les coûts augmentent, ils augmentent sans apport de nouvelles fonctionnalités, et ils se concentrent sur un petit nombre de serveurs au lieu d’être répartis dans l’écosystème. L’accusation récurrente selon laquelle le protocole MCP serait intrinsèquement surdimensionné ne correspond pas aux données. Ce que montrent les données, c’est que le texte produit par deux fournisseurs représente la majeure partie des coûts.

Limites des preuves

• Aucune tendance n’est visible. Deux valeurs séparées par treize jours ne forment qu’une différence, pas une trajectoire, et l’une d’elles est dominée par la mise à jour d’un seul fournisseur. Un mois calme donnerait un chiffre plat ou négatif, sans pour autant que le problème disparaisse.
• L’échantillon ne représente pas MCP dans son ensemble. Ces neuf serveurs ont été sélectionnés lors d’une étape précédente car ils sont largement installés et peuvent être explorés sans identifiants. Des milliers de serveurs existent, et personne ne dispose d’une liste fiable d’entre eux.
• Les agents réels ne sont pas modélisés. Personne ne se connecte précisément à ces neuf serveurs, donc le chiffre 38 738 décrit une configuration définie pour l’exercice et non une facture que quelqu’un paierait réellement. La partie reutilisable est la méthode, qui peut être exécutée sur n’importe quel ensemble personnel de serveurs.
• La valeur n’est pas mesurable. La description de firecrawl_scrape a quadruplé en longueur, mais pour savoir si le modèle l’appelle désormais correctement plus souvent, il faut un outil d’évaluation, ce qui constitue une expérience distincte.

Vérification de la première version du chiffre

La première tentative a utilisé une sérialisation naïve, en conservant l’objet outil dans son intégralité. Elle a donné 40 480 tokens pour le corpus du 9 septembre, contre 36 320 pour la version déjà publiée. Cette différence n’était pas due à un changement sur les serveurs ; elle provenait de champs supplémentaires que la méthode publiée omet délibérément.

En répétant l’opération avec la définition stricte archivée, on a obtenu 108 outils et 36 320 tokens par unité, d’où le résultat de contrôle mentionné précédemment. La comparaison de deux méthodes différentes produit un artefact et non une mesure réelle ; dans ce cas, l’artefact aurait gonflé la variation de 6,5 % dans une direction plus frappante.

La même prudence s’applique aux travaux antérieurs sur ce sujet. Un article précédent indiquait 38 900 tokens pour neuf serveurs MCP, mais ce chiffre provenait d’une exécution différente dont la méthode n’a pas été vérifiée à nouveau, ce qui fait qu’il ne constitue pas ici la valeur de référence. La valeur de 38 738 ne représente pas une baisse par rapport à 38 900. Le seul couple de valeurs qui puisse être soustrait honnêtement est 36 320 et 38 738, puisque un seul script a généré les deux.

Questions fréquentes

Qu’est-ce qui compte comme frais de tokens ? Tout ce que le client transmet au modèle au sujet des outils avant le début de toute conversation : en pratique, les informations relatives aux outils ou à la liste des outils de chaque serveur sont réduites au nom, à la description et au schéma d’entrée. Chaque requête au cours d’une session inclut ces informations, sauf si le client met en cache le préfixe, et ces frais sont facturés même si aucun outil n’est utilisé.

Le cache des prompts le rend-il gratuit ? Moins cher, mais pas gratuit, et uniquement tant que le préfixe ne change pas. En examinant 96 versions sur ces neuf serveurs, 48 % des transitions de version ont modifié le bloc d’outils qui ouvre un préfixe en cache. Des mises à jour fréquentes entraînent une invalidation fréquente du cache.

Pourquoi notion-mcp-server est-il si coûteux ? Ses 24 outils disposent de schémas d’entrée décrivant une grande surface API, et le bloc d’outils n’a pas été modifié depuis juillet. Il n’y a aucune évolution. Son coût est resté élevé dès le départ, ce qui constitue un problème distinct de ceux des serveurs bon marché mais très sollicités, et nécessite une réponse différente.

Les outils inutilisés peuvent-ils être désactivés ? Certains clients permettent de filtrer les outils d’un serveur, et avec ces chiffres, c’est l’option la plus efficace, car en retirant les deux serveurs les plus coûteux, on réduirait l’ensemble des serveurs de 73,5 %. Le niveau de support client varie, il est donc judicieux de vérifier cela avant d’installer un autre serveur.

6,7 % en moins de deux semaines, est-ce considéré comme élevé ? Si on projette cela sur une année, cela semble alarmant, mais se baser sur deux points de données uniquement est trompeur. Ce qui s’est passé, c’est qu’au cours d’une période de deux semaines, une seule mise à jour de fournisseur a ajouté 2 094 tokens à un ensemble de neuf serveurs, sans apporter de nouvelles fonctionnalités.

Une vérification à effectuer dès aujourd’hui

Ouvrez la configuration MCP de l’agent, comptez les serveurs et identifiez le plus grand d’entre eux. Les descriptions des outils ont-elles augmenté lors de sa dernière mise à jour, et ce changement aurait-il été remarqué ? Une question reste en suspens : combien de tokens un client envoie réellement lorsqu’il prétend filtrer les outils d’un serveur, un chiffre qui est ici supposé sans jamais être vérifié.