MCP : un système de plugins universel (par accident)

• USB-C ne vaut pas seulement pour la charge ou le transfert de fichiers, mais pour sa polyvalence qui lui permet de s’étendre à des usages très variés
• MCP (Model Context Protocol) a été conçu à l’origine pour les assistants IA, mais peut en pratique devenir un système de plugins universel reliant toutes les sources de données et tous les outils
• Comme le montre le cas de NFT Base64, un protocole peut s’étendre au-delà de son objectif initial pour stocker et exploiter directement des données du monde réel
• À mesure que les serveurs MCP se multiplient, chaque application peut intégrer facilement diverses fonctionnalités sans développement d’intégration séparé
• À l’image de l’USB-C, MCP peut devenir un « espace des possibles où tout peut se connecter », base d’innovations inattendues

---

MCP: An (Accidentally) Universal Plugin System (Or: The Day My Toaster Started Taking Phone Calls)

L’USB-C et son universalité inattendue

• Tout le monde voyait l’USB-C comme un simple moyen de charge ou de transfert de fichiers, mais sa structure lui permet de s’étendre à des usages très variés
• L’auteur cite l’exemple de son ami Rex, qui a branché un grille-pain à un moniteur, donnant ainsi au grille-pain une sortie HDMI, preuve des possibilités infinies de l’USB-C
• Cela tient au fait que l’USB-C est conçu de sorte que, tant que le connecteur correspond, on peut tout brancher sans trop se soucier des spécifications d’alimentation ou de données

Le principe de l’allume-cigare automobile

• L’allume-cigare d’une voiture était à l’origine destiné à allumer des cigarettes, mais il sert aujourd’hui de port d’alimentation universel pour toutes sortes d’usages
• Comme l’allume-cigare, un protocole ne limite pas les choix de l’utilisateur et autorise des usages variés
• MCP présente une extensibilité comparable

Redécouvrir MCP : un système de plugins universel par accident

• On présente souvent MCP (Model Context Protocol) comme un moyen pour des assistants IA, comme Claude, d’exploiter des données
• La documentation officielle indique aussi qu’il sert à « connecter de manière standard les modèles d’IA à plusieurs sources de données et outils »
• Mais si l’on retire l’élément IA, MCP devient un moyen de connecter « n’importe quoi » à différentes sources de données et à différents outils
• Il se transforme alors, indépendamment de son objectif initial, en protocole de connexion universel

The NFT Base64 Revelation

• À l’origine, les NFT servaient à référencer des images, mais à un moment donné, la référence elle-même est devenue la donnée
• L’intention initiale du protocole a changé, au point que la fiche de bibliothèque s’est mise à jouer le rôle du livre lui-même
• Il s’est transformé en outil capable de manipuler directement des données du monde réel, bien au-delà de son intention d’origine

Des effets de réseau que personne n’avait prévus

• Plus les serveurs MCP se multiplient pour l’IA, plus n’importe qui peut permettre à toutes les applications d’acquérir de nouvelles fonctionnalités sans développement supplémentaire
• Par exemple, si quelqu’un crée un serveur MCP pour Spotify, une application de sport pourrait générer automatiquement des playlists via MCP
• Cela crée des effets de réseau où des développeurs et des applications qui ne se connaissent pas se connectent naturellement, au bénéfice de tous
• Chaque serveur MCP peut être réutilisé comme plugin universel
• Sans que personne ne l’ait planifié, un écosystème universel de plugins se forme par accident

Le sens de l’USB-C et la philosophie de MCP

• On compare souvent MCP à l’USB-C de l’IA, mais ce qui rend l’USB-C spécial, ce n’est pas seulement d’être un simple port, c’est d’être un espace de possibilités où tout peut se connecter
• De même que l’USB-C peut accueillir l’alimentation, les données, la vidéo et d’autres fonctions encore inconnues, MCP ne se limite pas à « l’IA » : il joue le rôle d’une ouverture bien conçue pour les fonctionnalités, à laquelle n’importe qui peut connecter n’importe quelle capacité

The Part Where I Tell You I'm Building Something

• L’auteur développe actuellement une application de gestion du travail appelée APM (Actions Per Minute)
• APM fonctionne comme un système de plugins utilisant exclusivement des serveurs MCP
• Chaque fois qu’un utilisateur veut ajouter une fonction, il lui suffit de connecter un serveur MCP (par exemple : correcteur orthographique, commande automatique de café, réactions de personnage de jeu, etc.)
• L’application peut ainsi se transformer de manière fluide en des formes très diverses

