Le MCP est mort ; vive le MCP

 (chrlschn.dev)
19 points par GN⁺ 2026-03-16 | 6 commentaires | Partager sur WhatsApp
  • La CLI s’impose comme la nouvelle tendance des interfaces d’outils pour agents, mais les CLI sur mesure rencontrent les mêmes problèmes de contexte que le MCP et doivent renoncer à la structuration ainsi qu’à plusieurs de ses avantages
  • Le MCP en mode local stdio et le MCP distant basé sur Streamable HTTP répondent à des cas d’usage complètement différents, une distinction largement ignorée dans le débat actuel
  • Les fonctionnalités Prompts et Resources du MCP constituent un mécanisme permettant de diffuser en temps réel, à l’échelle de l’organisation, des compétences et de la documentation standardisées, ce qui est essentiel pour passer du vibe coding à une ingénierie agentique structurée
  • Les serveurs MCP centralisés standardisent l’authentification OAuth, la télémétrie et l’observabilité, rendant possibles la sécurité à l’échelle de l’organisation et la mesure de l’efficacité des outils
  • Pour un développeur individuel, la CLI peut convenir, mais au niveau organisationnel et enterprise, le MCP est l’outil du présent et de l’avenir pour garantir cohérence, sécurité et qualité

Cycle de hype piloté par les influenceurs

  • Il y a à peine six mois, le Model Context Protocol (MCP) était le principal sujet du secteur, et tous les éditeurs cherchaient à lancer des produits liés au MCP
  • Déjà à l’époque, certains restaient sceptiques en demandant « ce n’est qu’une API, pourquoi faut-il un wrapper ? », et certaines équipes ont effectivement choisi d’ignorer le cycle de hype du MCP pour écrire de simples wrappers d’outils au-dessus d’endpoints d’API REST
  • Pour la plupart des cas d’usage, l’idée s’est répandue que le MCP représentait un surcoût inutile par rapport à un appel direct d’API
  • Aujourd’hui, le discours du secteur s’est déplacé vers la critique du MCP et l’éloge de la CLI, en lien avec une dynamique où les influenceurs IA doivent sans cesse créer de nouvelles tendances pour capter l’attention
  • Même des figures reconnues comme Garry Tan ou Andrew Ng ont tendance à généraliser à partir de leur expérience personnelle, et cette culture d’influence qui alimente le FOMO et la hype déforme le débat dans ce domaine
  • Il existe bien des cas où la CLI est plus adaptée comme interface d’outils pour agents, mais ce n’est pas vrai dans tous les cas

Les économies de tokens avec la CLI : réalité et limites

Outils CLI présents dans les données d’entraînement

  • Des utilitaires CLI comme jq, curl, git, grep, psql, aws, déjà présents dans le jeu de données d’entraînement des LLM, peuvent être utilisés immédiatement par un agent sans instructions, schéma ni contexte supplémentaires
  • Le MCP doit pré-déclarer les outils dans la réponse tools/list, ce qui introduit un surcoût par rapport à des outils CLI déjà connus
  • Lorsqu’un outil CLI existe déjà dans les données d’entraînement, il est logique de le privilégier systématiquement au MCP

Limites des CLI sur mesure

  • Les outils CLI sur mesure (bespoke) ne sont pas connus des LLM, il faut donc fournir une explication dans AGENTS.md ou README.md
  • On peut désigner un répertoire /cli-tools et compter sur des noms descriptifs, mais les agents se trompent souvent avec cette approche, ce qui finit par nécessiter davantage de documentation explicative
  • Même un outil comme curl perd son avantage en économie de tokens dès qu’il doit comprendre un schéma OpenAPI personnalisé

Extraction et transformation en chaîne

  • Une chaîne CLI peut récupérer puis transformer des données afin de réduire le volume envoyé dans la fenêtre de contexte
  • Cependant, des contenus structurés comme HTML, JSON ou XML peuvent aussi être extraits via des sélecteurs DOM/CSS, JSONPath, XPath, ce qui n’est donc pas un avantage propre à la CLI

