Le créateur de MCP parle de l'origine, des avantages architecturaux et de l'avenir de MCP
TechFlow SélectionTechFlow Sélection
Le créateur de MCP parle de l'origine, des avantages architecturaux et de l'avenir de MCP
L'article le plus intéressant à lire sur MCP.
Dédié à des analyses Web3 approfondiesAuteur : FounderPark
Le protocole MCP, publié l’année dernière par Anthropic, est devenu soudainement l’un des protocoles les plus populaires dans le domaine de l’IA cette année grâce à la vague d’enthousiasme suscitée par Manus et les Agents. Des géants comme OpenAI, Microsoft et Google ont rapidement annoncé leur soutien au protocole, suivi par Alibaba Cloud Bailing et Tencent Cloud en Chine qui ont lancé des plateformes permettant une mise en œuvre rapide.
Cependant, ce succès n’est pas sans controverse : beaucoup remettent en question la différence réelle entre MCP et les API traditionnelles, critiquent les ingénieurs d’Anthropic pour leur manque apparent de maîtrise des protocoles Internet, ou encore soulignent les problèmes de sécurité liés à la simplicité du protocole.
Qui de mieux placé que les créateurs mêmes du protocole MCP pour répondre à ces questions ?
Dans un récent épisode du podcast Latent Space, les hôtes ont invité Justin Spahr-Summers et David Soria Parra, deux ingénieurs d’Anthropic à l’origine du protocole MCP, pour discuter en détail de ses origines, de sa philosophie, de son objectif initial, de ses différences avec les API existantes, ainsi que des moyens d’améliorer l’utilisation des outils via MCP. Une conversation riche en informations — à lire absolument et à garder sous la main.
Présentation des intervenants :
-
Alessio Fanelli (animateur) : associé et CTO chez Decibel
-
swyx (animateur) : fondateur de Small AI
-
David Soria Parra : ingénieur chez Anthropic
-
Justin Spahr-Summers : ingénieur chez Anthropic
Résumé (TLDR) :
-
L'idée du protocole MCP a surgi lors d’un projet interne chez Anthropic autour du LSP (Language Server Protocol). Inspirés par ce dernier, les deux ingénieurs se sont demandé s’il était possible de créer un système similaire afin de standardiser la communication entre « applications IA » et leurs « extensions ».
-
Le principe fondamental de conception de MCP est que le concept d’outil ne se limite pas à l’outil lui-même, mais est étroitement lié à l’application cliente et donc à l’utilisateur. Grâce à MCP, l’utilisateur doit conserver un contrôle total. Le fait qu’un modèle « contrôle » un outil signifie simplement que c’est le modèle qui décide de l’appeler, et non l’utilisateur (sauf dans un but de suggestion).
-
Les API ouvertes et MCP ne sont pas opposées, mais complémentaires. Le choix dépend de la tâche : si l’on vise des interactions riches entre applications IA, MCP est plus adapté ; si l’on souhaite que le modèle puisse facilement lire et interpréter une spécification d’API, alors les API ouvertes sont préférables.
-
Pour construire rapidement un serveur MCP, l’assistance par IA est une excellente approche. En phase initiale, insérer des extraits du SDK MCP dans le contexte d’un LLM pour qu’il aide à construire le serveur donne souvent d’excellents résultats. Les détails peuvent être affinés plus tard. Il s’agit d’une méthode efficace pour implémenter rapidement une fonctionnalité de base puis itérer. Par ailleurs, l’équipe MCP d’Anthropic accorde une grande importance à la simplification du processus de création de serveurs afin de faciliter l’implication des LLM.
-
L’avenir des applications IA, des écosystèmes et des Agents tend vers la persistance d’état (Statefulness), un sujet particulièrement controversé au sein de l’équipe MCP d’Anthropic. Après plusieurs discussions et itérations, la conclusion est que même si l’avenir semble prometteur pour Statefulness, il ne faut pas s’éloigner radicalement des paradigmes actuels. Un équilibre doit être trouvé entre la vision de Statefulness et la complexité opérationnelle.
Founder Park construit actuellement une communauté pour développeurs. Nous invitons tous les développeurs et entrepreneurs curieux, prêts à tester activement de nouveaux modèles et technologies, à rejoindre notre groupe. Veuillez scanner le code QR ci-dessous pour remplir en détail les informations sur votre produit/projet. Après vérification, un membre de l’équipe vous ajoutera au groupe.
Une fois dans le groupe, vous aurez accès à :
-
Des échanges techniques concentrés sur les principaux modèles (comme DeepSeek, etc.) ;
-
Des opportunités de mise en relation avec des fournisseurs d’API, de cloud et de modèles ;
-
Une visibilité accrue : Founder Park mettra volontiers en avant vos produits ou cas intéressants.
01 Comment le protocole MCP est-il né ?
swyx (animateur) : Pour commencer, qu’est-ce que MCP ?
Justin : Le Model Context Protocol (MCP), ou protocole de contexte du modèle, est essentiellement une architecture que nous avons conçue pour aider les applications IA à s’étendre ou à intégrer des écosystèmes de plug-ins. Concrètement, MCP fournit un protocole de communication permettant aux applications IA (appelées « clients ») et aux diverses extensions externes (appelées « serveurs MCP ») de collaborer. Ces « extensions » peuvent être des plug-ins, des outils ou d’autres ressources.
L’objectif de MCP est de permettre aux développeurs d’applications IA d’intégrer facilement des services externes, des fonctionnalités ou davantage de données, enrichissant ainsi les capacités de leurs applications. La notion de « client-serveur » dans notre terminologie vise surtout à souligner le mode d’interaction, mais il s’agit fondamentalement de créer une interface universelle pour rendre les applications IA plus extensibles.
Il est toutefois important de préciser que MCP se concentre sur les applications IA, et non sur les modèles eux-mêmes — une confusion fréquente. D’ailleurs, nous approuvons l’analogie selon laquelle MCP serait le port USB-C des applications IA : une interface universelle reliant tout l’écosystème.
swyx (animateur) : Le fait que client et serveur soient bidirectionnels, comme un port USB-C, est très intéressant. De nombreux chercheurs et projets open source explorent cette piste. Il me semble qu’Anthropic fait preuve d’un engagement bien plus fort que d’autres laboratoires envers les développeurs. Est-ce dû à des pressions externes, ou bien l’idée est-elle née spontanément entre vous deux dans une pièce ?
David : En réalité, c’est presque ça : l’idée est née spontanément entre nous deux. Ce n’était pas prévu dans une stratégie globale. J’ai rejoint Anthropic en juillet 2024, principalement pour travailler sur les outils internes de développement. Très vite, je me suis interrogé sur la manière d’aider davantage d’employés à intégrer profondément nos modèles, qui sont excellents et ont un bel avenir — autant les utiliser pleinement.
Dans mon travail, vu mon expérience antérieure dans les outils de développement, j’étais rapidement frustré : d’un côté, Claude Desktop avait des fonctionnalités limitées et ne pouvait pas s’étendre ; de l’autre, les IDEs manquaient des fonctionnalités pratiques de Claude Desktop. Je passais donc mon temps à copier-coller entre les deux. Au fil du temps, j’ai réalisé que c’était un problème de type M×N — plusieurs applications face à plusieurs intégrations — et qu’un protocole unique pourrait y remédier. À cette époque, je travaillais aussi sur un projet interne lié au LSP (Language Server Protocol), sans grand progrès. En combinant ces idées, après quelques semaines de réflexion, j’ai eu l’intuition : Et si on créait quelque chose comme le LSP ? Standardisons la communication entre « applications IA » et leurs « extensions ».
J’ai alors partagé cette idée avec Justin, qui s’y est immédiatement intéressé, et nous avons commencé à construire ensemble.
De l’idée à la première intégration, cela a pris environ six semaines. Justin a fait un gros travail sur l’intégration initiale dans Claude Desktop, tandis que moi, j’ai mené plusieurs validations conceptuelles dans les IDEs pour démontrer comment le protocole pouvait fonctionner. Avant la publication officielle, en examinant les dépôts de code, on peut retrouver beaucoup de traces. Voilà l’histoire de la genèse de MCP.
Alessio (animateur) : Quel était le calendrier ? Je sais que la date de sortie officielle était le 25 novembre. Quand avez-vous commencé ce projet ?
Justin : Vers juillet, juste après que David a eu l’idée, j’ai été enthousiaste et nous avons commencé à construire MCP. Pendant les premiers mois, comme il fallait poser toutes les bases — protocole de communication, client, serveur, SDK — le progrès a été lent. Mais dès qu’on a pu faire communiquer des éléments via le protocole, cela est devenu passionnant, ouvrant la voie à des applications incroyables.
Plus tard, nous avons organisé un hackathon interne où des collègues ont créé un serveur MCP pour contrôler une imprimante 3D, ou encore une extension avec fonction « mémoire ». Ces prototypes ont connu un grand succès, renforçant notre conviction sur le potentiel de cette idée.
swyx (animateur) : Revenons à la construction de MCP. Ce que nous voyons aujourd’hui est le résultat final, clairement inspiré du LSP — vous l’avez d’ailleurs reconnu. Pouvez-vous parler du volume de travail ? Était-ce principalement du codage, ou beaucoup de conception ? J’ai l’impression que la conception a pris beaucoup de place, notamment le choix de JSON-RPC, le niveau d’inspiration tiré du LSP, etc. Quelles parties ont été les plus difficiles ?
Justin : Nous avons beaucoup tiré du LSP. David, expérimenté dans les outils de développement, connaissait bien le LSP, alors que moi, spécialisé plutôt en produits ou infrastructures, j’en entendais parler sérieusement pour la première fois.
Sur le plan des principes de conception, le LSP résolvait justement le problème M×N mentionné par David. Avant lui, chaque IDE, éditeur et langage de programmation vivait en silo : impossible d’avoir le support Java de JetBrains dans Vim, ni le support C de Vim dans JetBrains. Le LSP a introduit un langage commun permettant à tous de « parler ». Il a uniformisé le protocole, de sorte que chaque paire « éditeur-langage » n’a plus besoin d’être implémentée indépendamment. Notre objectif était similaire, mais dans le contexte « application IA – extension ».
Au niveau technique, après avoir adopté JSON-RPC et la communication bidirectionnelle, nous avons divergé. Le LSP privilégie la présentation fonctionnelle — penser aux éléments de base sans nécessairement définir des règles sémantiques — une approche que nous avons reprise dans MCP. Ensuite, nous avons passé beaucoup de temps à concevoir chaque élément de base de MCP et à comprendre pourquoi ils diffèrent, ce qui représentait un gros travail de conception. Initialement, nous voulions supporter TypeScript, Python et Rust (pour l’intégration Zed), construire un SDK incluant client et serveur, créer un écosystème expérimental interne, et stabiliser le concept local MCP (lancement de sous-processus, etc.).
Nous avons aussi étudié les critiques faites au LSP, en essayant d’éviter les mêmes erreurs dans MCP. Par exemple, certaines implémentations du LSP sur JSON-RPC étaient trop complexes — nous avons opté pour des solutions plus directes. Notre stratégie était claire : innover dans un domaine spécifique, mais s’appuyer sur des modèles éprouvés ailleurs. Le choix de JSON-RPC, par exemple, n’était pas crucial — l’essentiel était d’innover sur les éléments de base, et là, s’inspirer du passé nous a beaucoup aidés.
swyx (animateur) : La conception de protocole m’intéresse beaucoup — il y a tant à approfondir ici. Vous avez parlé du problème M×N, un classique pour ceux qui travaillent sur des outils développeurs : c’est le problème de la « boîte universelle » (Universal Box).
En ingénierie infrastructurelle, le problème classique et sa solution consistent à connecter N choses différentes via une « boîte universelle ». Uber, GraphQL, Temporal où j’ai travaillé, React — tous ont rencontré ce problème. Avez-vous déjà résolu un problème N×N lors de votre passage chez Facebook ?
David : Oui, dans une certaine mesure. C’est un excellent exemple. J’ai traité beaucoup de cas similaires dans les systèmes de gestion de versions — rassembler tout dans un format lisible/écritable par tous, créer une « boîte universelle » pour résoudre le problème. Dans le domaine des outils développeurs, ce genre de problème est omniprésent.
swyx (animateur) : Ce qui est fascinant, c’est que tous ceux qui construisent une « boîte universelle » rencontrent les mêmes défis : combinabilité, local vs distant, etc. La question de Justin sur la présentation fonctionnelle montre que des concepts fondamentalement identiques doivent parfois être exprimés différemment.
02 Le cœur de MCP : les outils, les ressources et les prompts sont tous indispensables
swyx (animateur) : En lisant la documentation MCP, je me suis posé la question : pourquoi distinguer ces deux concepts ? Beaucoup traitent l’appel d’outil comme une solution universelle, mais en réalité, les appels d’outils ont des significations différentes — parfois ce sont des ressources, parfois des actions, parfois autre chose. Quels concepts avez-vous regroupés ? Pourquoi insistez-vous sur leur importance ?
Justin : Nous avons pensé chaque concept de base depuis la perspective du développeur d’applications. Quand on développe une application — IDE, Claude Desktop ou interface Agent — la vue utilisateur clarifie ce que l’on attend des intégrations. Et oui, l’appel d’outil est nécessaire, mais il faut distinguer les différents types de fonctionnalités.
Ainsi, les trois concepts fondamentaux initiaux de MCP (auxquels d’autres se sont ajoutés) sont :
-
Outil (Tool) : le cœur du système. Ajouter directement un outil au modèle, qui décide seul quand l’utiliser. Pour le développeur, c’est comme un « appel de fonction », mais initié par le modèle.
-
Ressource (Resource) : désigne fondamentalement des données ou informations contextuelles pouvant être ajoutées au contexte du modèle, contrôlées par l’application. Par exemple : le modèle peut automatiquement chercher et trouver des ressources pertinentes à inclure dans le contexte ; ou bien l’application peut offrir une interface utilisateur explicite (menu déroulant, trombone, etc.) pour que l’utilisateur intègre ces éléments dans le message envoyé au LLM. Ce sont des cas d’usage typiques des ressources.
-
Prompt : conçu intentionnellement comme un texte ou message initié ou remplaçable par l’utilisateur. Par exemple, dans un environnement éditeur, cela ressemble à une commande slash ou à une fonction d’autocomplétion — un macro que l’on veut insérer directement.
Via MCP, nous avons notre propre vision sur la manière dont ces concepts doivent être présentés, mais c’est finalement au développeur d’application de décider. Pour un développeur, disposer de ces concepts exprimés différemment est utile : il peut choisir l’expérience appropriée et créer une différenciation. Du point de vue du développeur, on ne veut pas que toutes les applications se ressemblent — en connectant un écosystème d’intégrations ouvertes, il faut des approches uniques pour offrir la meilleure expérience.
Je vois deux aspects : d’abord, aujourd’hui, les appels d’outil représentent plus de 95 % des intégrations. J’aimerais voir davantage d’appels de ressources et de prompts dans les clients. Le premier à être implémenté fut le prompt, très pratique, permettant de construire des serveurs MCP traçables. C’est une interaction pilotée par l’utilisateur, qui décide du moment d’importer l’information — meilleur que d’attendre que le modèle le fasse. J’espère aussi que davantage de serveurs MCP utilisent le prompt pour montrer comment utiliser un outil.
L’autre aspect est le potentiel des ressources. Imaginez un serveur MCP exposant des documents, des bases de données, etc., et un client construisant un index complet autour de ces ressources. Les ressources sont riches, pas pilotées par le modèle — car vous pouvez posséder bien plus de contenu que ce qui tient dans la fenêtre contextuelle. J’espère que dans les mois à venir, les applications sauront mieux exploiter ces concepts de base pour offrir des expériences plus riches.
Alessio (animateur) : Quand on tient un marteau, tout ressemble à un clou — on utilise l’appel d’outil pour tout résoudre. Par exemple, beaucoup l’utilisent pour interroger une base de données, au lieu d’un appel de ressource. J’aimerais savoir, quand on a une API (ex : base de données), quels sont les avantages/inconvénients respectifs d’un outil vs d’une ressource ? Quand utiliser un outil pour une requête SQL ? Quand utiliser une ressource pour manipuler des données ?
Justin : Nous distinguons outil et ressource ainsi : l’outil est appelé par le modèle, qui décide seul du moment opportun. Si vous voulez que le LLM exécute une requête SQL, le modéliser comme un outil est logique.
La ressource est plus flexible, mais complexe car peu de clients la supportent actuellement. Idéalement, pour des éléments comme la structure d’une table de base de données, un appel de ressource serait pertinent. L’utilisateur pourrait ainsi informer l’application au début de la conversation, ou l’application IA pourrait chercher automatiquement la ressource. Dès qu’il s’agit de lister des entités ou de les lire, modéliser cela comme une ressource est pertinent. Identifiée par un URI unique, la ressource agit comme un convertisseur universel — par exemple, un serveur MCP interprète un URI saisi par l’utilisateur. Dans l’éditeur Zed, par exemple, une bibliothèque de prompts interagit avec un serveur MCP pour remplir des suggestions — un bel exemple croisé d’utilisation des ressources.
Revenons au développeur d’applications : pensez à vos besoins, appliquez cette logique en pratique. Regardez les fonctionnalités existantes — quelles parties pourraient être externalisées via un serveur MCP ? Fondamentalement, tout menu « pièces jointes » dans un IDE pourrait naturellement être modélisé comme une ressource. Ces schémas existent déjà.
swyx (animateur) : Oui, en voyant le symbole @ dans Claude Desktop, j’ai tout de suite pensé à Cursor. Maintenant, d’autres utilisateurs peuvent aussi utiliser cette fonction. Ce design est excellent car la fonction existe déjà, donc facile à comprendre et utiliser. J’ai montré ce diagramme — vous devez reconnaître sa valeur. Je pense qu’il est très utile et devrait figurer en première page de la documentation. Excellente suggestion.
Justin : Seriez-vous prêt à soumettre une PR (Pull Request) pour cela ? Nous adorons cette idée.
swyx (animateur) : Bien sûr, je vais le faire.
En tant qu’expert en relations développeurs, je m’efforce toujours de donner des indications claires — d’abord les points clés, puis deux heures d’explication détaillée. Avoir une image couvrant l’essentiel est donc très utile. J’apprécie beaucoup votre insistance sur le prompt. Au début de ChatGPT et Claude, beaucoup ont tenté de créer des bibliothèques de prompts sur GitHub, mais rien n’a vraiment décollé.
Il faut vraiment plus d’innovation ici. Les gens veulent des prompts dynamiques, et vous offrez cette possibilité. Je valide fortement votre concept de « prompt multi-étapes » — parfois, pour que le modèle fonctionne correctement, il faut une séquence de prompts ou franchir certaines limites. Le prompt n’est pas qu’une simple entrée de dialogue — parfois, c’est un processus dialogué.
swyx (animateur) : Je pense que c’est là que ressources et outils se chevauchent un peu — parce que maintenant, vous dites qu’il faut parfois un contrôle utilisateur ou applicatif, parfois laisser le modèle décider. Donc, sommes-nous simplement en train de choisir un sous-ensemble d’outils ?
David : Oui, c’est une préoccupation légitime. Finalement, c’est un principe de conception central de MCP : le concept d’outil n’est pas isolé, il est intrinsèquement lié à l’application cliente, donc à l’utilisateur. Via les opérations MCP, l’utilisateur doit avoir un contrôle total. Quand nous disons « l’outil est contrôlé par le modèle », cela signifie uniquement que c’est le modèle qui l’appelle, pas l’utilisateur qui choisit explicitement un outil (sauf dans un but de suggestion, mais cela ne devrait pas être une fonction d’interface habituelle).
Mais je pense qu’il est tout à fait raisonnable que l’application cliente ou l’utilisateur filtre ou optimise le contenu proposé par le serveur MCP — par exemple, l’application peut récupérer la description des outils et les présenter de façon optimisée. Dans le paradigme MCP, le client doit garder le contrôle total. D’ailleurs, nous avons une idée préliminaire : ajouter dans le protocole une fonction permettant aux développeurs de serveurs de regrouper logiquement les prompts, ressources et outils. Ces groupes pourraient être vus comme des serveurs MCP distincts, que l’utilisateur combinerait selon ses besoins.
03 MCP vs OpenAPI : concurrents ou complémentaires ?
swyx (animateur) : Parlons de la comparaison entre MCP et l’API ouverte (Open API), car c’est clairement l’une des questions les plus discutées.
Justin / David : Fondamentalement, la spécification OpenAPI est un outil très puissant, que j’utilise souvent en développant des API et leurs clients. Mais pour les scénarios d’utilisation des grands modèles linguistiques (LLM), elle est trop détaillée. Elle ne reflète pas suffisamment des concepts de haut niveau adaptés à l’IA, comme les concepts de base de MCP ou la logique du développeur d’applications. Comparé à un simple REST API laissé libre au modèle, ce dernier tire bien plus de bénéfice d’outils, ressources, prompts et autres concepts spécialement conçus pour lui.
D’un autre côté, en concevant MCP, nous l’avons délibérément rendu un peu « étatique ». Car les applications et interactions IA ont tendance à être orientées « état persistant » (Statefulness). Bien que le sans-état (Stateless) ait toujours sa place, avec l’augmentation des modes d’interaction (vidéo, audio, etc.), le Statefulness gagne en popularité — un protocole étatique devient donc particulièrement utile.
En réalité, OpenAPI et MCP ne sont pas opposés, mais complémentaires. Chacun a ses forces, et ils s’associent bien. L’important est de choisir l’outil adapté à la tâche. Si l’objectif est d’obtenir des interactions riches entre applications IA, MCP est plus adapté ; si l’on veut que le modèle lise et interprète facilement une spécification API, OpenAPI est meilleur. Déjà, certains ont bâti des ponts entre les deux — des outils convertissent OpenAPI en MCP, et vice versa. C’est excellent.
Alessio (animateur) : J’ai co-animé un hackathon chez AGI Studio. En tant que développeur d’Agents personnels, j’ai vu quelqu’un construire un Agent capable de générer un serveur MCP : il suffit d’entrer l’URL de la spécification API, et il crée le serveur MCP correspondant. Que pensez-vous de cela ? Est-ce que cela signifie que la plupart des serveurs MCP ne sont que des couches ajoutées sur des API existantes, sans conception originale ? L’avenir sera-t-il dominé par l’IA connectant des API existantes, ou verrons-nous de nouvelles expériences MCP inédites ?
Justin / David : Je pense que les deux coexisteront. D’un côté, la demande de « connecteurs pour importer des données dans les applications » restera toujours pertinente. Actuellement, on utilise surtout l’appel d’outil par défaut, mais à l’avenir, d’autres concepts de base pourraient mieux convenir. Même s’il reste un connecteur ou une couche d’adaptation, adapter différents concepts peut ajouter de la valeur.
D’un autre côté, il existe un vrai potentiel pour des scénarios innovants où le serveur MCP ne se contente pas d’être un adaptateur. Par exemple, un serveur mémoire MCP permettrait au LLM de se souvenir d’informations entre conversations ; un serveur « pensée séquentielle » pourrait améliorer la capacité de raisonnement du modèle. Ces serveurs ne s’intègrent pas à des systèmes externes, mais offrent au modèle de nouvelles façons de penser.
Quoi qu’il en soit, utiliser l’IA pour construire des serveurs est tout à fait faisable. Même si la fonctionnalité n’est pas un adaptateur d’API, mais originale, le modèle trouve souvent un moyen de l’implémenter. Beaucoup de serveurs MCP seront des enveloppes API — c’est logique et efficace, cela vous fait avancer rapidement. Mais nous en sommes encore à l’exploration, à découvrir ce qui est possible.
Avec une meilleure prise en charge des concepts de base par les clients, de nouvelles expériences émergeront. Par exemple, un serveur MCP « résumant le contenu d’un forum Reddit » n’existe pas encore, mais le protocole le permet totalement. Je pense que lorsque les besoins passeront de « je veux juste connecter mes données au LLM » à « je veux un vrai flux de travail, une expérience riche où le modèle interagit profondément », ces innovations apparaîtront. Mais pour l’instant, il y a un problème de type « œuf ou poule » entre les capacités des clients et les ambitions des développeurs de serveurs.
04 Construire rapidement un serveur MCP : programmez avec l’IA
Alessio (animateur) : Je pense qu’un aspect de MCP est peu discuté : la construction du serveur. Pour les développeurs qui veulent commencer, quelle est votre recommandation ? En tant que développeur de serveur, comment trouver un bon équilibre entre fournir une description détaillée (pour que le modèle comprenne) et retourner directement les données brutes (laissant le modèle les traiter ensuite) ?
Justin / David : J’ai quelques conseils. Un atout de MCP est la facilité à construire des fonctionnalités simples — en environ trente minutes, même si ce n’est pas parfait, cela suffit pour démarrer. La meilleure entrée : choisissez votre langage favori, utilisez un SDK s’il existe ; créez un outil que vous voulez voir interagir avec le modèle ; construisez un serveur MCP ; ajoutez cet outil au serveur ; écrivez une courte description ; reliez-le via stdin/stdout à votre application favorite ; puis observez comment le modèle l’utilise.
Pour les développeurs, voir rapidement le modèle interagir avec quelque chose qui leur tient à cœur est très motivant. Cela les pousse à réfléchir à d’autres outils, ressources, prompts nécessaires, à évaluer les résultats, à optimiser les prompts. C’est un processus à explorer en profondeur, mais commencez par le simple : observer l’interaction entre le modèle et votre sujet est déjà très stimulant. MCP ajoute du plaisir au développement, permettant au modèle d’agir rapidement.
J’aime aussi programmer assisté par IA. Dès le début, nous avons vu qu’en plaçant des extraits du SDK MCP dans le contexte d’un LLM, celui-ci pouvait aider à construire le serveur — souvent avec de bons résultats. Les détails peuvent être peaufinés plus tard. C’est une bonne méthode pour implémenter rapidement et itérer. Dès le départ, nous avons mis l’accent sur la simplification de la création de serveurs pour permettre à l’IA d’y participer. Depuis quelques années, lancer un serveur MCP prend environ 100 à 200 lignes de code — extrêmement simple. Sans SDK disponible, donnez la spécification ou un autre SDK au modèle, il pourra vous aider à construire une partie. L’appel d’outil dans votre langage favori est généralement très direct.
Alessio (animateur) : Je remarque que les concepteurs de serveurs déterminent largement le format et le contenu des données retournées. Par exemple, dans un appel d’outil comme Google Maps, les attributs retournés sont décidés par le concepteur. S’il en oublie un, l’utilisateur ne peut pas le modifier. C’est comme mon irritation face à certains SDK : quand on empaquette une API, si les nouveaux paramètres ne sont pas inclus, on ne peut pas utiliser les nouveautés. Que pensez-vous de cela ? Quel contrôle l’utilisateur devrait-il avoir, ou tout revient-il au concepteur du serveur ?
Justin / David : Sur l’exemple Google Maps, nous avons peut-être une part de responsabilité, car c’est un serveur de référence que nous avons publié. Généralement, pour l’instant, concernant les résultats d’appel d’outil, nous avons délibérément évité qu’ils soient forcément des données JSON structurées ou correspondent à un schéma précis. Nous préférons qu’ils soient retournés sous forme de messages textuels, images, etc., directement injectables dans le LLM. Autrement dit, nous avons tendance à retourner beaucoup de données, en croyant que le LLM saura en extraire ce qui l’intéresse. Nous avons beaucoup travaillé là-dessus, pour permettre au modèle de récupérer librement l’information — c’est là sa force. Nous voulons exploiter pleinement le potentiel du LLM, plutôt que de trop le restreindre, ce qui nuirait à l’évolutivité avec l’amélioration des modèles. Ainsi, dans les serveurs exemples, l’idéal est que tous les types de résultats soient transmis tels quels depuis l’API appelée, automatiquement.
Alessio (animateur) : Définir cette limite est effectivement une décision difficile.
David : Là, je dois insister sur le rôle de l’IA. Beaucoup de serveurs exemples sont écrits par Claude — ce n’est pas surprenant. On a souvent l’habitude d’aborder les problèmes avec la méthodologie traditionnelle du génie logiciel, mais il faut réapprendre à construire des systèmes pour les LLM et faire confiance à leurs capacités. Avec les progrès annuels des LLM, il est intelligent de déléguer le traitement des données à un modèle spécialisé. Cela signifie peut-être abandonner certaines pratiques du génie logiciel des 20, 30, voire 40 dernières années.
Vue autrement, la vitesse de progression de l’IA est stupéfiante — à la fois excitante et un peu inquiétante. Le principal goulot d’étranglement pour la prochaine vague de capacités du modèle pourrait être son interaction avec le monde extérieur : lire des sources de données externes, agir de manière étatique. Chez Anthropic, nous accordons une grande importance à des interactions sécurisées, avec des contrôles et calibrages appropriés. À mesure que l’IA évolue, les utilisateurs s’attendent à ces capacités, et connecter le modèle à l’extérieur est clé pour augmenter la productivité. MCP est justement notre pari sur cette direction future et son importance.
Alessio (animateur) : Tout à fait. Je pense que toute propriété d’API marquée « formatée » devrait être supprimée. Nous devrions récupérer les données brutes de toutes les interfaces. Pourquoi formater à l’avance ? Le modèle est assez intelligent pour formater lui-même une adresse, etc. C’est à l’utilisateur final d’en décider.
05 Comment permettre à MCP d’utiliser davantage d’outils ?
swyx (animateur) : Une autre question : combien de fonctionnalités connexes un implémentant MCP peut-il supporter ? Cela touche à la largeur versus la profondeur, et au concept de MCP imbriqué dont nous parlions.
En avril 2024, quand Claude a présenté son premier exemple avec contexte d’un million de tokens, il affirmait pouvoir gérer 250 outils. Pourtant, dans de nombreux cas réels, le modèle n’utilise pas efficacement tant d’outils. C’est un problème de largeur, car il n’y a pas d’outil appelant un autre outil — seulement un modèle et une hiérarchie plate d’outils. Cela provoque facilement des confusions. Quand les outils sont similaires, le modèle peut en appeler un mauvais, donnant un mauvais résultat. Avez-vous des
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
