CLI vs MCP pour les agents IA

La question de savoir si les agents IA devraient utiliser des CLI ou MCP pour interagir avec des services externes est une question avec des benchmarks publiés et sans réponse universelle. Les compromis dépendent de conditions spécifiques — familiarité avec l’outil, environnement hôte, budget de tokens et exigences de sécurité.

Ce que montrent les benchmarks

Mario Zechner a effectué 120 évaluations sur des tâches standardisées comparant les approches CLI et MCP. Les deux ont obtenu des taux de succès de 100%. MCP était 23% plus rapide et 2,5% moins cher.

L’avantage de vitesse, cependant, ne provenait pas d’une supériorité inhérente du protocole. Il provenait principalement du contournement de la détection de commandes malveillantes de Claude Code sur les invocations bash — une vérification de sécurité qui ajoute de la latence aux commandes CLI. Cette latence est intentionnelle, pas une surcharge à optimiser.

Un benchmark séparé d’automatisation de navigateur a trouvé que CLI obtenait 33% de mieux en efficacité des tokens et accomplissait des tâches que MCP ne pouvait structurellement pas réaliser. Les requêtes CLI avec champs filtrés consommaient 43 fois moins de tokens que les snapshots MCP équivalents.

Les résultats divergents indiquent que le bon choix dépend de l’outil et de la tâche spécifiques.

Là où CLI l’emporte

Efficacité des tokens. Les CLI n’ont pas de coût de schéma ambiant. Avec MCP, chaque serveur connecté charge ses définitions d’outils dans la fenêtre de contexte du modèle avant que la conversation ne commence. Une configuration MCP modérée — disons 5 serveurs avec 10-80 outils chacun — peut consommer des dizaines de milliers de tokens avant un seul message utilisateur. Cette surcharge est réelle et cumulative. Les outils CLI, en revanche, ne consomment des tokens que lorsqu’ils sont activement utilisés.

Familiarité avec les données d’entraînement. Les LLM ont été entraînés de manière extensive sur des commandes shell, de la documentation et des discussions Stack Overflow pour des outils comme bq, gcloud, git et curl. Ils connaissent ces interfaces couramment. Générer une commande bq query est une correspondance de patterns avec un corpus d’entraînement massif. Générer du JSON structuré pour un appel d’outil MCP s’appuie sur des données de fine-tuning plus limitées. L’asymétrie des données d’entraînement explique pourquoi le pattern génération de code plutôt qu’appel d’outils tend à surpasser l’appel d’outils pour les outils bien établis.

Composabilité Unix. Les commandes CLI peuvent être chaînées et composées dans des expressions uniques. Un agent peut écrire un pipeline shell qui interroge gws drive files list, filtre avec jq, extrait des IDs et les passe à une deuxième commande gws. Les appels d’outils MCP ne peuvent pas se composer de cette façon — chaque appel est un aller-retour séparé à travers le contexte du modèle.

Zéro surcharge d’implémentation. Pas de serveur à construire, déployer ou maintenir. L’outil est livré ; vous l’utilisez.

Là où MCP l’emporte

Schémas typés et validation. Les définitions d’outils MCP utilisent JSON Schema, qui fournit une validation avant qu’une requête n’atteigne l’API. Les entrées malformées sont détectées tôt. Les outils CLI ne valident généralement pas la structure d’entrée — l’erreur arrive de l’API après l’aller-retour, ce qui est plus lent et moins informatif.

Universalité client. Claude Desktop, VS Code Copilot, Cursor et les extensions IDE manquent souvent d’accès shell. MCP fonctionne dans tous. Les commandes CLI nécessitent un environnement compatible bash, que tous les hôtes d’agents ne fournissent pas.

Opérations avec état. Les connexions MCP sont des sessions qui peuvent conserver des tokens d’authentification, des pools de connexions et d’autres états à travers plusieurs appels d’outils. Les commandes CLI sont intrinsèquement sans état — chaque invocation repart de zéro.

Audit de sécurité. MCP fournit des permissions granulaires et des pistes d’audit au niveau du protocole. Vous pouvez spécifier exactement quels outils un client peut appeler, journaliser chaque invocation et révoquer l’accès par outil. Les permissions de commandes shell sont plus grossières — vous pouvez autoriser ou refuser Bash(gws *), mais pas Bash(gws drive files list) vs. Bash(gws drive files delete).

Le même outil, les deux surfaces

La réponse émergente à “CLI ou MCP ?” est de plus en plus “les deux, depuis le même binaire.” Le CLI gws l’illustre :

# CLI standard : l'agent écrit des commandes shell
gws drive files list --params '{"pageSize": 10, "fields": "files(id,name)"}'

# Serveur MCP : même API sous-jacente, outils structurés
gws mcp -s drive,gmail,calendar

Lorsqu’un outil offre les deux surfaces, vous pouvez laisser l’agent choisir selon le contexte. Pour l’exploration rapide et les pipelines composables, CLI. Pour les opérations où la validation typée est importante ou où l’hôte d’agent manque d’accès shell, MCP. Le choix se fait au niveau de la tâche, pas au niveau de l’outil.

Enregistrez les deux dans la configuration de Claude Code :

{
  "mcpServers": {
    "gws": {
      "command": "gws",
      "args": ["mcp", "-s", "drive,gmail,calendar"]
    }
  },
  "permissions": {
    "allow": [
      "Bash(gws *)"
    ]
  }
}

Avec cette configuration, l’agent a les deux chemins disponibles et peut choisir. Pour une simple requête “list my Drive files”, il écrira probablement une commande shell. Pour un workflow complexe multi-étapes impliquant des mutations où la validation dry-run est importante, il pourrait préférer les outils MCP.

Le cadre de décision pratique

Utilisez CLI quand :

L’outil a une représentation profonde dans les données d’entraînement (bq, gcloud, git, outils Unix standard, gws)
Vous avez besoin de la composabilité Unix — chaîner la sortie d’une commande à une autre
Vous opérez dans un environnement où l’accès shell est disponible
L’efficacité des tokens est plus importante que la validation typée

Utilisez MCP quand :

L’hôte d’agent manque d’accès shell (Claude Desktop, extensions IDE)
Vous avez besoin d’un audit de sécurité granulaire et d’un contrôle de permission par outil
L’API de l’outil n’a pas de représentation dans les données d’entraînement (API internes personnalisées, SaaS moins connus)
Les opérations avec état nécessitent des connexions persistantes à travers les appels

Utilisez les deux quand :

L’outil propose les deux surfaces (comme gws)
Votre workflow mélange des requêtes exploratoires (CLI-friendly) avec des opérations de mutation (MCP-friendly)
Vous voulez laisser l’agent choisir le chemin le plus efficace par tâche

Comme le résume Zechner : “The protocol is just plumbing. What matters is whether your tool helps or hinders the agent’s ability to complete tasks.” Pour des outils comme gws, les deux protocoles servent des parties différentes de l’espace de tâches.