Consommation progressive du contexte

  • Alors que le MCP charge à l’avance l’ensemble des outils et des schémas, la CLI peut charger le contexte progressivement via --help
  • Mais avec des outils CLI sur mesure, l’agent doit explorer le contenu d’aide sur plusieurs tours, ce qui revient au final à charger une information proche d’un schéma MCP, mais sans structure
  • Dans des flux suffisamment complexes, l’agent finit de toute façon par explorer la majeure partie de l’arborescence, ce qui réduit fortement les gains
  • Selon les recherches de Vercel, placer l’index complet de la documentation dans AGENTS.md améliore l’exploitation de la documentation par les agents, et fournir d’emblée l’ensemble du schéma favorise un meilleur choix d’outils
  • Alors qu’Anthropic propose désormais une fenêtre de contexte d’un million de tokens, on peut se demander si l’économie de tokens reste encore un argument décisif

La dualité du MCP : stdio vs Streamable HTTP

Limites du mode stdio

  • En mode stdio, le serveur MCP s’exécute localement avec l’agent et ajoute une complexité inutile par rapport à l’écriture d’une simple CLI
  • Dans la majorité des cas d’usage, le MCP en mode stdio est superflu

La valeur transformatrice de Streamable HTTP

  • Le MCP avec transport Streamable HTTP permet d’exécuter la même logique sur un serveur centralisé, ce qui en fait un élément clé pour transformer, dans l’adoption en organisation et en enterprise, le vibe coding en ingénierie agentique
  • La plupart des influenceurs ne distinguent pas correctement ces deux modes

Les avantages d’un serveur MCP centralisé

Fonctionnalités backend riches

  • Un serveur central permet aux outils d’exploiter des capacités de plateforme avancées, comme une instance Postgres ou des requêtes de graphe Cypher basées sur Apache AGE
  • Côté agent, il suffit de configurer un endpoint HTTP et un jeton d’authentification, ce qui simplifie le déploiement
  • Une base locale comme SQLite reste possible, mais elle montre vite ses limites dès qu’il faut partager l’état à l’échelle de l’organisation

Environnements d’exécution d’agents éphémères

  • Dans des environnements d’exécution temporaires comme GitHub Actions, un serveur MCP distant permet d’utiliser sans installation des outils nécessitant un backend complexe
  • Il délègue au serveur central la gestion de charges stateful dans des environnements stateless

Authentification et sécurité

  • Avec une CLI, accéder à une API sécurisée impose que chaque développeur ait un accès direct à la clé API, ce qui représente une lourde charge pour les équipes d’exploitation
  • En centralisant derrière un serveur MCP, les développeurs s’authentifient au serveur MCP via OAuth, tandis que les clés API et secrets sensibles restent contrôlés côté serveur
  • Lorsqu’un membre quitte l’équipe, il suffit de révoquer le token OAuth ; cette personne n’a de toute façon jamais eu accès aux autres clés ni aux secrets

Télémétrie et observabilité

  • Un serveur MCP centralisé permet de collecter de manière standard des traces et métriques OpenTelemetry
  • Il devient possible d’identifier quels outils sont efficaces, quels runtimes d’agents sont utilisés et à quels endroits les outils échouent
  • C’est faisable aussi avec des outils CLI, mais un déploiement local exige des mises à jour côté utilisateurs et il faut reproduire le scaffolding de télémétrie dans chaque outil CLI

Déploiement instantané standardisé et mises à jour automatiques

  • Les outils distribués sous forme de paquets provoquent des problèmes de compatibilité de versions d’API, alors que le MCP permet au serveur de notifier les clients des mises à jour via Subscriptions et Notifications
  • Les MCP Prompts correspondent à un SKILL.md fourni par le serveur, et les MCP Resources à un /docs servi par le serveur

