MCP, CLI, API : comment choisir
Trois façons pour un agent d'accéder au monde extérieur, et un débat mal posé presque partout. Une grille de lecture honnête, exemples à l'appui.
D'abord, désempiler les niveaux
On oppose souvent MCP et CLI comme s'ils étaient deux options interchangeables. Ce sont en fait quatre niveaux d'abstraction au-dessus du même substrat : HTTP.
curl ou écrit un script Python avec httpx. Le LLM lit la doc OpenAPI et tape l'endpoint directement.
gh, glab, kubectl, aws. Pagination résolue, auth cachée, endpoints composites, output ergonomique. C'est là que la vraie valeur s'ajoute.
Ces quatre niveaux tapent le même backend HTTP. La question n'est pas « lequel est le bon », mais « où la complexité est déjà absorbée ? ».
Le même geste, trois façons
Tâche concrète : lister les issues GitHub ouvertes assignées à l'utilisateur. Voilà ce que ça donne, du plus brut au plus structuré.
même geste, coût en tokens à débit constant — environ 6× plus long pour MCP sur ce cas précis (mesure indicative, varie selon le client et le schéma)
Sur ce geste précis, la CLI hand-crafted l'emporte largement, parce que gh a déjà absorbé l'auth, la pagination et le formatage. Au passage, c'est aussi ce que le LLM connaît le mieux — il a vu gh des millions de fois dans son entraînement.
Les chiffres qui ont relancé le débat
Plusieurs benchmarks publiés début 2026 ont quantifié l'écart de manière brutale :
(Scalekit, 75 runs)
(MindStudio)
quand la complexité augmente
L'explication est plutôt mécanique, dans la majorité des implémentations actuelles : chaque tool MCP charge son schéma JSON dans le contexte du modèle, plus sa description, plus celle de ses arguments. Avec une dizaine de tools, on a déjà mangé plusieurs milliers de tokens avant même d'avoir commencé à travailler. À nuancer : le coût réel dépend fortement du client (Claude Desktop, Cursor, Continue…), du chargement lazy ou non des tools, de la taille des schémas et de la stratégie de tool selection. Certains clients commencent à filtrer dynamiquement les tools exposés au modèle, ce qui change la donne — l'overhead structurel reste cependant la règle aujourd'hui. Et chaque schéma supplémentaire élargit la surface de décision : le modèle hésite entre plus d'options, donc raisonne moins bien.
À l'inverse, une CLI mobilise des patterns que le modèle a vus des millions de fois pendant son entraînement (Stack Overflow, GitHub, docs). Le coût cognitif est quasi nul.
Là où MCP gagne vraiment
L'erreur du débat actuel, c'est de comparer MCP et CLI sur le terrain où CLI est de toute façon supérieure : dev local, mono-utilisateur, shell disponible. Mais MCP n'est pas un format alternatif à CLI, c'est un protocole pour des situations où CLI ne peut pas aller. Quatre cas structurels :
un seul serveur MCP, N clients hétérogènes — la CLI exigerait N installations
fork/exec local. Il faut un shell, un binaire installé, le bon OS. Dès que l'agent tourne dans un sandbox web, une app mobile, ou un service SaaS distant, la CLI n'existe plus.
Exemple : Claude Desktop, Cursor, Zed, Continue peuvent tous consommer le même serveur MCP sans installation locale. Avec CLI, chaque utilisateur de chaque éditeur doit installer chaque outil.
gh auth login résout l'auth du user de la machine. Pour un produit qui fait agir un agent on-behalf-of N utilisateurs distincts, chacun avec ses permissions, la CLI ne tient plus la route.
Exemple : un SaaS qui automatise des workflows GitHub pour 5000 clients. MCP standardise OAuth 2.1 + Dynamic Client Registration depuis 2025. Avec CLI, il faudrait provisionner 5000 contextes d'auth, non scalable.
cat, mais tu perds la sémantique « ceci est du contexte de référence, pas un résultat d'action ».
À noter : aucun de ces quatre points ne se règle en « standardisant » la CLI. C'est le modèle d'exécution qui diverge. Le seul moyen de faire une CLI remote, multi-tenant, bi-directionnelle, avec des Resources… c'est de réinventer MCP.
Le vrai critère de décision
Une seule question tranche presque tout, formulée par Scalekit dans leur benchmark :
L'agent agit pour qui ?
Le point d'inflexion, c'est quand l'agent arrête d'agir pour son utilisateur et commence à agir au nom d'autres personnes.
Automatiser son propre workflow → CLI. Un produit qui automatise des workflows pour des clients distincts, dans leurs organisations, avec leurs droits → MCP. Le surcoût en tokens est le prix d'admission de la gouvernance.
Le piège dans l'autre sens existe aussi : coller du MCP partout « parce que c'est le standard », y compris sur du dev local mono-utilisateur, c'est payer le surcoût sans bénéficier de la gouvernance. C'est ce qui produit la fatigue MCP qu'on lit en ce moment.
L'architecture qui gagne : hybride
Les équipes les plus matures en 2026 ne choisissent plus un camp. Elles utilisent :
- CLI pour 80% des tâches : tools que le modèle connaît déjà (
git,kubectl,jq,curl,ffmpeg…). - API directe pour les services sans CLI mais avec un bon OpenAPI — l'agent écrit son script de quelques lignes.
- MCP pour les 20% qui demandent vraiment auth déléguée, audit, ou bi-directionnalité.
Le fait que Google ait shippé en parallèle gws CLI et des serveurs MCP Workspace est le signal le plus clair : ce n'est pas une bataille, ce sont deux outils complémentaires pour deux périmètres différents.
Si tu dois décider demain
Trois questions, dans cet ordre
1 · L'agent agit pour qui ? Pour toi seul → CLI/API. Pour des tiers, avec leurs droits → MCP.
2 · Le tool existe-t-il déjà en CLI mature ? Si oui (git, gh, kubectl, aws, jq), prends-la. Tu réutilises ce que le modèle connaît déjà.
3 · Ai-je besoin de bi-directionnalité, OAuth délégué, Resources, ou cross-client ? Si oui sur l'un des quatre → MCP. Sinon, la CLI ou un script de quelques lignes coûteront moins en tokens et en debug.
Le défaut raisonnable d'un agent moderne : 80% de CLI/scripts, 20% de MCP là où la gouvernance ou le transport l'exigent. Tout MCP partout = fatigue cache + dilution du raisonnement. Tout CLI partout = on bute dès qu'on quitte le shell de l'opérateur.
D'où viennent les chiffres
-
4–32× tokens MCP vs CLI — Scalekit, benchmark publié début 2026 sur 75 runs comparatifs (gestion d'issues GitHub via
ghvs serveur MCP équivalent). Méthodologie publique, à consulter pour le détail (état d'auth, taille de schéma, modèle utilisé). - ~35× d'overhead sur tâches complexes — MindStudio, étude 2026 sur des workflows multi-étapes. Cas extrême, pas représentatif des gestes simples.
- 72% fiabilité MCP vs 100% CLI — même source Scalekit, mesuré sur les runs qui atteignent une condition de succès définie. Fiabilité ici = taux de complétion, pas qualité du résultat.
- Citation « too many MCP tools » — observation rapportée à plusieurs reprises dans les blogs Firecrawl et Nordic APIs en 2026, recoupée par les retours communautaires sur les implémentations MCP les plus chargées.
- OAuth 2.1 + Dynamic Client Registration dans MCP — ajouté à la spec MCP en 2025. Voir la spec officielle pour la liste des grant types supportés.
Chiffres à prendre comme ordres de grandeur, pas comme constantes physiques. Les écarts dépendent fortement du client MCP utilisé, du chargement lazy ou non des schémas, et de la maturité de la CLI comparée. Un benchmark gh vs MCP-GitHub n'a pas la même tête qu'un benchmark sur une API obscure sans CLI dédiée.
CLI quand l'agent agit pour son utilisateur, MCP quand il agit pour quelqu'un d'autre, API directe quand il n'y a ni l'un ni l'autre. Un agent moderne sait jongler entre les trois.