MCP est mort. Vive le CLI

 (ejholmes.github.io)
36 points par GN⁺ 2026-03-02 | 8 commentaires | Partager sur WhatsApp
  • 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é

À lire aussi

8 commentaires

 
sonnet 2026-03-03

Ce n’est pas que MCP n’a aucun avantage, c’est surtout qu’on s’est réveillés de l’illusion qui consistait à l’utiliser indistinctement même pour des usages où ses avantages n’apportent rien. Même lorsqu’on ouvre des microservices aux LLM, on n’utilise pas une CLI, et MCP reste un protocole d’« API ».
 
brainer 2026-03-03

À l’époque aussi, il suffisait d’utiliser une API. En réalité, si on utilisait MCP, c’était à cause des limites du long context, mais maintenant ces limites ont été en grande partie surmontées.
 
jamsya 2026-03-03

Je suis tout à fait d'accord.
Même sans installer aws mcp, Claude Code va chercher et utilise tout seul ce dont il a besoin via aws cli 😂
 
GN⁺ 2026-03-02
Réactions sur Hacker News

  • J’ai longtemps évité de le dire, mais je suis désormais convaincu que MCP n’apporte aucun avantage concret
    J’exploite des agents IA qui pilotent tout mon workflow de développement via des commandes shell, et ils comprennent très bien des flags CLI qu’ils voient pour la première fois rien qu’avec la sortie de --help
    À l’inverse, les serveurs MCP ont toujours été instables et demandaient de la maintenance
    La CLI est composable avec jq, grep, les redirections de fichiers, etc., alors que MCP reste enfermé dans le format renvoyé par le serveur
    Au final, j’ai l’impression que l’adoption de MCP relève davantage d’un signal marketing « AI-first » que d’une raison technique

    • MCP a connu une croissance fulgurante en 2024, mais c’est un cas où la dynamique a vite changé début 2025 avec l’arrivée des agents de terminal (Claude Code)
    • Moi, c’est l’inverse, je préfère MCP. La gestion des erreurs et le débogage y sont bien plus propres qu’avec une CLI, et on peut restreindre les flags dangereux ou découper les résultats avec de la pagination
      MCP peut simplement se comprendre comme un wrapper, au même titre que REST ou gRPC
    • Moi aussi j’évite MCP. J’ai essayé le MCP de JIRA et c’était catastrophique. À la place, laisser le LLM appeler directement l’API et écrire des scripts était bien plus efficace
      À ce stade, je pense que les outils CLI pour LLM sont ce qu’il y a de mieux
    • Dans notre entreprise, on expose via MCP des outils uniquement web, comme le wiki interne, pour permettre à Claude d’interroger directement les logs et les métriques
      En revanche, c’est gênant que les résultats MCP arrivent toujours dans la fenêtre de contexte. J’aimerais pouvoir les dumper vers le système de fichiers
    • Les serveurs MCP ressemblent à un artefact transitoire, conçu à une époque où les LLM étaient moins avancés. Je pense qu’il vaut bien mieux les entraîner sur des données de CLI

  • MCP ressemble à une API boîte noire qu’on peut appeler immédiatement sans installation ni provisioning de ressources
    À l’inverse, la CLI peut accéder à l’environnement local, donc elle offre beaucoup plus de précision
    Avec les CLI jq et duckdb, j’échantillonne de gros fichiers de données, et Opus 4.6 ajuste automatiquement les requêtes au fil de l’exploration
    La CLI est très réactive en temps réel, ce qui la rend particulièrement utile pour l’analyse exploratoire de données
    Parmi les CLI que j’utilise souvent, il y a showboat, br, psql et roborev

    • J’ai eu exactement la même expérience. Les entrées/sorties textuelles de la CLI correspondent le mieux à la façon dont les LLM sont entraînés
      J’ai pris beaucoup de plaisir à utiliser duckdb avec ChatGPT, et je me demande si tu configures le prompt système pour qu’il conserve une base locale
    • On peut éviter les problèmes d’installation en exécutant les commandes dans des conteneurs Docker plutôt que via la CLI locale. On pourrait même créer une « skill » pour automatiser cette approche
    • En tant que non-anglophone natif, je trouve amusant d’utiliser le pluriel comme dans MCPs

  • MCP a du sens lorsqu’il s’agit de découvrir des outils absents de la CLI et de les appeler selon le contexte
    Par exemple, echomindr, que j’ai créé, expose via MCP une base de données qui extrait des décisions de fondateurs depuis des podcasts
    Quand Claude reçoit une question liée aux startups, il cherche dans de vraies expériences de fondateurs pour répondre
    La CLI convient quand un humain sait déjà quel outil utiliser, tandis que MCP est adapté à une sélection d’outils par découverte

  • On dirait que l’auteur ne voit l’usage de l’IA qu’à travers le prisme des développeurs
    La plupart des utilisateurs se servent des LLM via des interfaces web comme ChatGPT
    Du point de vue des entreprises, MCP est bien plus adapté pour connecter des outils de marketing, de vente ou de gestion de projet

  • MCP en soi n’est pas mauvais, mais le stdio MCP est surconçu
    À la place, l’approche Streamable HTTP + OAuth Discovery est aujourd’hui la méthode la plus efficace pour les intégrations IA
    Par exemple, Sentry MCP permet l’authentification et l’accès aux données à partir d’une seule URL
    Le problème vient de la manière dont MCP est implémenté. Au lieu d’appeler du bash, exposer MCP comme un endpoint HTTP le rendrait bien plus flexible

    • Que ce soit pour la CLI ou MCP, le système d’autorisations devrait être conçu de façon cohérente au niveau de l’API. La partie Streamable HTTP mériterait un peu plus d’explications
    • Je suis du même avis. Une authentification centralisée et de la télémétrie sont bien plus simples. Il faut simplement l’utiliser pour les bons cas d’usage

  • Certains de mes clients n’ont pas de serveur MCP, mais les développeurs le demandent quand même
    Au final, on a exporté l’API Postman en JSON pour leur fournir quelque chose, mais les développeurs voulaient un serveur MCP
    Dans les faits, la prise en charge de MCP fonctionne comme une case à cocher marketing

  • Ce blog semble trop centré sur le point de vue des développeurs
    Quand il s’agit de se connecter à des outils ou services destinés aux non-développeurs, MCP est bien plus naturel

    • Exactement. Dans une interface de chat, on ne peut pas exécuter une CLI, et les services pour non-développeurs n’ont souvent pas de CLI du tout
    • Je me demandais justement s’il était seulement possible d’exécuter une CLI dans des interfaces web ou mobiles comme ChatGPT ou LeChat
    • Les interfaces pour non-développeurs évoluent déjà vers des formes comme OpenClaw ou Claude Cowork

  • Des offres d’emploi du genre « recherche profil avec 5 ans d’expérience en MCP » sont finalement devenues un mème dénué de sens

  • L’une des raisons pour lesquelles la CLI est meilleure que MCP, c’est qu’elle a un format optimisé du point de vue de la théorie de l’information
    La sortie des outils Unix place les informations liées les unes près des autres, ce qui permet au mécanisme d’attention des LLM de fonctionner efficacement
    Le JSON est facile à parser, mais peu pratique à lire et à raisonner
    Le format CLI est intuitif à la fois pour les humains et pour les LLM
    Voir aussi : Entropy and Information Layout

  • Comparer MCP et la CLI, c’est un peu comme comparer OpenAPI et des chaînes de caractères (JSON)
    MCP est défini formellement, tandis que la CLI est une interface abstraite du niveau de (String, List String, Map Int Stream) -> PID
    Au fond, ce sont deux API, et l’essentiel est de choisir l’outil adapté pour atteindre l’objectif

    • Mais la CLI fournit une documentation complète via --help, donc si un LLM peut la comprendre, il est difficile d’affirmer qu’une standardisation MCP est supérieure
    • Plus que la théorie, c’est l’expérience réelle d’utilisation qui compte. Pour affirmer que MCP et la CLI se valent, il faudrait par exemple montrer un cas où la CLI et MCP de Playwright offrent la même consommation de tokens et la même configurabilité
      Sinon, on finit forcément par constater directement que, dans la pratique, ces deux approches sont différentes
 
develosopher 2026-03-03

Si quelqu’un développe un SaaS et hésite entre CLI et MCP pour l’intégration de l’IA, il choisira probablement d’abord MCP. Prendre en charge une CLI augmente les points de gestion. Les deux peuvent coexister, mais je ne pense pas que cela disparaisse.
 
hanje3765 2026-03-03

On dirait qu’à mesure que l’intelligence des LLM augmente, la nécessité du MCP devient plus floue.
C’est aussi ce que je ressens en pratique.
 
m00nlygreat 2026-03-03

L’exécution à distance semble se résumer à mcp, et l’exécution locale à skills.
 
hulryung 2026-03-03

Moi aussi, j’ai commencé à créer et utiliser directement mes propres outils en CLI plutôt qu’avec MCP.