La valeur organisationnelle des MCP Prompts et Resources

  • Contenu dynamique : les fichiers *.md d’un dépôt sont statiques et nécessitent des mises à jour manuelles, alors que les prompts et resources côté serveur peuvent être générés dynamiquement en temps réel
    • Il est possible d’injecter dynamiquement sans appel d’outil des documents utiles seulement dans certains contextes, des données tarifaires, l’état actuel du système, etc.
  • Mises à jour automatiques et cohérentes : les fichiers *.md distribués dans un dépôt ou un paquet doivent être synchronisés, tandis que des prompts MCP restent toujours à jour
    • Même la documentation officielle de tiers peut être proxifiée via le serveur, sans duplication ni mise à jour manuelle dans les dépôts
  • Partage des connaissances à l’échelle de l’organisation : du contenu applicable à toute l’entreprise — bonnes pratiques de sécurité, de télémétrie, considérations de déploiement d’infrastructure — peut être diffusé de manière cohérente à tous les dépôts, tous les workflows et toutes les interfaces frontend d’agents (Claude Code, Codex, VS Code Copilot, GitHub Agents, OpenCode, etc.)
    • Dans un environnement microservices, une équipe peut ainsi accéder à la documentation d’un autre service, ou une équipe produit peut fournir dynamiquement des compétences à chaque déploiement
  • Des cas concrets montrent que les prompts et resources MCP fonctionnent réellement dans OpenCode, Claude Code CLI, etc., et qu’une simple configuration du client MCP suffit, sans gestion supplémentaire après le déploiement

Conclusion : à l’échelle des organisations, le MCP est le présent et l’avenir

  • Il y a six mois, le MCP était au sommet de la hype ; aujourd’hui, il est accusé d’être la cause principale du gonflement du contexte, mais on ignore souvent les compromis et pièges similaires des CLI sur mesure
  • Dès qu’une équipe réfléchit à la manière de passer du vibe coding à l’ingénierie agentique, elle aboutit naturellement à la conception et à la mission du MCP
  • Comme le montre un cas récent chez Amazon AWS — exigeant l’approbation d’un ingénieur senior pour des changements assistés par IA — les équipes devront de toute façon exploiter et maintenir les systèmes logiciels produits par des agents IA
  • Les conseils de Garry Tan ou d’Andrew Ng peuvent être pertinents dans un environnement individuel homogène, mais ils se transposent difficilement tels quels à une organisation où des équipes de niveaux techniques et d’expériences variés doivent converger vers une qualité cohérente
  • Pour livrer un logiciel fiable et maintenable, il faut une discipline d’ingénierie garantissant cohérence, sécurité, qualité et exactitude ; et pour cela, le MCP est aujourd’hui l’outil adapté aux organisations et aux entreprises

À lire aussi

6 commentaires

 
slowandsnow 2026-03-16

Le CLI est un outil local, tandis que MCP est un serveur, donc leurs usages sont très différents.
 
cnaa97 2026-03-17

Si on exécute le CLI sur le serveur, est-ce que ce ne serait pas la même chose ?
 
ng0301 2026-03-16

MCP est ressuscité !
 
edunga1 2026-03-16

Document associé : MCP est mort. Vive le CLI
 
hmmhmmhm 2026-03-16

J’aimerais que les discussions progressent davantage autour d’une sorte de fonctionnalité de sandbox CLI permettant d’utiliser des outils CLI aussi sur les applications mobiles ; quand on essaie de rendre le mobile réellement compatible, il semble qu’au final le principal goulot d’étranglement soit justement le sandboxing.
 
