←écrits

Architecture· Mai 2026, revu en octobre 2026· Lecture · 7 min

MCP, CLI, API : décrypter le débat

Trois façons pour un agent d'accéder au monde extérieur. Le débat est souvent mal posé ; ce mémo le reprend avec des exemples et des chiffres sourcés.

01 · Les niveaux

D'abord, séparer les niveaux

On oppose souvent MCP et CLI comme deux options interchangeables. Ce sont plutôt quatre niveaux d'abstraction au-dessus du même socle, HTTP.

API REST brute bas niveau

L'agent fait curl ou écrit un script Python avec httpx. Le LLM lit la doc OpenAPI et tape l'endpoint directement.

CLI auto-générée bas niveau

Outils type Kiota ou openapi-generator. Mapping 1:1 avec l'API. Gain syntaxique seulement, rarement utile pour un agent.

CLI hand-crafted moyen niveau

gh, glab, kubectl, aws. Pagination résolue, auth cachée, endpoints composites, output ergonomique. C'est à ce niveau que l'outil apporte le plus.

MCP haut niveau

Protocole JSON-RPC standardisé, schémas typés, OAuth 2.1, discovery, primitives Resources et Prompts en plus des Tools.

Les quatre niveaux appellent le même backend HTTP. La bonne question est de savoir où la complexité est déjà absorbée.

02 · Le même geste, trois façons

Le même geste, trois façons

La tâche : lister les issues ouvertes qui me sont assignées sur un repo GitHub, du plus brut au plus structuré.

API brute · curl ≈ 180 tokens

# L'agent gère l'auth, l'URL, le parsing, la pagination, et filtre les PR que /issues renvoie aussi
curl -H "Authorization: Bearer $TOKEN" \
     "https://api.github.com/repos/acme/app/issues?state=open&assignee=cyril" \
  | jq '.[] | select(.pull_request | not) | {number, title}'

CLI hand-crafted · gh ≈ 60 tokens

# Auth résolue, repo courant détecté, 30 résultats par défaut (-L pour plus)
gh issue list --assignee @me --state open \
  --json number,title

MCP · tool call ≈ 350 tokens (schéma inclus)

// Le schéma du tool est chargé en contexte avant l'appel
{
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": { "owner": "acme", "repo": "app",
                   "query": "open issues assigned to me" }
  }
}

même geste · tailles estimées à la main, schéma inclus pour MCP ; l'écart dépend du client et du chargement des schémas

Sur ce geste, la CLI l'emporte nettement parce que gh a déjà absorbé l'auth, la pagination et le formatage. C'est aussi l'outil que le modèle a le plus vu pendant son entraînement.

03 · Les chiffres

Les chiffres qui ont relancé le débat

Le benchmark le plus cité, publié par Scalekit le 11 mars 2026, compare gh au serveur MCP GitHub officiel, avec un agent qui charge tous les schémas d'office.

4–32×

Tokens consommés par MCP vs CLI
(75 runs, Claude Sonnet 4)

Tools du serveur GitHub dans la config testée
(schémas en contexte avant la 1^re requête)

72%

Fiabilité MCP vs 100% CLI
(échecs surtout liés à des timeouts)

Le mécanisme est simple. Un client qui charge tout d'office met dans le contexte le schéma JSON de chaque tool, sa description et celle de ses arguments. Dans la config testée par Scalekit, le serveur GitHub en exposait 43, et une simple question sur un repo embarquait aussi les schémas des pull requests, des notifications ou des actions. Le catalogue complet compte aujourd'hui près d'une centaine d'outils, regroupés en toolsets qu'on active ou non. Avec une dizaine de tools, on consomme déjà plusieurs milliers de tokens avant d'avoir commencé à travailler. Chaque schéma de plus élargit aussi le choix du modèle, qui raisonne moins bien.

Depuis, le terrain a bougé. Claude Code active par défaut la recherche d'outils : au démarrage, seuls les noms des tools et les instructions des serveurs entrent dans le contexte, et les schémas arrivent à la demande. Anthropic pousse aussi l'exécution de code contre MCP, où l'agent écrit un script qui appelle les tools au lieu de les invoquer un par un (environ 150 000 tokens ramenés à 2 000 sur son exemple). Les chiffres de Scalekit décrivent donc surtout les clients sans chargement différé.

Anthropic chiffre l'effet sur ses propres modèles : remplacer le chargement de tous les schémas par une recherche d'outils à la demande fait passer Opus 4.5 de 79,5 % à 88,1 % de précision sur ses évaluations MCP.

À l'inverse, une CLI s'appuie sur des usages que le modèle a vus très souvent pendant son entraînement (Stack Overflow, GitHub, docs), et ne coûte presque rien à décrire.

04 · Là où MCP gagne

Là où MCP gagne vraiment

Comparer MCP et CLI en dev local, mono-utilisateur, avec un shell sous la main, c'est se placer là où la CLI gagne de toute façon. MCP sert surtout là où une CLI ne peut pas aller. Quatre cas :

un seul serveur MCP, N clients hétérogènes · la CLI exigerait N installations

