Un regard critique sur le MCP

• MCP (Model Context Protocol) fournit une méthode d’intégration standardisée permettant aux LLM d’interagir avec le monde extérieur
• Des standards similaires comme ACP d’IBM et A2A de Google ont récemment émergé, tandis que les implémentations de MCP et les outils associés se multiplient rapidement
• Toutefois, des pratiques d’ingénierie encore immatures sont pointées du doigt, notamment une conception confuse, une documentation insuffisante et l’absence de véritables spécifications de protocole
• Les modes de transport actuellement proposés, comme HTTP+SSE et Streamable HTTP, accroissent la complexité et les problèmes de sécurité, et l’usage de WebSocket est recommandé comme alternative
• Les protocoles les plus récents ajoutent aussi une complexité excessive et incohérente autour de l’autorisation et de la gestion des sessions

---

Examen du MCP et des évolutions récentes

• MCP est un protocole ouvert conçu pour standardiser la manière dont les applications fournissent du contexte aux grands modèles de langage (LLM)
• Depuis un mois, MCP s’impose rapidement comme un standard clé pour transformer les LLM en agents, avec une adoption et des implémentations en forte accélération
• Des standards plus orthodoxes poursuivant des objectifs similaires apparaissent aussi rapidement, comme ACP d’IBM ou A2A de Google

Problèmes de pratiques d’ingénierie et de spécification du protocole

• Le faible niveau des implémentations réelles et de la documentation apparaît à de nombreux endroits
• Les grandes entreprises technologiques investissent massivement dans l’entraînement des modèles, mais leurs SDK et leur documentation restent souvent médiocres, ce qui crée de la confusion chez les utilisateurs
• MCP montre lui aussi des problèmes comparables, avec certaines décisions de conception peu rationnelles et un manque de spécifications, d’exemples et de lignes directrices

Discussion sur les protocoles de transport

Mode de transport stdio

• Stdio est la méthode traditionnelle consistant à relier directement, en local, un serveur MCP et un client via des pipes (stdout, stdin)
• Cette approche réduit les traitements complexes liés aux sockets et les problèmes dépendants de l’OS, tout en permettant une configuration d’environnement simple via les variables d’environnement et les flux d’entrée/sortie

Modes HTTP+SSE / Streamable HTTP

• Dans l’idée de s’adapter à l’ère du web, les approches HTTP+SSE et Streamable HTTP ont été adoptées pour les usages basés sur HTTP
• Mais au lieu de remplacer WebSocket, ces approches introduisent davantage d’ambiguïtés, de confusion de conception et de complexité
• Une même session et une même connexion peuvent être créées ou fermées de plusieurs façons, ce qui impose une lourde charge au serveur en matière de gestion d’état et de sécurité

Difficultés observées dans les implémentations serveur/client MCP

• Le manque de support est particulièrement visible dans plusieurs langages, notamment avec l’absence d’un SDK Go officiel
• La documentation et les spécifications étant floues, il faut souvent implémenter en passant par de la rétro-ingénierie
• Bien que la plupart des serveurs d’exemple soient basés sur Python et JavaScript, les problèmes de dépendances et de portabilité compliquent leur adoption en environnement de production
• Lors de l’implémentation d’un serveur, SSE/Streamable HTTP tente d’imiter les sockets, mais en pratique il est difficile de maintenir de façon cohérente les sessions et l’état des connexions, et une infrastructure séparée comme une file de messages devient nécessaire

Structure et problèmes de HTTP+SSE et de Streamable HTTP

Mode HTTP+SSE

• Le client ouvre une session SSE avec le serveur puis envoie ses requêtes d’écriture vers un endpoint distinct ; le serveur répond alors avec un code 202 et transmet la réponse via la connexion SSE existante
• Cela exige la gestion des sessions et la synchronisation de l’état, mais la documentation sur ce processus est insuffisante et la complexité opérationnelle très élevée

Mode Streamable HTTP

• La création de session, l’ouverture de SSE et la transmission des réponses s’y mélangent selon plusieurs variantes, si bien qu’un même flux requête-réponse manque de cohérence
• La coexistence de multiples mécanismes de gestion d’état, de divers endpoints et de différentes méthodes via les headers crée un obstacle majeur à l’implémentation réelle et à l’extensibilité

