Depuis son lancement fin 2024, le Model Context Protocol (MCP) a été salué comme le « connecteur universel » de l'écosystème de l'intelligence artificielle. Pourtant, alors que son adoption se répand, un nombre croissant de développeurs remettent en cause son efficacité au quotidien, tandis que d'autres acteurs du secteur en défendent la pertinence, en particulier pour les usages professionnels non techniques.

Des performances sous le feu des critiques

Une étude récente menée par une équipe d'ingénieurs sur leur pile technologique réelle dresse un tableau sévère. Selon leurs mesures, la connexion de quatre serveurs MCP (Linear, Notion, Slack et Postgres) consomme à elle seule 10,5 % de la fenêtre de contexte d'un modèle doté de 200 000 tokens, comme Claude. Avec un modèle plus contraint tel que GPT-4o (128 000 tokens), cette part monte à 16,5 %. Le serveur Linear est particulièrement gourmand, avec plus de 12 800 tokens nécessaires rien que pour ses définitions d'outils, soit 42 outils chargés en permanence, même si l'utilisateur n'en emploie que deux.

Les auteurs de ce travail signalent également des problèmes de fiabilité opérationnelle : échecs d'initialisation, ralentissement des réponses (jusqu'à trois fois plus lentes par appel, et 9,4 fois plus lentes pour le premier appel en incluant l'initialisation), et des interruptions de session lorsque le processus du serveur MCP plante. Ils soulignent aussi un chevauchement important avec les interfaces en ligne de commande (CLI) et les API existantes, qui offrent une meilleure composabilité, un débogage plus aisé et un coût d'installation moindre. Un comparatif montre qu'une simple requête vers Linear consomme environ 12 957 tokens via MCP, contre seulement 200 tokens via une commande curl directe.

Ces constats ont conduit certains à prononcer la mort du protocole, le jugeant inadapté pour les développeurs aguerris qui maîtrisent déjà les CLI et les API.

Un plaidoyer pour la gouvernance et les non-développeurs

Face à ces critiques, d'autres voix s'élèvent pour défendre MCP, en arguant que le protocole n'a jamais été conçu pour les utilisateurs avancés du terminal. Selon ces défenseurs, réduire MCP à une simple couche CRUD (création, lecture, mise à jour, suppression) revient à en méconnaître la finalité : exposer des intentions à un modèle d'IA dans le cadre d'une conversation, et non des appels d'API bruts.

Le cœur de l'argumentation porte sur la gouvernance. Dans les grandes organisations, il est impossible de laisser chaque employé configurer localement ses CLI avec des identifiants de production. MCP agit comme une « porte d'entrée contrôlée » entre les agents d'IA et les ressources qu'ils sont autorisés à toucher. Il permet de différencier les actions humaines des actions automatiques, d'auditer l'ensemble des appels, de délivrer des jetons à durée de vie limitée et de limiter le rayon d'explosion des actions malveillantes ou des erreurs. Sans cette couche, un agent utilisant un CLI local bénéficie du même niveau d'accès que l'utilisateur humain, ce qui est jugé dangereux.

Par ailleurs, les non-développeurs — commerciaux, analystes, responsables opérationnels — qui utilisent des outils comme Claude Desktop ne manipulent ni terminal ni ligne de commande. Pour eux, MCP est déployé de manière transparente par les équipes informatiques, via des connecteurs préconfigurés. La promesse n'est pas l'ergonomie pour un informaticien, mais la sécurité et la simplicité pour l'ensemble de l'organisation.

Une amélioration récente du contexte

Sur le point technique le plus contesté — la consommation de la fenêtre de contexte — les deux camps s'accordent sur une évolution notable. Depuis les mesures initiales, la version actuelle de Claude Code a introduit un « chargement différé » des schémas d'outils MCP, ce qui réduit la consommation de contexte de plus de 85 %. Les définitions complètes ne sont plus chargées qu'à la demande, seuls les noms des outils étant initialement visibles. Cette mise à jour, reconnue par les auteurs de l'étude critique, répond en grande partie au problème de l'inflation du contexte. Les autres arguments sur la fiabilité, le débogage et l'architecture subsistent toutefois.

Entre mort annoncée et utilité réelle

Ni enterré ni triomphant, MCP semble se trouver à un carrefour. Les alternatives comme l'approche « Skills + CLI » sont souvent plus légères et plus rapides pour les développeurs isolés ou les petites équipes. En revanche, dans un contexte d'entreprise, où la sécurité, l'auditabilité et le déploiement centralisé sont primordiaux, MCP conserve une utilité certaine — en particulier pour les bases de données partagées ou les services sans interface en ligne de commande. Le protocole n'est pas mort, mais son avenir dépendra de sa capacité à résoudre les problèmes de performance résiduels tout en restant la couche de confiance que les organisations lui demandent d'être.