The Toaster Protocol Principle

• Tous les grands protocoles finissent par créer de l’innovation en étant utilisés à des fins imprévues, différentes de leur intention initiale
  • HTTP : articles académiques → infrastructure de la civilisation
  • Bluetooth : kit mains libres → déverrouillage de porte d’entrée, etc.
  • USB : périphériques d’entrée → recharge de ventilateurs portables, etc.
• MCP aussi a été conçu à l’origine pour transmettre du contexte à l’IA, mais dans son essence, c’est un protocole qui connecte tout à tout
• L’auteur insiste sur le fait qu’il constitue la base d’un écosystème de plugins capable de produire des innovations imprévisibles
• Et même si cela n’a jamais été l’intention de départ, c’est exactement le genre d’approche qu’il faut dans une époque où l’on relie un grille-pain et un moniteur en HDMI

Conclusion

• PS : si vous fabriquez un ordinateur capable de diffuser une odeur de pain frais via un serveur MCP, contactez absolument l’auteur
• PPS : l’accès anticipé à APM est ouvert, et l’auteur encourage les idées originales et les expérimentations créatives
• (Quelque part, il existe sûrement un protocole utilisé exactement comme prévu. C’est très suspect.)

[a1eng0]

Les réponses d’un serveur MCP sont souvent en langage naturel, sans schéma prédéfini.

Il sera probablement difficile de traiter ce type de réponse de façon programmatique sans LLM.

[winterjung]

Pour information, la spécification mcp du 2025-06-18 a récemment ajouté les structured tool outputs, ce qui permet désormais de décrire un schéma de réponse. Comme vous l’avez dit, la plupart des outils mcp déjà implémentés sont probablement non structurés, mais cela semble prometteur pour les futurs outils mcp.

[a1eng0]

On se retrouve encore ici, hiver-san haha

Je n’avais pas réussi à suivre la spec du 250618. Merci !

[GN⁺]

Avis sur Hacker News

• J’ai vraiment le sentiment d’aimer cet article et le protocole MCP. Mais quand je vois MCP, ça me rappelle un peu les microservices et la SOA. Je crains qu’on ne soit en train de rejouer le cauchemar de créer de nouveaux points de défaillance. En même temps, j’ai aussi l’espoir que l’adoption des agents puisse rendre l’amélioration de la fiabilité plus naturelle

• Je suis d’accord avec les idées de l’article, et je trouve très amusant que l’auteur utilise MCP d’une manière un peu décalée. Le vrai cœur de cette réflexion, ce n’est pas simplement l’apparition d’un protocole qui permet de faire des choses inédites. En réalité, comme l’ont dit d’autres commentaires, MCP en lui-même n’est pas une idée particulièrement nouvelle ou intéressante. Ce qui est vraiment intéressant, c’est que l’engouement pour les agents IA remet l’interopérabilité au centre de l’attention, au point que le vendor lock-in commence à être perçu comme quelque chose de dépassé. Je ne sais pas combien de temps cela durera, mais en attendant, ça fait plaisir

  • Ça me rappelle l’époque de l’introduction de Winsock. À une époque, tout ce qui touchait au réseau sous Windows utilisait des interfaces propriétaires différentes. Puis est venu ce moment où plusieurs éditeurs se sont réunis pour décider de créer un standard commun bénéfique à tous. Voir Winsock sur Wikipédia
  • Le point essentiel, ce n’est pas seulement que l’interopérabilité soit devenue tendance ou que les connexions soient faciles. La vraie innovation, c’est que les LLM ont appris à manipuler des outils eux-mêmes. Il suffit de construire le backend, et le frontend n’est plus vraiment mon problème puisque l’IA s’en charge. Claude et Gemini sont aussi capables d’utiliser des outils par eux-mêmes si on leur donne simplement un objectif. Avant, il fallait toujours définir explicitement une procédure étape par étape pour obtenir le résultat souhaité, alors qu’aujourd’hui un LLM s’adapte bien mieux à des situations changeantes qu’un programme figé, et c’est un changement énorme
  • Il y a clairement un excès d’enthousiasme. Mais, à mon avis, les agents IA ont créé une vraie motivation pour l’interopérabilité. Avant, chacun pouvait travailler lentement dans son propre système et cela garantissait une certaine stabilité professionnelle, mais maintenant tout le monde veut tout connecter. C’est un peu comme si faire livrer des pizzas par le CEO pendant un hackathon revenait moins cher. Les agents dépendent de l’intégration. Ayant moi-même vécu la précédente vague d’innovation autour de l’intégration API, j’ai l’impression que le monde rattrape enfin son retard. J’espère que cette dynamique durera
  • Je ne suis pas totalement d’accord avec l’idée que l’engouement pour les agents IA entraîne une mode de l’interopérabilité et rend le vendor lock-in obsolète. Des outils récents très en vue comme Cursor n’utilisent MCP que dans un seul sens, sans exposer leur historique de conversation ni leur contexte vers l’extérieur. J’aime bien Cursor, mais partir d’un fork non open source de VS Code avec cette mentalité du « ne rien rendre » me semble nuisible pour la confiance des développeurs. En réalité, le lock-in reste très solide
  • Ironiquement, les restrictions récentes sur l’accès aux API se sont même renforcées à cause de l’entraînement des données pour l’IA. En fait, ce verrouillage des API existait déjà bien avant, et il y a aussi une vision sceptique selon laquelle tout pourrait se refermer très vite si la nouvelle tendance à l’ouverture ne suit pas le niveau actuel d’enthousiasme excessif