Implications générales

• Avec l’augmentation de la complexité technique, la charge cognitive et de maintenance pour les développeurs augmente, et des problèmes de compatibilité incohérente et de comportements imprévisibles apparaissent entre les différentes implémentations serveur et client
• Le serveur doit suivre l’ensemble des états et des situations de connexion, et dans un environnement distribué il devient encore plus difficile d’assurer une montée en charge efficace et une synchronisation de l’état

Implications de sécurité

• La diversité et la granularité des modes de connexion et de session augmentent les vulnérabilités de sécurité liées à la gestion d’état, comme le détournement de session, les attaques par rejeu et le déni de service (DoS)
• La multiplication des points d’entrée et des modes de réponse élargit la surface d’attaque et peut permettre de dissimuler des activités malveillantes dans des flux inattendus

Confusion autour du protocole de gestion des autorisations

• La spécification actuelle applique des règles incohérentes, par exemple en imposant OAuth2 uniquement pour le transport HTTP, tandis qu’en STDIO elle laisse l’usage de variables d’environnement au libre choix de l’implémentation
• Il existe donc une confusion et une incohérence, notamment sur la raison pour laquelle seul le transport HTTP impose une implémentation complexe d’OAuth2

Pistes d’amélioration

• Il faudrait simplifier autour d’un unique protocole JSON RPC, avec comme transports principaux Stdio et WebSocket
• Une approche souhaitable consisterait à faire correspondre les variables de l’environnement Stdio aux headers dans l’environnement HTTP, et les entrées/sorties aux flux bidirectionnels de WebSocket
• Cela permettrait d’éliminer le suivi de session inutile, la gestion d’état superflue et la multitude de traitements d’exception
• WebSocket devrait devenir l’option standard pour tous les transports basés sur HTTP, ce qui permettrait aussi de résoudre les problèmes complexes de synchronisation d’état

Comparaison avec les protocoles alternatifs et tendances du marché

• ACP d’IBM et A2A de Google offrent, pour l’interopérabilité entre agents, une conception du transport plus simple ainsi que des fonctions de découverte d’agents
• Mais dans le fond, ils restent pour la plupart au niveau d’outils séparés pouvant être intégrés dans un environnement construit autour de MCP
• Comme l’apparition continue de nouveaux protocoles risque d’aboutir à une prolifération des standards, il est important pour la croissance du secteur de privilégier avant tout la simplicité du transport

[GN⁺]

Avis Hacker News

• Je suis convaincu que si la documentation rédigée par les vendeurs de LLM est si confuse, c’est précisément parce qu’ils utilisent des LLM pour l’écrire ; c’est une très mauvaise approche, et utiliser un LLM pour travailler sur une spécification est bien pire encore que de l’utiliser pour écrire de la bonne documentation ; le processus même d’écriture d’une spec est essentiel, et il est important que des concepteurs humains examinent les défauts, les manques et les cas limites avec réflexion, or je ne vois guère de traces de cette réflexion humaine dans la spec MCP ; son style plat caractéristique, sa dispersion et sa structure centrée sur les listes ressemblent exactement à un texte écrit par un LLM
  • La documentation de DeepSeek a plutôt pour problème d’être truffée de fautes d’orthographe et de grammaire ; c’est vraiment étrange qu’une entreprise qui travaille avec le langage toute la journée, et qui a même eu à un moment l’un des meilleurs LLM anglophones du monde, ne soit pas capable de produire une documentation d’un niveau professionnel
  • Moi aussi, j’ai fortement l’impression que cette spec a été écrite par un LLM ; tous les indices vont dans ce sens ; je soupçonne que la plupart des produits sont déjà conçus pour l’IPO, afin de montrer aux investisseurs qu’ils produisent des résultats « plausibles » en faisant une moyenne de l’existant
  • Si c’est vrai, c’est vraiment regrettable ; Anthropic compte pourtant beaucoup de gens brillants, et c’est dommage de voir ce genre de chose arriver sur un composant clé d’un écosystème important
  • Je viens seulement de réaliser que les vendeurs d’IA pour le code ont peut-être intérêt à rendre la documentation volontairement incompréhensible : produire un code que les humains ne comprennent pas et que seule leur IA peut interpréter, afin de rendre les utilisateurs totalement dépendants de leur service d’IA ; s’ils ne parviennent pas à remplacer complètement les vrais programmeurs dans les deux ans, cette stratégie finira par faire disparaître les consommateurs et détruire leur propre marché ; il ne restera qu’un énorme tas de code impossible à convertir entre humains et IA
  • Quand je lis une prose écrite par un LLM, je constate que ce n’est pas seulement mon problème si ma concentration se brise : ces textes répétitifs, sans contexte, produits par des machines, manquent de pensée profonde et finissent même par provoquer une fatigue émotionnelle ; et quand ce même type de LLM se met à écrire des specs techniques, du contenu que même l’auteur ne comprend pas finit par s’y glisser inconsciemment ; cela m’inquiète de plus en plus
  • La documentation de DeepSeek ne m’a pas semblé mauvaise dans l’ensemble ; elle donne l’impression d’avoir été bricolée rapidement, mais le niveau reste correct ; cela montre qu’il peut exister des exceptions à l’idée selon laquelle toute documentation générée par LLM est forcément mauvaise
