Des chiffres de benchmark réels pour MCP ou CLI dans les agents IA : 1 365 tokens contre 44 026 pour la même tâche GitHub, et un test Playwright où l’écart a presque disparu. Découvrez où partent les tokens, quand MCP vaut son surcoût et comment réduire la facture sans abandonner les outils dont vous avez besoin.
Votre agent n’a pas encore écrit le moindre mot de sa réponse, et il a déjà consommé des milliers de tokens. C’est le véritable enjeu derrière MCP ou CLI pour les agents IA : il ne s’agit pas de savoir quel protocole est le plus propre, mais lequel laisse le plus de place dans la fenêtre de contexte pour le travail réel. Un benchmark a mesuré 1 365 tokens pour une recherche GitHub passée par la ligne de commande, et 44 026 pour la même recherche passée par MCP. Un autre, construit autour de Playwright, n’a relevé presque aucun écart. Les deux résultats sont réels, et la différence entre eux en dit plus que chacun des chiffres pris isolément. Vous verrez ci-dessous où partent les tokens, ce que montrent les mesures, quand MCP reste justifié et comment choisir sans deviner.
Les deux approches donnent des mains au modèle. Elles diffèrent par la manière dont le modèle découvre ce que ces mains savent faire, et par le moment où il paie pour cette connaissance.
Le Model Context Protocol est un standard JSON-RPC. Au démarrage d’une session, le client demande à chaque serveur connecté quels outils il propose. Chaque outil arrive sous la forme d’un nom, d’une description et d’un schéma d’entrée, et l’ensemble reste dans le contexte du modèle pour qu’il puisse décider quoi appeler. Chaque appel et chaque résultat circulent ensuite au format JSON structuré.
L’avantage est réel : entrées typées, authentification gérée côté serveur, et outils qu’un client compatible peut découvrir seul. L’inconvénient est que le catalogue entier est payé d’avance, que la tâche en nécessite un seul ou aucun.
Avec l’approche CLI, l’agent écrit une commande shell, l’environnement d’exécution la lance, et la sortie standard revient sous forme de texte brut. Il n’y a ni catalogue ni poignée de main. Le modèle connaît déjà git, grep, curl et jq grâce à ses données d’entraînement, et s’il oublie une option, il exécute --help et lit une page courte.
Le coût n’apparaît que pour les commandes effectivement utilisées. Cette seule différence de conception explique l’essentiel de ce qui suit.
💡 Définition rapide : un token est un morceau de texte que le modèle lit ou écrit. Les définitions d’outils, les commandes et les résultats occupent tous la fenêtre de contexte, et tous comptent comme entrée au tour suivant.
Le coût en tokens d’une boucle d’agent provient de trois sources : ce qu’on indique au modèle sur ses outils, ce qu’il envoie, et ce qui revient. MCP et CLI diffèrent surtout sur la première et la troisième.
Un serveur MCP typique injecte la définition de chaque outil dans la conversation avant même que la première question ne soit posée. Le serveur officiel de GitHub expose 43 outils, selon le benchmark de Scalekit, si bien qu’une requête anodine transporte 43 schémas. Checkly a mesuré à lui seul les définitions du serveur Playwright à 5,9k tokens. Anthropic formule le problème sans détour dans son article technique sur l’exécution de code avec MCP : les définitions d’outils saturent la fenêtre de contexte.
Le deuxième coût est plus facile à manquer. Avec les appels MCP par défaut, chaque résultat intermédiaire passe par le modèle. L’exemple d’Anthropic est une transcription de réunion récupérée depuis un service puis écrite dans un autre : le texte traverse le contexte deux fois, ce qui peut ajouter plus de 50 000 tokens pour un long enregistrement. Un pipeline shell peut filtrer, compter ou tronquer ces données avant que le modèle ne les voie.
| Source de coût | MCP, configuration par défaut | CLI |
|---|---|---|
| Catalogue d’outils | Toutes les définitions chargées au démarrage de la session | Aucun, --help à la demande |
| Format d’appel | Enveloppe JSON avec nom et arguments | Une seule chaîne shell |
| Résultats | Réponse complète renvoyée au modèle | Redirigés, filtrés ou écrits dans un fichier |
| Recherche d’outil | Le serveur déclare ses outils | Le modèle se souvient des commandes ou lit l’aide |
Deux tests publics donnent l’image la plus claire, et ils ne vont pas dans le même sens.
Scalekit a lancé cinq tâches GitHub en lecture seule avec Claude Sonnet 4, 25 exécutions par approche, contre le serveur MCP officiel de GitHub. Ils ont comparé le CLI simple, le CLI avec de courts fichiers d’instructions appelés skills, et MCP, soit 75 exécutions au total. Tokens par tâche :
| Tâche | CLI | CLI + skills | MCP | MCP par rapport au CLI |
|---|---|---|---|---|
| Langage et licence du dépôt | 1 365 | 4 724 | 44 026 | 32x |
| Détails et statut de revue d’une PR | 1 648 | 2 816 | 32 279 | 20x |
| Métadonnées du dépôt et installation | 9 386 | 12 210 | 82 835 | 9x |
| PR fusionnées par contributeur | 5 010 | 6 107 | 33 712 | 7x |
| Dernière version et dépendances | 8 750 | 6 860 | 37 402 | 4x |
En moyenne sur les cinq tâches, cela représente environ 5 200 tokens pour le CLI contre environ 46 000 pour MCP, soit à peu près 9x. L’estimation de Scalekit pour 10 000 opérations par mois donne environ 3,20 $ pour le CLI contre 55,20 $ pour MCP en direct, un écart de 17x. La fiabilité suit la même tendance : le CLI a terminé 25 exécutions sur 25, MCP 18 sur 25 (72 %), et les sept échecs étaient tous des délais d’expiration au niveau TCP.
Regardez aussi la colonne des skills. Sur la dernière tâche, la version avec skills a utilisé moins de tokens que le CLI simple (6 860 contre 8 750), probablement parce qu’un court fichier d’instructions a évité à l’agent quelques essais et erreurs. Sur les recherches simples, elle a coûté davantage, car les instructions se chargent à chaque fois.
⚠️ Les limites à connaître : un seul modèle, un seul service, des tâches en lecture seule. Les délais d’expiration sont des problèmes de connexion, pas des erreurs de raisonnement, donc l’écart de fiabilité en dit plus sur la configuration de ce serveur que sur le protocole lui-même.
Checkly a mené un test différent : ouvrir une boutique de démonstration, rechercher un produit, cliquer, ajouter des articles au panier et valider le contenu. La session MCP a utilisé de 48k à 50k tokens de contexte. La session CLI, avec les skills installés, en a utilisé de 45k à 48k. Après trois exécutions, la différence était négligeable, et l’explication est simple : le CLI Playwright et le serveur MCP partagent un même backend et écrivent les mêmes fichiers d’instantané sur le disque.
Checkly reconnaît aussi que les critiques envers MCP étaient justifiées en 2025. Deux facteurs en étaient la cause : les serveurs chargeaient toutes les définitions dès le départ, et chaque action renvoyait un instantané complet de la page directement dans la réponse. Les deux points ont depuis été atténués, car les environnements d’agents modernes reportent le chargement des outils MCP jusqu’à ce qu’ils soient nécessaires, et les serveurs peuvent enregistrer les instantanés sur le disque. L’avertissement de Checkly mérite d’être répété : les conseils sur l’IA ont une date de péremption mesurée en mois.
La leçon n’est pas que l’un des camps a eu tort. Le chiffre de 32x décrit une implémentation où chaque schéma est chargé. L’égalité presque parfaite décrit une autre implémentation qui évite ce surcoût. Le coût en tokens dépend de la manière dont un serveur est conçu, et non de l’étiquette du protocole.
Quand les deux options fonctionnent telles quelles, le CLI l’emporte le plus souvent. Deux raisons portent l’essentiel du poids.
Des décennies de scripts shell, de fichiers README et de réponses sur les forums figurent dans les données d’entraînement de chaque grand modèle. L’agent n’a pas besoin d’un schéma pour utiliser git log ou grep -r, et une commande d’une ligne remplace un appel JSON avec un nom, un objet d’arguments et une enveloppe autour. Quand il hésite, --help coûte une page courte, et non un catalogue complet au début de chaque session.
L’avantage le plus sous-estimé du CLI est la composition. Voici une façon de lister les titres des pull requests récemment fusionnées :
gh pr list --state merged --limit 10 --json title --jq '.[].title'
Le modèle ne voit que dix lignes de titres. Un appel MCP par défaut à un outil de pull request renvoie souvent la charge utile complète pour chaque élément : auteurs, étiquettes, URL, horodatages, état de revue. La plus grande partie est ignorée, mais tout est lu, et tout est facturé.
Une session CLI est aussi plus facile à déboguer. Vous pouvez coller la même commande dans votre propre terminal et voir exactement ce que l’agent a vu.
Le nombre brut de tokens n’est qu’un axe. Certaines tâches exigent ce que seul un protocole peut offrir.
Une commande shell s’exécute avec les droits de celui qui l’a lancée. C’est acceptable sur votre propre ordinateur portable, et problématique dans un produit où de nombreux utilisateurs connectent chacun leur compte. Un serveur MCP peut détenir des identifiants limités par utilisateur et n’exposer que les actions prévues, comme « lire les tickets » sans « supprimer le dépôt ». Il permet aussi aux clients qui ne sont pas des terminaux, des assistants de bureau aux panneaux d’IDE, de trouver des outils sans qu’il faille installer de binaire.
Les outils avec état favorisent MCP. Une session de navigateur qui doit tenir sur des dizaines de tours, ou une connexion à une base de données avec une transaction ouverte, est difficile à reconstruire à partir de commandes shell ponctuelles.
La génération de médias en est un bon exemple. Les modèles d’images et de vidéos fonctionnent comme des tâches asynchrones : vous soumettez une requête, obtenez un identifiant de tâche, puis interrogez jusqu’à ce que le résultat soit prêt. Le connecteur de PicassoIA enveloppe ce flux dans neuf outils au moment de la rédaction : génération d’images, édition d’images, deux générateurs de vidéos, consultation de statut, annulation, liste des tâches passées, liste des modèles et vérification du compte. Les outils de génération renvoient un identifiant de tâche accompagné d’un délai d’attente suggéré avant la prochaine interrogation, si bien que l’agent sait quand revenir vérifier au lieu de boucler à l’aveugle. Les modèles derrière ce connecteur incluent PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video et Seedance 2.5 Lite, avec jusqu’à cinq prédictions simultanées par compte.
Vous pouvez accéder aux mêmes modèles via l’API REST à https://api.picassoia.com/v1 avec un simple curl. Cela fonctionne bien, mais l’agent doit retenir le point de terminaison, joindre les identifiants et écrire sa propre boucle d’interrogation. Les outils MCP regroupent ces étapes. Remarquez aussi que la taille du catalogue compte : neuf petits outils pèsent bien moins que les 43 de GitHub, ce qui explique pourquoi un serveur léger pénalise moins qu’un serveur tentaculaire.
Si MCP est le bon choix, vous n’êtes pas obligé d’accepter la facture par défaut.
Anthropic appelle cela la divulgation progressive : laisser le modèle lire les définitions d’outils quand il en a besoin, au lieu de tout charger d’un coup. Deux formes fonctionnent. L’une est une organisation en fichiers où chaque outil est un petit fichier que l’agent ouvre à la demande. L’autre est une fonction de recherche qui trouve et charge uniquement les définitions pertinentes. Quel que soit le nom que donne votre environnement, vérifiez si le chargement différé est activé, et ne connectez que les serveurs dont le projet en cours a besoin.
Le mouvement le plus ambitieux d’Anthropic consiste à présenter les outils MCP comme du code que l’agent peut appeler depuis un bac à sable. L’agent écrit un court script, le script communique avec les serveurs, et seul un résumé revient au modèle. Dans leur exemple de Google Drive vers Salesforce, la consommation de tokens est passée de 150 000 à 2 000, soit une économie de 98,7 %.
Regardez ce que cela représente vraiment : un comportement de type CLI, où les données sont filtrées avant que le modèle ne les voie, superposé à l’authentification et aux interfaces typées de MCP. Les deux camps finissent par s’emprunter mutuellement leurs idées.
Gains rapides à appliquer dès aujourd’hui :
Sur le coût brut en tokens avec les réglages par défaut, le CLI l’emporte la plupart du temps, de 4x à 32x dans le benchmark le mieux documenté. Pour le contrôle d’accès, l’état à long terme et les services hébergés, MCP l’emporte. Et quand les outils MCP se chargent à la demande et que les gros résultats restent hors du contexte, l’écart peut se réduire à presque rien, comme l’a montré le test Playwright.
| Situation | Meilleur choix | Pourquoi |
|---|---|---|
| Travail local avec git, fichiers et builds | CLI | Commandes familières, sortie filtrée |
| Tâches courtes scriptées ou CI | CLI | Pas de poignée de main, empreinte réduite |
| Serveur avec plus de 40 outils en réglages par défaut | CLI ou exécution de code | Le surcoût des schémas domine |
| Nombreux utilisateurs, chacun avec ses comptes | MCP | Identifiants limités par utilisateur |
| Longues sessions de navigateur | MCP | L’état persiste entre les tours |
| Génération de médias asynchrone | MCP | Identifiants de tâche et indications d’interrogation |
Choisissez le CLI lorsque l’outil existe déjà sous forme de commande, que l’agent tourne sur une machine que vous contrôlez et que chaque token compte.
Choisissez MCP lorsque vous avez besoin de permissions par utilisateur, d’un état persistant ou d’un service hébergé sans bon outil en ligne de commande.
Combinez les deux en cas de doute. La plupart des configurations réelles le font : le shell pour le travail local, MCP pour quelques services hébergés, chacun réduit à ce que la tâche exige.
Vous pouvez tester ces compromis sur votre propre configuration avec Claude Sonnet 5, un modèle conçu pour le codage en plusieurs étapes et l’utilisation d’outils. Voici un flux d’audit rapide :
low désactive la réflexion et répond le plus vite, ce qui suffit pour un tri. Passez à high lorsque vous voulez des compromis raisonnés sur plusieurs serveurs.wc -c pour une estimation rapide de la taille, et utilisez les chiffres d’utilisation de votre fournisseur pour les comptes exacts de tokens.💡 Astuce : lancez le même audit avec Kimi K2.6 ou GPT 5.6 Sol et comparez les outils que chaque modèle supprimerait.
Chaque photo de cet article suit un schéma simple : un sujet clair, une source de lumière, un choix d’appareil et d’objectif. Essayez la même recette vous-même. Décrivez un établi à neuf heures du matin, un randonneur à une bifurcation ou votre propre version d’un bureau chargé d’outils, puis lancez-la avec PicassoIA Image. Affinez le résultat avec PicassoIA Image Editor Pro, et lorsqu’une image fixe mérite du mouvement, envoyez-la vers PicassoIA Video. Choisissez un prompt pour votre prochain projet et voyez ce qui en ressort.
Choisissez votre langue