• L’auteur mise énormément sur l’universalité de MCP, mais honnêtement je me demande en quoi cela diffère vraiment de la notion même d’API. Si on remplaçait MCP par REST, est-ce que l’article changerait vraiment beaucoup ? On peut aussi voir des ressemblances avec les API des systèmes d’exploitation, POSIX ou les pipes Unix. Bien sûr, MCP est beaucoup plus simple et plus générique que tout cela. Mais la vraie solution n’est-elle pas de revenir aux fondamentaux et de créer des logiciels simples, plutôt que de produire sans cesse de nouvelles abstractions ?

  • MCP est différent de REST. J’ai plutôt l’impression que MCP est un protocole qui permet de découvrir dynamiquement des endpoints REST à l’exécution et de laisser l’utilisateur configurer lui-même quels endpoints REST utiliser. Par exemple, si une application doit lancer un morceau sur Spotify, elle utilisera évidemment l’API Spotify. Si on veut ensuite ajouter la prise en charge des titres de Sonofm, l’approche classique impose de modifier le code, ajouter des conditions, publier une nouvelle version, prévenir des mises à jour, etc. Avec MCP, ce genre de configuration peut se faire à l’exécution, ce qui donne une impression de bien meilleure extensibilité
  • La différence clé, c’est que MCP impose la description de soi dès le départ. REST a bien OpenAPI, mais c’est un ajout a posteriori et peu utilisé comme standard. MCP, au contraire, exige que la description soit publiée en premier, ce qui change l’accessibilité
  • Pour moi, la seule chose qui rend vraiment MCP nouveau, c’est qu’il impose la fourniture d’un schéma au niveau du protocole. Bien sûr, le fait d’avoir des structures de requête et de réponse cohérentes facilite aussi la gestion pour les bibliothèques qui encapsulent du typage dynamique avec du typage statique. En réalité, tout le monde faisait déjà quelque chose de similaire avec les API. On n’avait simplement pas réussi à s’accorder sur cette forme d’enveloppe. Le fait que la fourniture du schéma soit obligatoire, et que les modèles d’IA puissent l’utiliser immédiatement, explique sans doute son succès
  • Une grande différence entre MCP et REST, c’est l’existence d’une commande intégrée list-tools. Les API REST ont diverses façons d’énumérer des ressources, alors que MCP fournit une seule méthode standardisée
  • Une autre différence importante, c’est que MCP a une procédure de discovery intégrée directement dans le protocole. REST n’a rien qui permette d’indiquer au client quelles ressources sont disponibles ni même quelles capacités expose l’API