• En ce moment, le domaine des LLM imite les paradigmes logiciels à toute vitesse, comme s’il utilisait un cheat code ; il existe déjà de nombreux précédents pour exposer des fonctions distantes, comme DLL, gRPC, SOAP, IDL, dCOM, etc., mais le camp des LLM semble à peine conscient de leur existence ; j’espère que cela gagnera en maturité avec le temps, mais il faudra de toute façon traiter les problèmes restants
  • Dans quelques mois de plus, cela gagnera sûrement en maturité, mais cela me rappelle l’écosystème Python des débuts, où les erreurs se sont enracinées dans les couches basses de la stack et où tout le monde a continué à empiler de nouveaux outils par-dessus ; cette fois, il est d’autant plus regrettable que l’écosystème IA reproduise les mêmes erreurs alors que l’histoire de ces échecs passés existe déjà
  • Quand j’ai découvert MCP pour la première fois, j’ai pensé à COM/DCOM, et ça m’a rappelé l’époque du DLL Hell ; je vais regarder comment MCP évolue
  • Je n’ai toujours pas trouvé d’explication me permettant de comprendre précisément ce qu’est MCP, et je me demande comment on appellerait cela avec le vocabulaire des anciens langages de développement
  • Je voudrais souligner que, dans ce type de protocole strict et déclaratif, on perd l’espace de signification potentiel et les forces sémantiques des LLM ; il pourrait être plus intuitif de simplement placer un fichier agents.json à la racine web et de laisser les agents se débrouiller via une conversation sémantique automatique ; au final, HTTP deviendrait l’entrée/sortie standard des agents
  • Je pense que tous les exemples donnés sont pertinents
  • Je me demande si MCP est basé sur JSON-RPC
• Je suis d’accord avec l’ensemble du billet, notamment avec cette expérience frustrante de ne pas avoir réussi à trouver de vraies informations sur le site de MCP ; les RFC sont difficiles à lire, mais c’est bien mieux que « utilisez simplement le SDK »
  • J’aimerais que davantage de gens prennent conscience de l’importance de ce billet ; il faudrait mettre un instant en pause l’adoption de MCP et vérifier à nouveau s’il repose vraiment sur des bases techniques solides ; il y a beaucoup d’enthousiasme, mais dès qu’on entre sérieusement dans l’implémentation, la déception arrive ; plusieurs décisions, notamment autour des WebSockets et d’autres aspects du cœur, paraissent discutables, et l’ensemble donne parfois l’impression d’un bricolage fait à la hâte, même si ce n’est pas entièrement le cas
  • C’est dommage qu’il n’y ait pas de spec claire sur le site ; on dirait que la moitié de la spec a été générée par Sonnet, et le fonctionnement réel du protocole n’est pas décrit clairement ; à côté de ça, la spec GraphQL est bien mieux rédigée
