Surcoût des outils MCP : 26 outils, $0.03 par appel

Connecter un serveur MCP à votre agent entraîne un coût à chaque appel, avant même la moindre action : les 26 outils du serveur GitHub coûtent $0.0302 pour chaque appel à Claude Opus 4.8, qu’un outil soit utilisé ou non. Ce mécanisme reste invisible tant qu’on ne consulte pas les métriques. Son coût dépend davantage du modèle utilisé que du nombre d’outils connectés, et il est possible d’en éviter l’essentiel. Nous avons mesuré toute la chaîne : cinq familles de modèles, cinq vrais serveurs MCP, des séries synthétiques allant de 0 à 40 outils, ainsi que les leviers de cache et d’allègement qui réduisent la facture.

TL;DR

• Les définitions d’outils sont refacturées comme tokens d’entrée à chaque appel API ; un petit outil représente 401 tokens sur Claude Opus 4.8.
• Le même ensemble d’outils consomme 2.7x plus de tokens sur Claude que sur GPT-5.6 (173 contre 64 par outil dans nos mesures).
• Le vrai serveur MCP GitHub (26 outils) coûte $0.0302 par appel sur Opus 4.8, contre $0.0029 sur Gemini 3.6 Flash, soit un écart de 10x.
• La mise en cache explicite divise par dix le coût du bloc transporté. Les ensembles d’outils sous le seuil minimal ne peuvent toutefois pas être mis en cache, et la modification d’un seul outil entraîne la refacturation de tout le bloc.

Comment un serveur MCP se transforme-t-il en tokens d’entrée ?

Le processus comporte trois étapes. Seule la dernière est payante, mais elle se répète à chaque appel. Précisons d’abord le périmètre : les serveurs MCP exposent trois primitives, les outils, les ressources et les prompts. Seuls les outils entraînent un coût permanent, car l’API possède un paramètre tools qui doit contenir tous les schémas à chaque requête. Les ressources et les prompts n’ont pas de champ API dédié ; ils ne consomment des tokens que lorsque leur contenu est effectivement ajouté à la conversation. À l’étape 1, le client de l’agent interroge le serveur avec tools/list via JSON-RPC et récupère les schémas. Cette opération n’a lieu qu’une fois par session et ne sollicite aucun modèle. À l’étape 2, le client convertit ces schémas vers le paramètre tools de l’API et supprime les champs propres à MCP, comme annotations et outputSchema. Cette opération reste gratuite. À l’étape 3, le fournisseur transforme ces schémas en texte de prompt caché à chaque requête, car l’API est stateless et le modèle ne se souvient pas des outils disponibles. Ce texte est facturé au tarif d’entrée complet à chaque appel, que les outils soient utilisés ou non.

Voici la démonstration la plus simple : une requête dont le message utilisateur se limite à « Reply OK » consomme 11 tokens de prompt sur Opus 4.8. Ajoutez un outil get_weather assez simple, avec deux paramètres et une description d’une ligne, et la même requête passe à 412 tokens. Cet outil ajoute à lui seul 401 tokens, soit $0.002, à chaque appel qui le transporte. Le volume envoyé ne reflète pas le volume facturé : le JSON de l’outil ne représente qu’environ 130 tokens de texte, mais le rendu du fournisseur en consomme presque trois fois plus.

Combien coûte un outil sur chaque modèle ?

Le coût dépend bien plus du modèle que la plupart des équipes ne l’imaginent. Nous avons envoyé des ensembles d’outils synthétiques identiques, chacun avec trois paramètres et une description d’une ligne, selon une progression de 0 à 40 outils. Nous avons ensuite relevé les écarts facturés sur cinq familles :

À outils identiques, l’écart atteint 2.7x : Claude produit le format d’outils le plus verbeux du groupe, GPT-5.6 le plus compact. Le rapport avec le JSON envoyé varie lui aussi dans les deux sens : Claude facture environ 1.36x l’estimation naïve consistant à diviser par quatre la taille du payload en octets, tandis que GPT-5.6 et Gemini en facturent à peu près la moitié. Le nombre de tokens d’un bloc d’outils ne se transpose pas d’une famille à l’autre. Établissez donc le budget par modèle, et non par schéma.

Combien coûtent de vrais serveurs MCP par appel ?

Voici les résultats pour cinq serveurs réels et non modifiés du dépôt MCP officiel. Nous les avons convertis avec le mapping de champs standard, puis avons mesuré le surcoût transporté à chaque appel :