• Beaucoup disent que MCP est extraordinaire, mais j’ai l’impression de ne pas voir beaucoup de cas où l’on construit réellement quelque chose d’impressionnant avec. Ça me rappelle un peu la mode de la blockchain. Au fond, j’ai l’impression que MCP est une solution provisoire en attendant que l’IA devienne plus intelligente. D’ici deux ans, on évoluera peut-être naturellement vers un modèle où, au lieu de MCP, on injectera simplement la documentation des outils ou leur OpenAPI, et l’IA assimilera elle-même tout le contexte

  • Par exemple, je vois mal en quoi fournir uniquement la documentation d’Ableton Live aiderait Claude à composer directement un morceau
  • Peu importe à quel point les modèles progresseront, leur utilité restera très limitée tant qu’on ne leur donnera pas un accès déterministe aux outils et des informations directes sur l’état du monde. Et si on tient compte des questions de sécurité, on ne peut pas laisser un modèle envoyer librement des requêtes arbitraires en production sans contrôle. Je trouve l’emballement autour de MCP un peu excessif, mais le problème évoqué ici est malgré tout bien réel. Si ce protocole pousse les développeurs à exposer clairement leurs fonctionnalités via des API, ce serait très enthousiasmant
  • La mode de la blockchain et MCP sont assez différentes. J’étais moi aussi sceptique au début, mais dès qu’on implémente un peu un serveur MCP soi-même, on comprend que l’expérience n’a rien à voir. Avec l’IA conversationnelle ou vocale, les LLM actuels, MCP et toutes sortes d’outils et de fonctions, mélangés à des API et à des données/services privés, on a vraiment l’impression d’entrer sur une nouvelle frontière. Ce n’est pas parfait à 100 %, mais c’est déjà largement suffisant pour presque tous les cas d’usage réels, et cela risque de changer profondément la manière même de créer des applications
  • En pratique, je voulais savoir ce que les élus de mon État avaient fait cette semaine, et comme il n’existait pas de moyen simple de trouver cette information, j’ai entendu dire que MCP et l’API de congress.gov étaient une combinaison intéressante, alors j’ai créé un serveur MCP. Code publié ici. Aujourd’hui, je m’en sers vraiment très bien pour suivre en temps réel l’actualité du Congrès américain
  • Tant que l’architecture des modèles d’IA continuera d’évoluer, je pense qu’une couche intermédiaire de middleware, c’est-à-dire MCP, aura du mal à disparaître

• J’ai l’impression que la stratégie habituelle de Microsoft, « Embrace, Expand, Extinguish », s’applique aussi ici. Pour des raisons de stabilité du système et de sécurité, laisser des agents découvrir dynamiquement des outils sans aucune supervision augmente le risque de conflits. Il existe des alternatives comme PydanitcAI, mais au final Microsoft pousse officiellement MCP à la Build 2025 et entraîne l’industrie à son rythme. Anthropic a publié un standard avec des outils faibles et sans vraie gouvernance, ce qui facilite la prise de contrôle par Microsoft. L’étape suivante serait que Microsoft fasse de son propre registre le standard de fait de l’industrie, puis le combine à des commandes spécifiques à Windows. À la fin, le scénario serait que Microsoft définisse les critères de « sécurité » à son avantage et marginalise les concurrents

• Et si on retirait complètement la partie IA ? Je crains que si l’on dépend directement des serveurs MPC sans middleware IA, on se heurte immédiatement à des problèmes de rétrocompatibilité. En effet, les serveurs MCP supposent que l’appelant est un algorithme d’IA, ce qui signifie que des changements cassants peuvent survenir à tout moment dans les outils ou dans les schémas d’entrée/sortie

• J’ai pensé la même chose, mais au fond je me demande si la plupart des serveurs MCP ne sont pas simplement de nouveaux clients pour des API existantes. Par exemple, le serveur MCP de Kagi ne fait qu’appeler l’API Kagi. Dans ce cas, ne vaut-il pas mieux utiliser directement l’API ? De plus, on va se retrouver avec autant d’interpréteurs Python que de serveurs MCP dans le système ; je me demande donc si un service de « hosting » n’apparaîtra pas pour les regrouper et les bridger d’un coup

  • Si j’ai bien compris, MCP revient à ajouter un endpoint API /list-tools à une API existante. Tous les clients commencent par interroger /list-tools pour récupérer la liste des outils disponibles, puis appellent ensuite chaque API correspondante
  • Mon approche est la suivante : si une API dispose déjà d’une spécification OpenAPI, ne suffit-il pas de l’envelopper avec FastMCP ? En pratique, j’ai fait l’intégration avec Goose tout en gérant les demandes d’authentification, et au final Goose n’a qu’à envoyer des commandes curl vers les routes API existantes. Si la spécification OpenAPI est suffisamment bonne, MCP n’est peut-être pas indispensable. Bien sûr, s’il n’existe pas d’API préalable, il semble alors plus logique que le serveur MCP lui-même évolue pour implémenter directement le comportement principal

