Le MCP n'est pas mort, il est mal utilisé

Le vrai problème : le LLM aux commandes du MCP

Depuis fin février 2026, le protocole MCP (Model Context Protocol) fait face à des critiques virales. Eric Holmes proclame “MCP is dead, long live the CLI”. Le CTO de Perplexity annonce l’abandon interne du protocole. Garry Tan de Y Combinator tweete : “MCP sucks honestly”. Le projet OpenClaw refuse délibérément de le supporter.

Les griefs soulevés sont légitimes dans un contexte architectural précis : l’explosion de la consommation de tokens, l’authentification immature, et la fiabilité opérationnelle douteuse.

Le modèle LLM-as-router sous le feu

Le schéma dominant attaqué est celui du LLM-as-router. Des centaines de schémas d’outils MCP sont injectés dans le contexte du modèle, laissant le LLM choisir quel outil appeler, avec quels arguments, et dans quel ordre.

Cloudflare a mesuré l’impact : 1,17 million de tokens pour exposer 2.500 endpoints via schémas MCP natifs. Même en conservant uniquement les paramètres obligatoires, on reste à 244.000 tokens. Leur solution Code Mode réduit cela à ~1.000 tokens grâce à deux outils génériques, soit une réduction de 99,9%.

Quand chaque token représente latence, énergie et coûts financiers, l’équation du MCP natif s’effondre.

L’ajout du risque d’erreur : un LLM choisissant parmi 50 outils peut déclencher des actions destructrices sur malentendu.

Notre approche : séparer compréhension et exécution

Chez Agora, le choix architectural diffère fondamentalement. Le LLM ne voit jamais les schémas MCP. Il ne choisit pas quel outil appeler ni ne construit les paramètres d’appel API.

Le flux opérationnel

Le LLM intervient sur son point fort : comprendre le langage naturel.

• Il classifie l’intention utilisateur (“je veux poser un congé”)
• Il extrait les entités mentionnées (dates, noms, montants)
• Il détecte les suites de conversation

L’exécution MCP est ensuite pilotée par un DSL (Domain-Specific Language) déclaratif et un SDK dédié.

Ce DSL, injecté sous forme de prompt structuré, décrit les intentions reconnues, les paramètres attendus, et les règles de dialogue pour les collecter.

La différence clé avec le pattern LLM-as-router

Au lieu d’injecter des centaines de schémas MCP et demander au LLM de choisir le bon endpoint, on fournit une grammaire métier ciblée. Le LLM comprend uniquement ce que l’utilisateur veut faire, pas comment l’API fonctionne.

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, le SDK orchestre un dialogue de collecte si 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 ne se déclenche qu’une fois tous les arguments collectés et validés.

Ce que ça change concrètement

Des tokens utilisés pour comprendre, pas pour router

Dans le modèle LLM-as-router, le budget de tokens est consommé par les descriptions d’outils injectées dans le contexte, avant même que l’utilisateur pose sa question.

Chez Agora, le contexte du LLM contient l’historique conversationnel et le prompt de classification — pas les schémas MCP.

Résultat : consommation de tokens réduite, capacité de traitement supérieure sur l’infrastructure d’inférence locale.

Une collecte d’arguments garantie

Le pattern classique espère que le LLM extraira tous les paramètres obligatoires en une seule passe. Quand un paramètre manque, le comportement devient imprévisible.

Le système Agora détecte les arguments manquants et engage une conversation structurée pour les collecter. La désambiguïsation et la confirmation deviennent des étapes du workflow, pas des comportements émergents du modèle.

L’authentification : un faux problème

Parmi les critiques du MCP, l’authentification revient régulièrement. Eric Holmes demande : pourquoi un protocole pour donner des outils à un LLM devrait-il gérer l’authentification ?

Cette critique confond deux réalités :

• 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

Le MCP, basé sur JSON-RPC, n’a pas besoin de réinventer l’authentification. Il peut s’appuyer sur les standards éprouvés : 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 dans ce sens, intégrant OAuth 2.1 et le transport HTTP streamable.

Chez Agora, l’authentification des appels MCP est gérée en amont par la plateforme. L’agent conversationnel ne manipule jamais directement de credentials. C’est une séparation des responsabilités — similaire à un contrôleur web qui délègue l’authentification à un middleware.

Les organisations peinent avec l’auth MCP généralement parce qu’elles tentent de faire gérer l’authentification par le LLM lui-même, ou déploient des serveurs MCP communautaires sans couche de sécurité en amont.

MCP comme standard d’interopérabilité, pas comme moteur d’agent

Le débat oppose deux visions caricaturales : “MCP partout” contre “MCP nulle part”. La réalité s’avère 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, ERP ou CRM, MCP fournit un cadre clair — bien plus que “exposez une CLI et laissez le LLM se débrouiller”.

Ce qui pose problème n’est pas le MCP en tant que protocole, mais le pattern architectural exposant l’intégralité de la surface MCP au LLM en lui confiant les décisions de routage et de paramétrage.

Le chemin vers la fiabilité

• 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 de piloter les appels

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. L’architecture naïve laissant le LLM seul aux commandes — choisir l’outil, deviner les paramètres, déclencher l’exécution — mérite les critiques reçues.

Agora construit des agents conversationnels pour des éditeurs de logiciels métier traitant des données sensibles sur infrastructure souveraine. Confier le routage MCP à un modèle probabiliste n’a jamais été une option.

Le 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é.

Résultat : moins de tokens consommés, actions fiables, données protégées, authentification maîtrisée, et un protocole qui fait ce qu’on lui demande.