La dernière ligne illustre deux points. Sequential-thinking n’expose qu’un seul outil, mais coûte tout de même plus cher que les neuf outils de Memory sur quatre des cinq familles, car son unique description est énorme : le nombre d’outils n’est pas le bon indicateur, seule compte la taille après rendu. La première ligne réserve une autre surprise aux équipes qui développent des agents : transporter l’ensemble d’outils GitHub pendant un épisode de 10 appels coûte $0.30 sur Opus 4.8 et $0.03 sur Gemini, soit un rapport de dix, avant même le moindre travail utile. GLM 5.2 revient encore moins cher en dollars alors qu’il facture plus de deux fois le nombre de tokens de Gemini. Un tarif catalogue faible compense un rendu verbeux : budgétez donc séparément les tokens et les dollars.

Quelle part des outils les agents utilisent-ils réellement ?

Très peu à chaque appel, ce qui rend ce surcoût difficile à accepter. Dans le scénario d’outillage de notre suite d’agents, un ensemble de 8 outils accompagne les trois appels d’un épisode type, alors que chaque appel n’en invoque au maximum qu’un seul : les huit schémas sont facturés pour en utiliser un. Aux tarifs mesurés sur Opus 4.8, ce bloc de 8 outils représente environ 1,674 tokens par appel, soit près de 5,000 tokens par épisode uniquement pour transporter les schémas. Le scénario de boucle d’outils est le plus favorable : trois outils sont utilisés à presque chaque appel, mais le bloc est tout de même renvoyé lors des quatre à cinq appels de la boucle. Les relevés montrent une règle générale : un appel utilise rarement plus d’un outil. Le coût par appel dépend donc de ce que vous avez connecté, pas de ce que l’agent fait.

Le cache peut-il absorber le surcoût des outils ?

Oui, en grande partie sur les modèles adaptés, mais nos mesures montrent trois limites nettes. Sur Claude Opus 4.8, le bloc d’outils constitue un préfixe directement éligible au cache : en marquant le dernier outil avec cache_control, notre bloc de 20 outils a été écrit une fois (3,682 tokens avec la majoration d’écriture de 1.25x), puis relu à 0.1x lors de chaque appel suivant. Le coût effectif du transport baisse ainsi de 90 %. Le cache automatique de Kimi K3 a fait encore mieux sans aucune configuration : au deuxième appel, 2,048 des 2,112 tokens du bloc, soit 97 %, provenaient du cache, avec les habituels blocs de 256 tokens. Pour les points de rupture explicites de GPT-5.6, nos mesures du premier jour montrent la même tarification : écritures à 1.25x et lectures à 0.1x. Le cache implicite de Gemini, conformément à tout ce que nous avons déjà mesuré à son sujet, n’a produit aucun hit lors de trois tests préparés sur le bloc d’outils. Considérez toute réduction obtenue dans ce cas comme un bonus, pas comme une hypothèse de calcul.

Première limite : le seuil minimal. Un bloc de 2 outils représente environ 655 tokens sur Claude, sous le minimum de 1,024 tokens requis pour le cache. Les petits ensembles d’outils ne peuvent donc pas être mis en cache, même avec un marquage explicite ; les seuils propres à chaque modèle déterminent si ce levier est disponible. Deuxième limite : la volatilité. Le bloc d’outils se trouve tout en haut du prompt. Modifier la liste invalide donc tout ce qui le suit. Nous avons mesuré directement la pénalité : l’ajout d’un outil à un ensemble en cache de 20 outils sur Claude Opus 5 a réécrit l’intégralité du bloc de 4,082 tokens au tarif majoré d’écriture. Figez la liste d’outils pendant la session, sous peine de payer cette réécriture à chaque modification. Troisième limite : la fonctionnalité bêta d’Anthropic permettant de modifier les outils en cours de conversation, documentée pour Opus 5, vise précisément à lever cette contrainte. Elle autorise les changements d’outils entre les tours sans invalider le cache. C’est la fonctionnalité à surveiller pour les agents qui utilisent beaucoup d’outils.

Comment réduire le bloc d’outils lui-même ?

Réduisez d’abord les paramètres, avant de raccourcir le texte. Sur notre bloc de 20 outils, ramener les descriptions à une seule proposition concise a économisé 10 %. Réduire chaque outil de trois paramètres à un seul a économisé 34 %. Les deux optimisations combinées ont économisé 44 %, avec une baisse de 3,768 à 2,128 tokens. L’essentiel des tokens se trouve dans les schémas de paramètres, notamment les noms, les types et les descriptions imbriquées. Il faut donc aller à l’encontre du réflexe habituel qui consiste à soigner les descriptions tout en laissant les schémas grossir.