• Il y a beaucoup de scepticisme dans les commentaires, et je m’y retrouve. J’ai implémenté moi-même un serveur MCP la semaine dernière, et honnêtement je trouve exagéré de dire que c’est « bien conçu ». L’un des objectifs de MCP est d’être simple à créer, mais en pratique ce n’est pas si facile. Cela dit, l’important, c’est qu’en ce moment l’attention de très nombreux développeurs converge dans la même direction. Avec ce genre de momentum, la résolution des problèmes peut aller très vite. Il faut aussi une masse critique autour d’une idée pour qu’un écosystème se forme, et j’ai vraiment l’impression que ce point d’inflexion est en train d’arriver. Je souhaite à tout le monde patience et bonne chance

  • Avec la bibliothèque Python MCP, c’est vraiment très simple. Il suffit de mettre un décorateur sur une fonction et l’outil est immédiatement prêt. Moi non plus je ne connaissais pas du tout le protocole MCP, mais de cette façon ça fonctionne très bien. Bien sûr, si l’on doit implémenter directement le protocole, c’est peut-être une autre histoire
  • Un serveur MCP n’a qu’à réexposer une « API publique ou semi-publique existante ». L’idée selon laquelle cela devrait pouvoir se faire avec un minimum de changements sur les endpoints d’origine me paraît convaincante
  • Ce genre de tentative a déjà existé par le passé, mais au bout de quelques années les applications finissent par verrouiller leurs endpoints afin que seuls des serveurs spécifiques comme chatgpt ou claude puissent y accéder. L’interopérabilité, c’est aussi en réalité la portabilité de l’utilisateur, et dans les faits beaucoup d’entreprises technologiques préfèrent le lock-in et le monopole à cette portabilité

• Je veux souligner à quel point le fait d’abaisser la barrière d’entrée a toujours joué un rôle majeur dans l’adoption et la diffusion des technologies. MCP s’inscrit aussi dans cette continuité, et il ne faut pas le sous-estimer. Dans notre équipe aussi, quelqu’un sans absolument aucun bagage technique a pu utiliser directement un agent pour automatiser des tâches de partage de fichiers. Bien sûr, auparavant cela n’était possible qu’avec des centaines de langages de programmation, bibliothèques ou API, mais avec MCP, même des non-spécialistes peuvent résoudre le problème sans s’en soucier. En termes de performance, ce n’est pas ce qu’il y a de mieux, ni l’implémentation optimale, mais la valeur apportée par cette nouvelle manière de faire est sans précédent à notre niveau actuel de ressources et de technologie. C’est précisément cela le vrai point essentiel

  • Je pense que l’histoire selon laquelle un collègue non technicien aurait bien réussi seul à réorganiser un partage de fichiers est exagérée. À moins qu’il ne s’agisse de trier des milliers de fichiers, d’après mon expérience il est déjà très difficile d’obtenir ne serait-ce que la coopération des services concernés dans presque toutes les tentatives de réorganisation de partage de fichiers. Même les personnes directement concernées n’aiment pas ça quand ce n’est pas explicitement leur tâche. Il faut parfois mobiliser la direction pour obtenir un accord, ou s’asseoir ensemble pendant une heure rien que pour définir l’arborescence. Dans ce type de travail, 50 % relèvent de la politique entre services, 20 % de la mise à jour des procédures, 20 % de la formation, et seulement 10 % de problèmes techniques. J’ai vécu de grandes et petites catastrophes, ainsi qu’un chaos sans fin, donc j’ai du mal à croire que la réalité soit aussi simple, même si des outils IA rendent la création plus facile. Je parierais plutôt sur une opération de restauration de sauvegarde dans quelques mois

• La blague « J’aimerais que l’agent IA réponde aux ordres comme Peon dans Warcraft 3 », et ma réponse serait plutôt que je préfère faire du voilier

  • Je voudrais juste signaler que « I'd rather be sailing » est une réplique de Warcraft 2, alors que dans Warcraft 3 la réponse est « I'd rather be flying »