• Aujourd’hui, la majorité du travail dans l’IA est surtout assurée par des mathématiciens, des scientifiques (des données), des étudiants et des passionnés amateurs ; vu avec les critères d’ingénieurs logiciel professionnels, beaucoup de choses n’ont pas plus de maturité qu’un projet du week-end
  • Pour ma part, je pense que des ingénieurs logiciel professionnels font bel et bien une grande partie du travail
• MCP aurait dû partir dès le départ sur du HTTP stateless ; la plupart des serveurs n’ont pas besoin de conserver un état, et il suffit de stocker l’état globalement ou d’avoir un simple identifiant de session
  • Je ne comprends pas la structure réelle des interactions de MCP ; j’aimerais savoir pourquoi ce n’est pas stateless et pourquoi il faut garder une connexion ouverte
  • Je n’ai pas beaucoup d’expérience personnelle, mais si l’on ferme la connexion après une requête, il faut se reconnecter pour la suivante ; garder ou non une session ouverte dépend de nombreuses variables, comme les habitudes d’utilisation ou la consommation mémoire
• Je construis un service MCP basé sur Ruby on Rails, ninja.ai ; c’est un app store qui installe des serveurs MCP en un clic ; il installe les serveurs Model Context Protocol sur l’appareil client à l’aide de Tauri ; il fournit aussi des serveurs MCP cloud via Rails ; je suis critique envers HTTP+SSE et Streamable HTTP ; WebSockets est mieux adapté aux communications bidirectionnelles en temps réel, et la prise en charge SSE de Rails est limitée, ce qui m’a conduit à migrer les endpoints vers le serveur web Falcon ; je me demande pourquoi les ingénieurs de Shopify ont choisi Streamable HTTP ; c’est peut-être dû à des contraintes d’infrastructure ou de déploiement ; il faut aussi noter que la couche de transport MCP est abstraite, ce qui laisse tout à fait la porte ouverte à de futures implémentations en WebSockets ou WebRTC
• Je suis l’opérateur de l’un des registres MCP (glama.ai/mcp/servers) ; je suis partiellement d’accord avec l’auteur, mais le protocole est encore à un stade très précoce et peut beaucoup évoluer ; il a attiré bien plus d’attention que prévu, passant très vite de quelques dizaines de serveurs à plusieurs milliers, même si seule une partie fonctionne réellement, ce qui me prend beaucoup de temps à filtrer ; c’est un effet du fait que MCP a attiré l’attention du grand public avant d’être mûr ; malgré cela, l’écosystème — frameworks de code, registres, clients compatibles MCP — se développe à une vitesse étonnante ; voir un tel changement en à peine six mois est sans précédent ; si cette tendance continue, je pense que les perspectives sont bonnes ; je fournis aussi une collection de ressources utiles pour les débutants
  • Si l’on commet des erreurs au début de la conception du protocole, il faut ensuite les traîner pour toujours ; il faut donc construire la spec avec humilité ; une structure à la Rube Goldberg comme SSE peut très bien devenir un défaut permanent qu’on ne corrigera jamais ; à l’échelle entreprise, tout changement cassant dans le protocole est difficile, donc on peut rester longtemps prisonnier des décisions initiales
  • Le protocole MCP lui-même, bon, il est naturel qu’il continue à évoluer avec le temps ; ce serait plus étrange d’en attendre un niveau de finition parfait dès le départ ; surtout, la standardisation des API agentiques est un changement vraiment puissant ; il faut l’avoir vécu pour mesurer à quel point c’est concret de pouvoir écrire et déployer du code que l’IA reconnaît immédiatement et utilise automatiquement
  • Ce qui m’inquiète, c’est qu’à ce rythme, MCP n’adopte trop tôt un design de couche de transport qui devra durer très longtemps ; cela me rappelle les standards fragmentés des browser wars des années 90, qui ont mis très longtemps à se résorber, un peu comme IE11 qui a survécu bien trop longtemps