Le levier le plus efficace reste de ne pas connecter ce que vous n’utiliserez pas. Chaque serveur MCP ajouté transporte son bloc complet à chaque appel ; une deuxième ligne de configuration peut doubler le surcoût. Lorsque le client permet de filtrer les outils, n’enregistrer qu’une partie de ceux d’un serveur réduit le coût à peu près proportionnellement. En ne conservant que cinq des 26 outils du serveur GitHub, les $0.0302 d’Opus 4.8 tombent à environ $0.007, sur la base de la taille moyenne des outils de ce serveur. Si vous utilisez des modèles de plusieurs familles, gardez aussi en tête l’écart de 2.7x mesuré plus haut : déplacer le même agent de Gemini vers Claude sans revoir le budget multiplie presque par trois le nombre de tokens nécessaires au transport des outils.

FAQ

MCP entraîne-t-il lui-même un coût en tokens ?

Non. Le protocole MCP, la découverte, JSON-RPC et la mécanique d’invocation des outils ne sollicitent jamais le modèle et ne sont pas facturés. Le coût apparaît lorsque le client transmet les schémas du serveur dans le paramètre tools de l’API. Le fournisseur les transforme alors en texte de prompt facturé à chaque appel. MCP amplifie surtout le phénomène : une seule ligne suffit pour connecter 26 outils, puis les 26 schémas accompagnent tous les appels suivants.

Les outils inutilisés ont-ils un coût ?

Oui, exactement le même que les outils utilisés. Le modèle doit lire tous les schémas à chaque appel pour savoir ce qu’il peut invoquer. Les relevés de notre suite d’agents montrent qu’au maximum un outil est invoqué par appel, alors que l’ensemble complet est facturé à chaque fois. Un serveur connecté mais inactif ne génère qu’un coût de transport. Le cache peut le réduire, mais seuls l’allègement ou la déconnexion peuvent le supprimer.

Les ressources et les prompts MCP consomment-ils des tokens comme les outils ?

Non. Seuls les outils entraînent un coût de transport à chaque appel, car le paramètre tools renvoie tous les schémas à chaque requête. Une ressource n’est facturée que lorsque le client la lit et insère son contenu dans la conversation. Elle devient alors une entrée ordinaire, facturée comme n’importe quel document récupéré. La même discipline de structuration s’applique : le contenu volatil des ressources doit être placé après les points de rupture du cache. De même, les templates de prompts ne sont facturés que lorsqu’ils sont invoqués, sous la forme du texte produit. Les ressources et prompts inutilisés d’un serveur connecté ne coûtent rien. Lorsqu’une intégration MCP apparaît sur la facture, ce sont donc les outils qu’il faut auditer.

La modification de la liste d’outils invalide-t-elle le prompt cache ?

Oui, entièrement. Le bloc d’outils est placé en tête du prompt. Toute modification le réécrit, ainsi que tout ce qui est mis en cache après lui. Lors de nos mesures, l’ajout d’un seul outil a entraîné la refacturation d’un bloc de 4,082 tokens avec une majoration de 1.25x. Figez la liste d’outils pour chaque session, regroupez ses modifications et surveillez la fonctionnalité bêta d’Anthropic permettant de modifier les outils en cours de conversation. Elle vise précisément à supprimer cette pénalité sur Opus 5.

Mesures réalisées le 2026-07-31 via la gateway Synthorai : séries synthétiques de 0 à 40 outils (n=2) et ensembles d’outils de cinq vrais serveurs MCP, avec des schémas récupérés en direct depuis les serveurs officiels via JSON-RPC tools/list, sur cinq familles de modèles ; tests de cache avec préfixes salés et ventilation du cache par appel ; utilisation des agents issue des relevés de la suite à l’origine de nos études sur le coût des agents. Les multiplicateurs de cache de GPT-5.6 proviennent des mesures publiées le premier jour dans notre analyse des coûts. Les montants en dollars correspondent aux écarts de coût facturé relevés dans les métriques de la gateway, sur la base des tarifs catalogue d’entrée. Les tarifs et le comportement du rendu peuvent évoluer ; vérifiez-les dans vos propres relevés d’utilisation.

← Retour au blog