MCP est mort. Vive le CLI

• Le MCP perd rapidement l’attention du secteur, et une approche fondée sur le CLI est désormais plus pratique
• Les LLM sont déjà très à l’aise avec les outils en ligne de commande, et peuvent travailler efficacement avec la documentation et le CLI seuls, sans protocole supplémentaire
• Le CLI permet aux humains comme aux LLM d’exécuter et de déboguer dans le même environnement, ce qui simplifie l’identification de la cause des problèmes
• En matière de composabilité, de mécanismes d’authentification et de stabilité, le CLI est plus efficace que le MCP et plus facile à maintenir
• En pratique, le MCP crée des frictions continues : initialisation instable, réauthentifications répétées et absence de contrôle des autorisations
• Dans la plupart des cas, le CLI est l’option la plus simple et la plus fiable, et les entreprises devraient prioritairement se concentrer sur la fourniture d’API et de CLI plutôt que de serveurs MCP

---

Les limites du MCP et la supériorité du CLI

• Depuis l’annonce du Model Context Protocol (MCP) par Anthropic, le secteur s’est empressé de construire des serveurs MCP, mais des outils majeurs comme OpenClaw et Pi ne le prennent pas en charge, et les bénéfices concrets sont inexistants
  • Les LLM peuvent déjà accomplir ces tâches via le CLI et la documentation
  • Le MCP ajoute de nouveaux endpoints et un nouveau système d’authentification, tout en dupliquant des fonctionnalités existantes
• Les LLM sont optimisés pour l’usage des outils CLI et s’en sortent très bien
  • Ils ont appris à partir de millions de pages de manuel, de réponses Stack Overflow et de scripts shell GitHub
  • Par exemple, si l’on demande à Claude d’exécuter une commande comme gh pr view 123, il le fait tel quel
• Le MCP promettait une interface plus propre, mais en pratique il faut documenter de la même manière la description de chaque outil, ses paramètres et les moments où l’utiliser

Le CLI est aussi utile aux humains

• Le CLI permet aux humains et aux LLM de partager les mêmes commandes
• Si Jira a un comportement inattendu, on peut reproduire directement le problème avec la même commande jira issue view
• Avec le MCP, les outils n’existent qu’à l’intérieur de la conversation avec le LLM, ce qui oblige à fouiller les logs d’envoi JSON quand un problème survient
• Le débogage ne devrait pas nécessiter de décodeur de protocole
• Avec le CLI, les entrées et sorties sont explicites, ce qui facilite le diagnostic

Composabilité

• Le CLI peut être combiné en pipeline avec jq, grep, les redirections de fichiers, etc.
• Exemple d’analyse d’un plan Terraform à grande échelle :
  • terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
• Avec le MCP, il faut soit déverser l’intégralité du plan dans la fenêtre de contexte (coûteux et souvent impossible), soit implémenter un filtrage personnalisé dans le serveur MCP lui-même
• L’approche CLI s’appuie sur des outils déjà existants, bien documentés, et compréhensibles à la fois par les humains et les agents

Le problème de l’authentification

• Le MCP est inutilement prescriptif sur l’authentification
• Les outils CLI utilisent déjà des schémas d’authentification éprouvés : aws avec les profils et le SSO, gh avec gh auth login, kubectl avec kubeconfig
• Que l’outil soit utilisé directement par un humain ou piloté par Claude, le même flux d’authentification s’applique
• En cas de problème d’authentification, on peut le résoudre avec les méthodes existantes comme aws sso login ou gh auth refresh, sans dépannage spécifique au MCP

Problèmes opérationnels : aucune pièce mobile (No Moving Parts)

• Un serveur MCP local nécessite de démarrer et maintenir un processus distinct, et dans Claude Code il est créé comme processus enfant, ce qui pose parfois problème
• Un outil CLI n’est qu’un binaire sur disque : pas de processus en arrière-plan, pas de gestion d’état, pas de procédure d’initialisation

Les désagréments en pratique

• Initialisation instable : il arrive fréquemment que le serveur MCP ne démarre pas, obligeant à redémarrer Claude Code puis à réessayer après réinitialisation de l’état
• Réauthentifications répétées : avec plusieurs outils MCP, il faut s’authentifier séparément à chacun, contrairement aux CLI qui utilisent un SSO ou des identifiants de longue durée
• Contrôle des autorisations rudimentaire : dans Claude Code, on peut autoriser les outils MCP par nom, mais pas imposer un mode lecture seule ni limiter les plages de paramètres
  • Avec le CLI, on peut autoriser gh pr view mais exiger une approbation pour gh pr merge, ce qui permet un contrôle fin des autorisations

Quand le MCP est pertinent

• Le MCP peut convenir lorsqu’aucun outil CLI équivalent n’existe
• On peut reconnaître sa valeur comme interface standardisée, ainsi que la possibilité qu’il existe des cas d’usage où le MCP est plus adapté que le CLI
• Mais pour la plupart des tâches, le CLI reste plus simple, plus rapide à déboguer et plus fiable

Leçon essentielle et message aux builders

• Les meilleurs outils sont ceux qui fonctionnent à la fois pour les humains et pour les machines, et le CLI, après des décennies d’itérations, est composable, facile à déboguer et intégré aux systèmes d’authentification existants
• Le MCP cherchait à créer une meilleure abstraction, mais une abstraction déjà suffisamment bonne existait déjà
• Les entreprises qui investissent dans des serveurs MCP sans proposer de CLI officielle devraient revoir leur stratégie :
  bonne API → bon CLI, et les agents sauront les exploiter d’eux-mêmes
• Cela permet de réduire une complexité protocolaire inutile et d’améliorer la productivité comme la maintenabilité