• La controverse autour de l’authentification a déjà commencé à être traitée ; en collaboration avec Anthropic et la communauté sécurité, la séparation des rôles entre resource server (RS) et authorization server (AS) a été mise en œuvre dans MCP ; en attendant la formalisation de la nouvelle version du protocole, un projet de spec a été publié provisoirement
  • Je me demande quelle proportion de la spec MCP provient d’une sortie de LLM ; je me demande si ces signaux d’alerte répétés sont quelque chose qu’on perçoit instinctivement
  • J’essaie d’être neutre, mais on dirait qu’ils ont juste grossièrement copié le brouillon OAuth, et je n’aime pas cette structure où, dès qu’on utilise HTTP, il faut suivre cela sans avoir le choix ; en réalité, on aurait pu formuler beaucoup plus clairement le fait que le client comme le serveur puissent prendre en charge OAuth2 de manière optionnelle
• À propos du lancement de Streamable HTTP pour MCP, j’ai déjà ouvert un ticket pour demander si tout ne pourrait pas simplement être ramené à de simples requêtes HTTP ; la spec MCP est prometteuse comme solution générique pour connecter des LLM à des outils, mais dans la pratique elle se heurte à de nombreuses difficultés : authentification, streaming, commandes personnalisées selon les outils, vérification de la fiabilité des outils, etc. ; je trouve qu’en pratique une intégration par simple API REST est plus simple ; OpenAI et Gemini ont aussi annoncé vouloir adopter MCP, mais je pense que la spec va vite se heurter à des désaccords sur des couches qu’elle ne souhaite pas couvrir, comme l’UI ou les interactions, ce qui finira soit par ne pas correspondre à leur marque, soit par créer des problèmes comme le vol d’authentification
  • Même si Anthropic construit MCP, sa taille reste nettement inférieure à celle de ChatGPT ; je me demande si de grandes entreprises comme OpenAI ou Google accepteront durablement qu’une spec définie par une équipe externe fixe les limites de l’expérience utilisateur ; il existe déjà le précédent des plugins ChatGPT, qui ont échoué moins à cause de l’ingénierie qu’à cause des limites de l’expérience grand public ; malgré tout, je veux bien croire à la force d’une communauté solide
  • Après avoir publié le billet, j’ai moi-même laissé un ticket sur un problème similaire ; c’est vraiment crucial, et une erreur serait difficile à rattraper
• Je trouve étrange l’ampleur prise par MCP, mais c’est la tendance du moment ; j’aimerais entendre en quoi MCP est meilleur que la spec OpenAPI
  • À mon avis, l’essentiel de la popularité de MCP vient du fait que l’usage des outils par les LLM s’est récemment vraiment amélioré ; les plugins OpenAI de 2023 ont échoué parce qu’à l’époque les LLM n’étaient pas encore assez fiables pour l’usage d’outils, alors que MCP arrive avec un bien meilleur timing
  • Le fait qu’il soit très facile de démarrer un serveur MCP, avec une barrière d’entrée faible, est aussi un facteur important ; quand les outils se multiplient, la quantité de texte envoyée au LLM augmente aussi, mais si l’on fournit de l’OpenAPI avec les détails des endpoints individuels et des messages de description, Claude peut tout à fait bien s’intégrer
  • L’une des raisons importantes de MCP, c’est qu’OpenAPI est une documentation statique et que le LLM doit prendre en charge tout le processus de génération des requêtes, alors qu’un serveur MCP réduit cette charge grâce à l’abstraction ; au final, c’est plus simple, plus rapide et plus sûr du point de vue du LLM
  • Je ne considère pas MCP comme parfait, mais il présente quelques aspects plus adaptés aux LLM qu’OpenAPI ; d’abord, les outils MCP peuvent être spécifiés de façon bien plus courte et simple, alors que les specs OpenAPI sont trop volumineuses et consomment trop de contexte LLM ; le LLM ne fabrique pas réellement les appels, il ne fait que générer du texte de sortie, donc l’approche MCP est plus naturelle ; et MCP est bien plus flexible face aux ajouts ou modifications d’outils grâce à sa structure dynamique, ce qui dépasse les limites statiques d’OpenAPI ; bien sûr, il y a aussi des problèmes évidents, en particulier sur la couche de transport, qui a encore de la marge de progression ; la bibliothèque de référence est également plutôt bien implémentée