Pourquoi MCP a toujours été une mauvaise idée

Récemment, j'ai assisté à un événement d'une journée entier centré sur les dernières nouveautés du monde MCP. Bien que tous les présentateurs étaient excellents et semblaient passionnés par leur travail, je suis honnêtement fatigué de MCP. C'est un protocole horrible conçu pour une époque où les LLM n'étaient pas si intelligents, et nous l'avons dépassé.

Brève histoire

MCP a été publié en novembre 2024 par l'équipe Anthropic en tant que protocole conçu pour aider les agents à se connecter à des services et sources de données externes. Les modèles de l'époque étaient encore relativement primitifs, du moins comparés à ce que nous avons maintenant. Nous n'avions même pas encore Claude Code, et les flux de travail agentiques à usage général étaient bien moins fiables. Les utilisateurs ont commencé à voir l'utilité de donner à leurs modèles d'IA un accès aux services externes. Cela a permis un niveau de productivité que nous n'avions jamais vu auparavant. Nous avons vu une explosion de l'adoption de MCP, coïncidant avec une croissance similaire, sinon plus explosive, de l'adoption des LLM dans toute l'économie. Au fil du temps, MCP a continué d'évoluer sous la direction d'Anthropic avant d'être éventuellement donné à la Agentic AI Foundation, sous la Linux Foundation, en 2025.

Le complexe industriel MCP

Avec l'énorme croissance de l'adoption, les utilisateurs ont commencé à ajouter de nombreux serveurs MCP à leurs configurations, et ils ont commencé à rencontrer le problème de l'enflure du contexte. Chaque serveur viendrait avec plusieurs outils, chacun avec son propre schéma, ce qui a commencé à surcharger le contexte de tous ces modèles. Les développeurs de Harness ont trouvé de nombreuses astuces pour contourner cela, y compris les modèles génériques de recherche/exécution maintenant offerts par des plateformes comme Composio, Mint MCP et Pipedream. Ils résolvent tous efficacement le problème d'avoir un seul endroit pour mettre vos identifiants pour les divers services externes et donner à votre agent un ensemble minimal d'outils (pour réduire l'enflure du contexte) qu'il peut utiliser pour y accéder. Je veux clarifier que c'est une bonne chose, à court terme.

Avec tout ce que nous avons construit autour de MCP, ce que nous n'avons pas pris en compte, ou peut-être ignoré, c'est que les modèles s'amélioraient. Nous avons maintenant des systèmes entiers dédiés à la surveillance des serveurs MCP, s'assurer que les réponses sont bonnes, s'assurer que les agents peuvent accéder facilement aux outils, comprendre les schémas, et déterminer ce que nous devons donner aux agents pour qu'ils puissent faire le bon appel au bon moment.

Surprise, surprise, les grands laboratoires avaient raison

Les modèles se sont améliorés. Ils sont maintenant capables d'exécuter du code sur un ordinateur, de raisonner sur de grandes bases de code, et d'agir généralement de manière beaucoup plus autonome que jamais. Une grande partie de ce travail consistait à écrire/exécuter des scripts à des fins de codage. Un effet secondaire (en est-ce un ?) est qu'ils sont maintenant bons pour appeler des API directement. Ils peuvent écrire des scripts, composer plusieurs services différents, et appeler des API qu'ils n'ont jamais vues auparavant, le tout dans des flux de travail utiles avec une intervention minimale de la part de l'utilisateur.

Les LLM sont devenus si bons à cela que Cloudflare a même lancé Code Mode, une meilleure façon d'utiliser MCP en faisant composer aux LLM les divers appels en scripts qui peuvent être exécutés dans un bac à sable. Mais encore mieux que cela, les LLM ont découvert comment utiliser la commande --help pour découvrir les CLI, donc ils n'ont plus besoin de serveurs MCP pour accéder à de nombreux services disponibles via des API documentées ou des CLI. La plupart des serveurs MCP de services distants enveloppent en fin de compte des API qui existent déjà.

Et maintenant ?

Nous supprimons la plupart de nos serveurs MCP. C'est tout. Les agents avec un accès au terminal peuvent remplacer la plupart des serveurs MCP et sont souvent plus capables.

Il reste encore quelques problèmes, comme les CLI qui retournent des réponses lisibles par machine (JSON/XML, etc.), qui ont tendance à être très verbeuses et lourdes en utilisation de tokens, mais nous avons des moyens de corriger cela. Une grande partie de l'alternative existe déjà : des API HTTP documentées, une négociation de contenu standard, et des mécanismes d'authentification matures. Nous devrions commencer à standardiser la façon dont les agents utilisent les API HTTP directement. Par exemple, les clients agents pourraient joindre des en-têtes pour s'identifier comme agents, et les serveurs pourraient leur envoyer automatiquement les données de réponse en Markdown ou en texte au lieu de HTML ou....