Transport remote, cross-client

Une CLI, c'est 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.

OAuth multi-tenant déléguée

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 5 000 clients. MCP standardise OAuth 2.1 depuis 2025, et l'enregistrement des clients passe désormais par les Client ID Metadata Documents (le Dynamic Client Registration est déprécié depuis la spec 2026-07-28). Avec une CLI, il faudrait gérer 5 000 contextes d'auth.

Notifications et questions en cours d'appel

Une CLI fonctionne en requête → réponse, sur un cycle court. Un serveur MCP peut remonter des notifications de progression pendant un appel, et l'elicitation lui permet de demander une précision à l'utilisateur en cours de route (depuis la spec 2026-07-28, par des requêtes en plusieurs allers-retours). Le sampling, où le serveur demandait au LLM de générer, est déprécié dans la même version. Exemple : un agent de migration de base de données qui remonte sa progression toutes les 30 secondes, ou qui demande confirmation avant une étape destructive.

Primitives Resources & Prompts

Une CLI n'a qu'une primitive, la commande. MCP en a trois : les tools, les resources (du contenu exposé comme contexte, pas comme résultat d'appel) et les prompts (des templates paramétrés proposés à l'utilisateur dans le client). Exemple : un serveur MCP de documentation peut exposer chaque page comme une resource attachable au contexte. Avec une CLI, on peut faire cat, mais on perd la sémantique « ceci est du contexte de référence, pas un résultat d'action ».

Aucun de ces quatre points ne se règle en standardisant la CLI, parce que c'est le modèle d'exécution qui diverge. Une CLI distante, multi-tenant, avec notifications et resources, finirait par réinventer MCP.

05 · Le critère

La question qui tranche

Scalekit la pose dans son benchmark, et elle règle presque tout.

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 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 profiter de la gouvernance. De là vient la lassitude envers MCP qu'on lit souvent.

En pratique, un mélange

Je ne choisis pas un camp. Mon découpage :

La CLI pour la plupart des tâches, avec les outils que le modèle connaît déjà (git, kubectl, jq, curl, ffmpeg…).
L'API directe pour les services sans CLI mais avec un bon OpenAPI, où l'agent écrit un script de quelques lignes.
MCP quand il faut de l'auth déléguée, de l'audit, des notifications ou un accès depuis plusieurs clients.

Google illustre bien ce partage. Sa CLI Workspace pour agents, gws (mars 2026), a embarqué un serveur MCP pendant quelques jours avant de le retirer en version 0.8.0. En mai 2026, Google a ouvert en preview un serveur MCP Workspace distinct. On a donc deux produits séparés, la CLI sur le poste et MCP côté service distant.

À retenir

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 notifications, d'OAuth délégué, de resources ou de plusieurs clients ? 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.

Par défaut, CLI et scripts pour l'essentiel, MCP là où la gouvernance ou le transport l'exigent. Tout en MCP sature le contexte, surtout sans chargement différé. Tout en CLI bloque dès qu'on quitte le shell de l'opérateur.

Notes & sources

D'où viennent les chiffres

4–32× tokens, 43 tools, 72 % de fiabilité : benchmark Scalekit, 11 mars 2026. 75 runs annoncés, gh contre le serveur MCP GitHub Copilot officiel (43 tools dans la config testée), Claude Sonnet 4, sans chargement différé des schémas. Les échecs MCP (7 sur 25) sont des timeouts TCP vers le serveur, un problème d'exploitation plus que de protocole. Le dépôt public (scalekit-inc/mcp-vs-cli-benchmark) ne reproduit pas exactement le billet : son README annonce un seul run et 100 % de complétion des deux côtés, mais les médianes de son rapport redonnent bien 4 à 32×.
Le « 35× » qui circule : un test isolé de Jannik Reinhard (Microsoft Graph MCP contre les CLI mgc et az sur des appareils Intune, environ 145 000 contre 4 150 tokens), repris par Firecrawl puis par MindStudio, qui l'a mélangé avec le 72 % de Scalekit. Un seul cas, donc absent des stats.
79,5 % → 88,1 % (Opus 4.5) : Anthropic, Advanced tool use, 24 nov. 2025. Effet du Tool Search (chargement des schémas à la demande) contre le chargement complet, mesuré sur les évaluations MCP internes d'Anthropic.
Exécution de code contre MCP : Anthropic, Code execution with MCP, 4 nov. 2025. Recherche d'outils par défaut : doc MCP de Claude Code.
gws : CLI Google Workspace orientée agents (Rust, non supportée officiellement par Google), sortie début mars 2026. Sa commande mcp a disparu en v0.8.0 (CHANGELOG). Le serveur MCP Workspace de Google est un produit séparé, en preview développeur depuis mai 2026.
Spec MCP : OAuth 2.1 depuis 2025. La version 2025-11-25 recommande les Client ID Metadata Documents. La version 2026-07-28 rend le protocole sans état (plus de handshake initialize ni de session) et déprécie le Dynamic Client Registration, ainsi que Sampling, Roots et Logging.

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.

Mémo

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.