GN⁺ 2026-03-16
Réactions sur Hacker News

  • J’ai l’impression que la plupart des fonctions d’intégration IA qui sortent en ce moment sont mal conçues
    Alors que même les commandes de base ne sont pas standardisées, on se retrouve inondés de guides inexacts générés par des LLM au lieu d’avoir une vraie documentation
    Au final, ce qu’on appelle les « standards de l’IA » va sans doute apparaître puis disparaître en boucle. Les LLM sont fondamentalement basés sur du texte, donc ils ont du mal à fonctionner avec la précision d’un protocole réseau. Ce type d’ingénierie centrée sur le texte finit par construire une pyramide d’abstractions instable

  • Parmi les outils IA, les plus utiles me semblent être ceux qui encapsulent des agents probabilistes dans des garde-fous déterministes
    C’est pour ça que j’utilise MCP au-dessus de HTTP. Par exemple, NanoClaw renforce la sécurité en filtrant de manière déterministe les messages WhatsApp et en proxyfiant les clés API. Ce type d’architecture rend l’IA plus digne de confiance

    • Je suis un schéma similaire. Mon agent autonome Smith relie MCP à un service mesh pour gérer de façon centralisée les politiques (OPA) et le monitoring
      Cette architecture offre un haut niveau de sécurité et de facilité d’administration, et permet même de générer automatiquement un CLI à partir du catalogue d’outils
      On peut voir un exemple d’implémentation dans smith-gateway
    • Même si l’agent est compromis, les frontières doivent rester intactes. Nous utilisons des jetons de délégation cryptographiques à périmètre limité pour chaque tâche, vérifiés à la frontière des outils MCP
      Le cœur open source est disponible dans tenuo
    • Aujourd’hui, la clé d’un bon tooling IA, ce n’est pas de donner de la liberté, mais de poser des contraintes
      MCP sépare clairement la prise de décision de l’IA de l’exécution déterministe du système. J’utilise Claude Code avec un serveur MCP : l’IA s’occupe de la résolution créative des problèmes, et l’exécution suit un chemin prévisible, ce qui est très efficace

  • MCP est une spécification de protocole fixe pour la communication entre applications IA
    Au lieu de bricoler les API entre applications comme dans les approches d’« intégration » classiques, il fournit une abstraction de communication réutilisable comme HTTP, FTP ou SMTP
    Je pense qu’il faut un langage commun de ce type pour que l’IA puisse interagir avec divers services
    La spécification est disponible sur modelcontextprotocol.io/specification/2025-11-25

    • Mais certains disent que c’est « une solution qui se trompe de problème »
      En réalité, ce qu’il faut, ce n’est pas un nouveau protocole, mais des spécifications CLI ou API explorables progressivement. Selon eux, MCP n’est qu’un pis-aller né à une époque où les premiers agents ne savaient pas exécuter des CLI
    • Un autre avis est : « si l’IA est vraiment de l’IA, pourquoi lui faut-il un protocole séparé pour comprendre HTTP ou FTP ? »
      Dans cette lecture, MCP n’est qu’une solution temporaire à l’immaturité technique
    • Certains soulèvent aussi la question fondamentale : « a-t-on vraiment besoin de créer un nouveau protocole ? »
    • Il y a aussi la critique selon laquelle MCP n’est en pratique qu’une définition d’API sur mesure posée sur JSON-RPC, donc pas vraiment plus standard ni plus réutilisable que les approches existantes
    • D’autres estiment que les outils CLI, eux aussi, sont au fond une « abstraction de communication réutilisable », et ne sont donc pas si différents de MCP

  • Quand MCP est apparu, ça m’a semblé être une camelote inutilement surconçue, donc je n’y ai pas prêté attention
    Jusqu’à présent, je ne le regrette pas. Même chose pour LangChain. Suivre une mode parce qu’elle est populaire, c’est dangereux

    • Pourtant, aujourd’hui, j’ajoute une interface MCP à tout mon code. C’est beaucoup plus simple à déboguer pour un LLM, et c’est devenu un composant aussi important que l’UI
      Avec un très faible investissement en temps, on peut obtenir un gros gain d’efficacité
    • Bien sûr, le « sniff test » est utile, mais il ne suffit pas à lui seul
      Parfois, des outils un peu grossiers survivent précisément parce qu’ils simplifient des problèmes d’intégration complexes
      Si on les écarte d’emblée parce qu’ils paraissent laids, on risque de rater quelque chose qui deviendra plus tard une infrastructure standard
    • LangChain n’est pas surconçu, c’est un chaos sans aucune conception
    • Certains disent au contraire que MCP a gagné en popularité parce qu’il est trop simple
      Ce ne serait pas un cas de surconception, mais plutôt une structure claire et intuitive
    • Il y a aussi des gens qui disent ne toujours pas savoir exactement ce qu’est LangChain

  • Le MCP distant est intéressant parce que l’authentification y est gérée automatiquement, ce qui simplifie l’accès aux services
    Mais par rapport à la combinaison CLIs + Skills, il entraîne davantage de surcharge de contexte (context bloat) et fait perdre les avantages du CLI Unix, comme les pipelines ou les entrées heredoc
    Un skill peut être généré automatiquement à partir de la sortie de --help, ce qui est efficace
    MCP exige un processus persistant, alors qu’un CLI peut être exécuté seulement quand on en a besoin

    • Bien sûr, un CLI doit être installé, mais MCP a l’avantage de fonctionner par simple configuration

  • Je pense toujours que MCP est une couche inutile
    Je suis d’accord sur le fait que CLI > MCP, mais les avantages en matière de documentation et de centralisation peuvent être obtenus autrement
    Par exemple, avec des Skills, on peut inclure des instructions pour les CLI comme pour les API, et elles ne sont chargées qu’au moment nécessaire
    En réalité, les avantages d’un MCP centralisé peuvent déjà être reproduits avec un proxy classique ou AWS SSO
    Au final, je pense qu’il vaut mieux documenter avec des Skills et faire les interactions réelles via un CLI ou une API REST

    • Il existe toutefois une réponse à cela
      Le contenu des Skills finit lui aussi par être injecté dans le contexte et par créer une surcharge, et un proxy ne peut pas remplacer complètement les fonctions de MCP
      MCP permet d’activer des prompts et des ressources via les commandes / et les références @, ce qu’un proxy ne permet pas
      On peut voir des démos liées à cela dans les .gif en fin d’article et dans la spécification MCP

  • J’ai l’impression que MCP est mieux adapté aux environnements grand public
    Dans un environnement de développement, c’est complexe et inefficace, mais pour un utilisateur généraliste, MCP permet de comprendre facilement quelles fonctions un modèle peut exécuter
    Il ne nécessite pas de configuration de l’environnement, et une GUI peut visualiser les réponses comme Siri ou Google Assistant

  • Du point de vue de quelqu’un qui fournit des outils IA à des utilisateurs non développeurs en entreprise, une approche MCP centralisée s’est révélée très utile
    Elle permet de gérer de manière cohérente le ton de marque, la terminologie interne, l’accès commun aux données et le contexte métier
    Grâce aux méthodes de ressources de MCP, on peut fournir des « skills » standardisés et contrôler les schémas de connexion aux données

  • L’auteur examine plusieurs concepts sous différents angles, mais il semble ne pas connaître des notions existantes comme Token Notation (TOON)
    On a presque l’impression qu’il souhaite l’existence de quelque chose qui existe déjà

  • Le vrai problème de MCP, c’est la charge de maintenance
    Par exemple, si on a besoin d’une intégration GitHub, on finit par dépendre d’un wrapper npm au lieu d’une API déjà bien documentée
    Moi, j’utilise simplement le CLI gh ou curl. Si l’API change, l’agent lit la nouvelle documentation et s’adapte
    Avec MCP, il faut attendre que le wrapper intermédiaire soit mis à jour
    Les arguments sur la sécurité sont aussi contradictoires — au départ, c’est sorti sans authentification, et maintenant on présente la sécurité comme un avantage
    En pratique, ce sont des problèmes déjà résolus depuis longtemps par des approches comme chroot ou les scoped tokens
    Le seul vrai avantage de MCP, à mes yeux, c’est le flux OAuth pour les non-développeurs. Pour les outils destinés aux développeurs, je pense qu’il vaut mieux simplement concevoir de meilleurs CLI