Depuis fin février 2026, le protocole MCP (Model Context Protocol) est sous le feu des critiques.
“MCP is dead, long live the CLI”, titre Eric Holmes dans un article devenu viral.
Le CTO de Perplexity annonce l’abandon du protocole en interne.
Garry Tan, président de Y Combinator, tweete sans détour : “MCP sucks honestly ”.
Le projet OpenClaw choisit délibérément de ne pas le supporter.
Les griefs sont connus :
- explosion de la consommation de tokens,
- authentification immature,
- fiabilité opérationnelle douteuse.
Et ils sont légitimes — dans un modèle d’architecture bien précis. Celui que nous n’avons jamais adopté chez Agora.
Le vrai problème : le LLM aux commandes du MCP
Le schéma que tout le monde attaque, c’est celui du LLM-as-router. On injecte dans le contexte du modèle les schémas de dizaines d’outils MCP — leurs descriptions, leurs paramètres, leurs contraintes. Le LLM doit ensuite choisir quel outil appeler, avec quels arguments, et dans quel ordre. C’est le pattern dominant dans l’écosystème actuel des agents IA.
Et c’est précisément là que les critiques font mouche.
Cloudflare a mesuré l’écart sur sa propre API : 1,17 million de tokens pour exposer ses 2.500 endpoints via des schémas MCP natifs — davantage que la fenêtre de contexte complète des modèles les plus avancés. Même en ne conservant que les paramètres requis, on reste à 244 000 tokens. Leur solution, Code Mode, ramène le tout à ~1 000 tokens grâce à deux outils génériques (search() et execute()), soit une réduction de 99,9 %.
Quand chaque token a un coût en latence, en énergie et en euros, l’équation du MCP natif ne tient plus.
Sans compter le risque d’erreur : un LLM qui choisit parmi 50 outils peut se tromper d’appel, inventer des paramètres, ou déclencher une action destructrice sur un malentendu.
Le diagnostic est juste. Mais la conclusion — “il faut abandonner MCP” — confond le protocole avec un pattern d’architecture.
Notre approche : séparer compréhension et exécution
Une séparation claire entre compréhension et exécution (MCP)
Chez Agora, nous avons fait un choix d’architecture fondamentalement différent dès la conception de notre plateforme agentique.
Le LLM ne voit jamais les schémas MCP. Il ne choisit pas quel outil appeler. Il ne construit pas les paramètres d’un appel API.
Le flux est le suivant :
Le LLM intervient sur ce qu’il fait le mieux : comprendre le langage naturel.
- Il classifie l’intention de l’utilisateur (“je veux poser un congé“, “affiche mon bulletin de paie de janvier“),
- Il extrait les entités mentionnées (dates, noms, montants), et détecte les suivis de conversation.
Une exécution MCP pilotée par un DSL et un SDK dédié
C’est ensuite notre SDK, piloté par un DSL déclaratif, qui prend le relais.
Un DSL — Domain-Specific Language — est un langage spécialisé pour un domaine précis. Contrairement à un langage généraliste comme Python, un DSL exprime des règles métier de façon concise et lisible.
Dans notre cas, ce DSL est injecté dans le contexte du LLM sous forme de prompt structuré : il décrit les intentions reconnues par l’agent, les paramètres attendus pour chaque intention, et les règles de dialogue à suivre pour les collecter.
Quelle est la différence clé avec le pattern LLM-as-router ?
Au lieu d’injecter des centaines de schémas d’outils MCP dans le contexte et de demander au LLM de choisir le bon endpoint avec les bons paramètres, on lui fournit une grammaire métier ciblée. Le LLM n’a qu’à comprendre ce que l’utilisateur veut faire — pas comment l’API fonctionne.
Cette spécialisation du prompt rend la classification nettement plus stable et réduit considérablement la charge cognitive imposée au modèle.
Le résultat : moins de tokens en contexte, moins d’ambiguïté, moins d’erreurs.
Une fois l’intention classifiée et les entités extraites, c’est le SDK — côté code, cette fois — qui sait quelle intention correspond à quel appel MCP. Et il orchestre un dialogue de collecte quand des informations manquent :
- “Pour quelles dates souhaitez-vous poser ce congé ?”
- “S’agit-il d’un congé payé ou d’un RTT ?”
L’appel MCP n’est déclenché qu’une fois tous les arguments collectés et validés. Pas avant.
Ce que ça change concrètement
Des tokens utilisés pour comprendre, pas pour router
Dans le modèle LLM-as-router, l’essentiel du budget de tokens est consommé par les descriptions d’outils injectées dans le contexte. Et cela avant même que l’utilisateur n’ait posé sa question.
Chez nous, le contexte du LLM contient l’historique de la conversation et le prompt de classification. Effectivement, les schémas MCP n’y figurent pas.
Résultat : une consommation de tokens par requête considérablement réduite, ce qui se traduit directement en capacité de traitement supérieure sur notre infrastructure d’inférence locale.
Une collecte d'arguments garantie
Le pattern classique repose sur l’espoir que le LLM extraira correctement tous les paramètres du message de l’utilisateur en une seule passe. Quand un paramètre obligatoire est absent, le comportement est imprévisible : paramètre inventé, appel partiel, ou échec silencieux.
Notre système de dialogues automatiques détecte les arguments manquants et engage une conversation structurée pour les collecter.
La désambiguïsation (“vous avez deux managers, lequel ? ”) et la confirmation (“je vais poser un congé du 15 au 22 mars, c’est bien ça ?”) sont des étapes du workflow, pas des comportements émergents du modèle.
L'authentification : un faux problème
Parmi les critiques récurrentes adressées au MCP, l’authentification revient systématiquement.
Eric Holmes résume le sentiment dominant : “pourquoi un protocole pour donner des outils à un LLM devrait-il se préoccuper d’authentification ?”.
Les CLI, eux, s’appuient sur des mécanismes éprouvés — aws sso login, gh auth login, kubeconfig — et ça fonctionne.
Mais cette critique confond deux choses :
- l’immaturité de l’implémentation auth dans l’écosystème MCP communautaire et
- la capacité intrinsèque du protocole à s’intégrer à des solutions d’authentification robustes.
En effet le MCP, en tant que protocole basé sur JSON-RPC, n’a pas besoin de réinventer l’authentification. Il peut — et doit — s’appuyer sur les standards éprouvés qui existent déjà : SAML pour le SSO en entreprise, OAuth 2.1 pour la délégation d’accès, OpenID Connect pour l’authentification fédérée.
La roadmap 2026 du protocole va d’ailleurs dans ce sens, avec l’intégration d’OAuth 2.1 et le support du transport HTTP streamable.
Chez Agora, l’authentification des appels MCP est gérée en amont par la plateforme. Le SDK contrôle la chaîne complète : authentification de l’utilisateur, vérification de ses droits, puis transmission d’un contexte d’identité validé au serveur MCP.
Donc l’agent conversationnel ne manipule jamais de credentials directement. Et ce n’est pas une limitation — c’est une séparation des responsabilités. Le même principe que celui qui fait qu’un contrôleur dans une application web ne gère pas lui-même les tokens JWT : il délègue à un middleware d’authentification.
En fait, les organisations qui peinent avec l’auth MCP sont généralement celles qui tentent de faire gérer l’authentification par le LLM lui-même, ou qui déploient des serveurs MCP communautaires sans couche de sécurité en amont. Dans une architecture maîtrisée, l’authentification est un problème résolu depuis longtemps.
MCP comme standard d'interopérabilité, pas comme moteur d'agent
Le débat actuel oppose deux visions caricaturales : “MCP partout” contre “MCP nulle part”. La réalité est comme souvent plus nuancée.
MCP reste un excellent standard d’interopérabilité entre une plateforme d’IA et les applications métier qu’elle doit piloter. Il offre un contrat d’interface structuré, versionnable, documentable.
Pour un éditeur de SIRH, d’ERP ou de CRM qui veut rendre son application accessible via un agent conversationnel, MCP fournit un cadre clair — bien plus que “exposez une CLI et laissez le LLM se débrouiller”.
Ce qui pose problème, ce n’est pas le MCP en tant que protocole. C’est le pattern architectural qui consiste à exposer l’intégralité de la surface MCP au LLM et à lui confier les décisions de routage et de paramétrage.
- Séparez la compréhension du langage naturel de l’exécution des actions.
- Donnez au LLM le rôle de comprendre l’utilisateur.
- Demandez à du code déterministe le rôle de piloter les appels.
Et vous retrouvez un MCP qui fait exactement ce pour quoi il a été conçu : un standard d’intégration fiable entre systèmes.
MCP is not dead
Le MCP n’est pas mort. Mais l’architecture naïve qui laisse le LLM seul aux commandes — choisir l’outil, deviner les paramètres, déclencher l’exécution — mérite les critiques qu’elle reçoit.
Chez Agora, nous construisons des agents conversationnels pour des éditeurs de logiciels métier qui traitent des données sensibles sur une infrastructure souveraine.
Confier le routage MCP à un modèle probabiliste n’a jamais été une option. Notre stack repose sur un LLM pour la compréhension, un DSL pour le routage, des dialogues pour la collecte, et MCP pour l’interopérabilité.
Le résultat : moins de tokens consommés, des actions fiables, des données protégées, une authentification maîtrisée, et un protocole qui fait ce qu’on lui demande — ni plus, ni moins.
_____________
Vous êtes un éditeur de logiciel ? Nous espérons que cet article vous aura éclairé sur notre conviction : Le MCP n’est pas à écarter, il s’agit d’un problème d’usage, et non de design ou de performance.
Agora Software est l’éditeur de solutions d’IA dédiées aux éditeurs. Nous déployons, rapidement, des agents renforçant l’expérience utilisateur des applications et des plateformes.
Vous souhaitez intégrer des agents à vos applications ?
Parlons-en : contact@agora.software
Vous avez aimé cette lecture ? Alors vous pourriez lire notre article dédié à l’inférence locale.
Rejoignez-nous sur notre page Linkedin pour suivre notre actualité !
Vous développez une application ou une plateforme SaaS et souhaitez intégrer des agents IA performants, sans retarder votre roadmap produit ?
Découvrez comment notre plateforme vous permet de déployer, maintenir et faire évoluer vos agents à l’échelle, en bénéficiant en continu de nos innovations et de notre veille technologique.