Serveurs MCP : connecter vos outils à une IA, l'annuaire des possibles

Le 25 novembre 2024, Anthropic publie sur son blog un billet au titre modeste : « Introducing the Model Context Protocol ». Le contenu, lui, est loin d'être anodin. L'entreprise ouvre le code d'un protocole censé résoudre un problème que tout ingénieur ayant relié un assistant IA à une base de données, un dépôt Git ou un espace de travail Slack connaît par cœur : chaque intégration se construisait à la main, projet par projet, sans réutilisation possible d'un modèle à l'autre. Pour résumer l'ambition, Anthropic choisit une image volontairement banale : le Model Context Protocol (MCP) serait « comme un port USB-C, mais pour l'intelligence artificielle ». Un connecteur unique, standardisé, auquel n'importe quel outil peut se brancher, et auquel n'importe quelle application dotée d'un modèle de langage peut se relier.

Le protocole arrive accompagné d'une spécification ouverte, de kits de développement en Python et TypeScript, d'un support natif dans Claude Desktop pour les serveurs locaux, et surtout d'un dépôt de code open source rassemblant déjà une quinzaine de serveurs de référence prêts à l'emploi : Google Drive, Slack, GitHub, Git, Postgres, Puppeteer, et plusieurs autres. Ce n'est pas une simple annonce de recherche : c'est un outillage complet, immédiatement utilisable par quiconque fait tourner Claude Desktop sur son ordinateur.

Cet article propose un tour d'horizon pratique de cet écosystème naissant : ce que le protocole résout concrètement, comment il fonctionne sous le capot, quels serveurs sont disponibles dès aujourd'hui, qui les a déjà adoptés, et ce que cela change pour quiconque souhaite relier une IA à ses propres outils. L'objectif n'est pas de vendre du rêve sur une technologie qui vient tout juste de naître, mais de comprendre précisément ce qu'elle met sur la table — et ce qu'elle ne fait pas encore.

Le problème du N×M : pourquoi connecter une IA à des outils était un casse-tête

Pour saisir l'intérêt de MCP, il faut d'abord comprendre le problème qu'il cible. Avant le protocole, brancher un assistant conversationnel sur une source de données extérieure — un système de fichiers, une base Postgres, un espace Slack, un dépôt GitHub — imposait d'écrire une intégration sur mesure. Cette intégration dépendait à la fois du modèle utilisé et de l'outil visé : la connexion entre Claude et Slack ne se réutilisait pas pour connecter GPT à Slack, et la connexion entre Claude et Postgres ne servait à rien pour connecter Claude à GitHub.

Avec N modèles de langage différents et M outils ou sources de données à connecter, le nombre d'intégrations à écrire et à maintenir grimpe vers N × M. Chaque nouvel outil ajouté au catalogue doit être réécrit pour chaque assistant qui souhaite s'en servir ; chaque nouveau modèle qui arrive sur le marché doit, à son tour, être reconnecté à chacun des outils déjà en place. Le travail ne se capitalise pas : il se démultiplie.

MCP propose une architecture qui transforme cette équation combinatoire en une simple addition. Un développeur qui construit un serveur MCP pour Postgres n'a besoin de le faire qu'une seule fois : n'importe quel client compatible avec le protocole — Claude Desktop aujourd'hui, d'autres applications demain — peut s'y connecter sans code supplémentaire. Le problème devient N + M plutôt que N × M : un connecteur par outil, un connecteur par application, et l'ensemble s'assemble comme des pièces de Lego plutôt que comme un enchevêtrement de câbles propriétaires.

« Open technologies like the Model Context Protocol are the bridges that connect AI to real-world applications, ensuring innovation is accessible, transparent, and rooted in collaboration. » — Dhanji R. Prasanna, Chief Technology Officer de Block, partenaire de lancement du protocole.

Cette citation de Dhanji Prasanna, reprise dans le billet d'annonce d'Anthropic, résume bien l'enjeu tel que le perçoivent les premiers partenaires : il ne s'agit pas seulement de brancher un modèle sur un outil, mais de bâtir une infrastructure commune que plusieurs organisations peuvent partager et faire évoluer ensemble, plutôt que de dupliquer indéfiniment le même travail d'intégration en interne.

Anatomie du protocole : hôtes, clients et serveurs

MCP repose sur une architecture à trois rôles, empruntée aux schémas classiques du client-serveur mais adaptée aux besoins particuliers d'une application dotée d'un modèle de langage.

Les trois participants

• L'hôte MCP (MCP host) : c'est l'application qui orchestre l'ensemble, celle que l'utilisateur voit et manipule. Claude Desktop en est l'exemple de référence au lancement du protocole : c'est lui qui décide quels serveurs lancer, qui présente les outils disponibles au modèle, et qui affiche les demandes d'autorisation à l'utilisateur.
• Le client MCP (MCP client) : un composant interne à l'hôte, créé un par serveur connecté. Si Claude Desktop se connecte à trois serveurs — un pour le système de fichiers, un pour Slack, un pour Postgres — il instancie trois clients distincts, chacun maintenant une connexion dédiée avec son serveur.
• Le serveur MCP (MCP server) : un programme, léger et autonome, qui expose des capacités précises — lire des fichiers, interroger une base, publier un message. Il peut tourner en local sur la machine de l'utilisateur ou à distance sur un serveur distant.

Cette séparation nette entre les trois rôles est ce qui permet la réutilisation. Un même serveur Postgres, écrit une fois, peut être invoqué par n'importe quel hôte compatible avec le protocole, sans qu'il ait besoin de connaître à l'avance quel modèle de langage l'utilisera. Le serveur ne parle pas au modèle : il parle au protocole. C'est cette indirection, en apparence anodine, qui casse la dépendance entre modèle et outil et rend possible l'équation N + M évoquée plus haut.

Local ou distant : deux façons de tourner

Un serveur MCP peut fonctionner de deux manières. En local, il tourne comme un simple processus sur la machine de l'utilisateur, lancé automatiquement par l'hôte au démarrage — c'est le cas du serveur de système de fichiers, qui n'a de sens que sur l'ordinateur dont il explore les dossiers. À distance, il tourne sur une infrastructure séparée et communique par le réseau — un modèle plus proche de celui d'une API classique, adapté à des services partagés par plusieurs utilisateurs. Au lancement du protocole, l'essentiel de l'écosystème de référence privilégie le mode local, plus simple à mettre en œuvre et suffisant pour la grande majorité des cas d'usage individuels : accéder à ses propres fichiers, à son propre dépôt Git, à son propre espace Slack.

Les primitives : outils, ressources et prompts

Le cœur technique de MCP tient dans ce que sa documentation appelle les « primitives » : les types d'informations et d'actions qu'un serveur peut proposer à un hôte. Trois primitives structurent l'essentiel des usages côté serveur.

Tools : des actions que le modèle peut déclencher

Les outils (tools) sont des fonctions exécutables que l'IA peut invoquer pour accomplir une action : lire un fichier, écrire un enregistrement dans une base, envoyer un message, lancer une recherche. Chaque outil est décrit par un nom, une explication en langage naturel de ce qu'il fait, et un schéma qui précise les paramètres attendus. C'est cette description qui permet au modèle de comprendre, au moment de répondre à une demande de l'utilisateur, quel outil utiliser et avec quels arguments.

Resources : des données à consulter

Les ressources (resources) désignent des sources d'information que le serveur met à disposition sans que cela déclenche d'action : le contenu d'un fichier, un enregistrement de base de données, la réponse d'une API. Contrairement aux outils, les ressources sont pensées pour être lues plutôt qu'exécutées — elles alimentent le contexte du modèle sans effet de bord.

Prompts : des gabarits réutilisables

Les prompts sont des modèles d'interaction prêts à l'emploi : un squelette de requête, des exemples annotés (few-shot), un enchaînement de questions typiques pour un cas d'usage donné. Ils permettent à l'auteur d'un serveur de partager, en plus des données et des actions, sa connaissance de la meilleure façon d'interagir avec elles.

Un exemple concret aide à visualiser l'articulation des trois : un serveur MCP dédié à une base de données peut exposer un outil pour exécuter une requête, une ressource qui décrit le schéma des tables disponibles, et un prompt qui fournit des exemples de requêtes bien formées. Le modèle dispose ainsi, en une seule connexion, de la capacité d'agir, du contexte nécessaire pour agir correctement, et d'un mode d'emploi.

Une quatrième primitive, plus discrète, s'ajoute côté client : le sampling. Il permet à un serveur de demander à l'application hôte de solliciter elle-même le modèle de langage pour produire un texte, sans que le serveur ait besoin d'embarquer son propre accès à un modèle. C'est un choix d'architecture qui garde les serveurs légers et indépendants d'un fournisseur de modèle particulier : l'auteur d'un serveur MCP n'a pas à décider à l'avance quel LLM ses utilisateurs feront tourner.

Sous le capot : JSON-RPC et le cycle de vie d'une connexion

Techniquement, MCP s'appuie sur JSON-RPC 2.0, un format d'échange de messages simple et déjà largement éprouvé dans l'industrie du logiciel, bien antérieur à l'intelligence artificielle. Ce choix n'a rien d'exotique : c'est une décision pragmatique qui permet de s'appuyer sur des bibliothèques existantes plutôt que d'inventer un nouveau format depuis zéro.

Une connexion MCP suit toujours la même séquence. D'abord, une phase d'initialisation : le client envoie une requête initialize qui précise la version du protocole qu'il supporte et les capacités qu'il gère ; le serveur répond en indiquant les siennes, en particulier les primitives qu'il expose — outils, ressources, prompts. Cette négociation évite les incompatibilités : un client qui ne sait pas gérer les ressources n'ira pas en réclamer à un serveur qui n'en propose pas.

Une fois la connexion établie, le client peut interroger le serveur pour découvrir ce qu'il propose, via des méthodes comme tools/list, qui renvoie la liste des outils disponibles avec leur description et leur schéma d'arguments. Le client peut ensuite exécuter un outil précis via tools/call, en lui passant les arguments requis, et récupérer un résultat structuré.

Le protocole prévoit également des notifications : lorsque la liste des outils d'un serveur change — par exemple parce qu'un nouvel outil devient disponible en cours de session — le serveur peut en avertir le client sans attendre d'être interrogé. Cette dimension dynamique distingue MCP d'une simple API statique : les capacités exposées à un instant donné peuvent évoluer pendant la durée d'une session.

Étape	Méthode JSON-RPC	Rôle
1. Initialisation	initialize	Négociation de version et de capacités entre client et serveur
2. Confirmation	notifications/initialized	Le client signale qu'il est prêt à échanger
3. Découverte	tools/list, resources/list, prompts/list	Le client recense les capacités proposées par le serveur
4. Exécution	tools/call	Le client invoque un outil avec ses arguments
5. Mise à jour	notifications/tools/list_changed	Le serveur signale un changement de ses capacités

Se connecter en pratique : Claude Desktop et les serveurs locaux

Sur le papier, l'architecture peut sembler abstraite. En pratique, la mise en route pour un utilisateur de Claude Desktop tient en quelques étapes simples, documentées par Anthropic dès le lancement du protocole.

La configuration passe par un fichier JSON unique, claude_desktop_config.json, accessible depuis le menu Réglages puis l'onglet Développeur de l'application. Chaque serveur à activer y est déclaré sous une clé mcpServers, avec un nom, une commande à exécuter et, le cas échéant, des arguments et des variables d'environnement — typiquement une clé d'API pour les services qui en réclament une.

Un exemple simple : pour donner à Claude un accès en lecture et en écriture à un dossier Bureau et un dossier Téléchargements, il suffit de déclarer un serveur nommé filesystem, lancé via la commande npx avec le paquet @modelcontextprotocol/server-filesystem et les chemins concernés en argument. Après redémarrage de l'application, un indicateur apparaît dans la zone de saisie, listant les outils désormais disponibles : lire un fichier, en créer un, déplacer un dossier, chercher par nom ou par contenu.

Le point le plus structurant, du point de vue de l'utilisateur, reste le principe du consentement explicite. Avant chaque action susceptible de modifier quoi que ce soit — écrire un fichier, exécuter une requête, envoyer un message — l'application affiche une demande d'autorisation détaillée, que l'utilisateur peut accepter ou refuser au cas par cas. Rien ne s'exécute silencieusement en arrière-plan : chaque geste du modèle sur le monde extérieur reste soumis à validation humaine, du moins dans cette première mouture du protocole.

L'annuaire des possibles : les serveurs de référence

Anthropic ne publie pas seulement une spécification : l'entreprise ouvre en parallèle un dépôt de code rassemblant des serveurs de référence, maintenus directement par l'équipe à l'origine du protocole. Ces implémentations jouent un double rôle : elles sont immédiatement utilisables telles quelles, et elles servent de modèle pour quiconque souhaite écrire son propre serveur.

Le catalogue de lancement couvre déjà un éventail large de cas d'usage, du développement logiciel à la bureautique en passant par la recherche web et la persistance de mémoire :

Serveur	Catégorie	Ce qu'il permet
Filesystem	Système local	Lire, écrire, déplacer et rechercher des fichiers avec des permissions configurables
Git	Développement	Lire l'historique, rechercher et manipuler un dépôt Git
GitHub	Développement	Consulter et gérer des dépôts, des issues et des pull requests
GitLab	Développement	Équivalent GitHub pour les instances GitLab
Postgres	Données	Interroger une base de données relationnelle
SQLite	Données	Interroger une base de données embarquée
Redis	Données	Lire et écrire dans un cache clé-valeur en mémoire
Google Drive	Productivité	Rechercher et consulter des documents dans le cloud
Slack	Communication	Lire et publier des messages dans un espace de travail
Puppeteer	Web	Piloter un navigateur pour naviguer et extraire du contenu
Brave Search	Recherche	Effectuer des recherches web et locales via l'API Brave
Fetch	Web	Récupérer et convertir du contenu web pour un usage optimisé par un modèle
Memory	Mémoire	Maintenir un graphe de connaissances persistant entre les sessions
Sentry	Observabilité	Consulter les erreurs et incidents applicatifs remontés par la plateforme
Google Maps	Géolocalisation	Rechercher des lieux et calculer des itinéraires

Ce que ce tableau donne à voir, ce n'est pas seulement une liste d'intégrations techniques : c'est un signal sur l'intention derrière le protocole. En couvrant d'emblée le développement logiciel, la donnée structurée, la bureautique cloud, la communication d'équipe et la recherche web, Anthropic ne se contente pas de démontrer un principe abstrait — l'entreprise livre un point de départ suffisamment riche pour qu'un développeur puisse, dès le premier jour, brancher son assistant sur une part significative de sa pile d'outils quotidienne sans écrire une ligne de code d'intégration.

Explorer par catégorie : quatre grandes familles d'usage

Au-delà de la liste brute, il est utile de regrouper ces serveurs par grande famille d'usage, pour mieux comprendre où le protocole apporte le plus de valeur dès son lancement.

Développement logiciel

C'est l'une des familles les plus étoffées du catalogue de référence — à égalité avec les données structurées et le web/recherche —, et sans doute la plus naturelle : les développeurs sont à la fois les premiers utilisateurs des assistants IA et les mieux placés pour en écrire les extensions. Git, GitHub et GitLab permettent à un assistant de consulter l'historique d'un projet, de comprendre le contexte d'un bug ou de proposer une modification en connaissance de cause, sans que l'utilisateur ait à copier-coller manuellement des extraits de code dans la conversation.

Données structurées

Postgres, SQLite et Redis donnent à un assistant la capacité d'interroger directement une base de données, à condition que l'accès soit configuré avec les permissions adéquates. C'est un cas d'usage particulièrement parlant pour illustrer le gain du protocole : sans MCP, interroger une base depuis un assistant supposait d'écrire un connecteur maison, propre à chaque combinaison de modèle et de moteur de base de données. Avec un serveur MCP dédié, la même intégration sert n'importe quel client compatible.

Bureautique et communication

Google Drive et Slack couvrent des usages plus proches du quotidien de bureau : retrouver un document dans une arborescence partagée, résumer un fil de discussion, préparer un message. Ces intégrations rapprochent l'assistant des outils que la plupart des équipes utilisent déjà, sans passer par une refonte des habitudes de travail.

Web, recherche et automatisation

Puppeteer, Fetch et Brave Search permettent à l'assistant d'aller chercher de l'information sur le web ouvert, de naviguer sur une page comme le ferait un navigateur automatisé, ou de récupérer un contenu et de le convertir dans un format exploitable. Cette famille comble une limite structurelle des modèles de langage : leur connaissance, figée au moment de leur entraînement, ne couvre pas ce qui se passe après cette date. Un serveur de recherche web, branché via MCP, permet à l'assistant d'aller chercher une information à jour au moment même où la question est posée.

Mémoire et observabilité

Deux serveurs méritent une mention à part, car ils répondent à des besoins moins évidents mais tout aussi structurants. Le serveur Memory offre un graphe de connaissances persistant : contrairement à une conversation classique, dont le contexte s'efface une fois la fenêtre de dialogue fermée, ce serveur permet à l'assistant de conserver, d'une session à l'autre, des informations que l'utilisateur souhaite voir mémorisées durablement — des préférences, des faits récurrents, des relations entre des projets. Le serveur Sentry, de son côté, connecte l'assistant à une plateforme de suivi d'erreurs applicatives : un développeur peut ainsi demander à Claude de résumer les incidents remontés la veille sur un projet donné, sans quitter sa conversation pour aller consulter un tableau de bord séparé.

Ce sont des cas d'usage moins spectaculaires que la génération de texte ou la recherche web, mais ils illustrent une dimension importante du protocole : MCP ne se limite pas à des connecteurs vers des sources d'information externes, il ouvre aussi la voie à des capacités qui touchent au fonctionnement même de l'assistant, comme sa mémoire à long terme.

Écrire son propre serveur : un exercice volontairement accessible

Pour qui souhaite connecter un outil qui ne figure pas encore dans le catalogue de référence, Anthropic ne se contente pas de publier une spécification abstraite : l'entreprise fournit des kits de développement complets en Python et en TypeScript, pensés pour réduire au minimum la quantité de code nécessaire pour exposer une nouvelle capacité.

La structure minimale d'un serveur MCP tient en trois éléments : une déclaration des primitives qu'il expose — un ou plusieurs outils, éventuellement des ressources et des prompts —, une implémentation de la logique qui répond à chaque appel, et une configuration de transport, le plus souvent en entrée-sortie standard pour un serveur local. Le code d'exemple documenté par Sourcegraph pour intégrer Linear à Cody illustre bien cette simplicité : deux méthodes suffisent pour lister les tickets d'un projet et récupérer le détail de l'un d'entre eux, l'essentiel de la complexité résidant dans l'appel à l'API existante de Linear plutôt que dans la couche MCP elle-même.

Cette accessibilité est un choix délibéré. En maintenant la barrière d'entrée basse, Anthropic parie sur une croissance organique du catalogue de serveurs, portée par des développeurs individuels et de petites équipes plutôt que par un petit nombre de grands acteurs. C'est un pari qui ne peut se vérifier que dans la durée, mais dont les modalités techniques — une poignée de méthodes à implémenter, un schéma JSON pour décrire les entrées, une bibliothèque qui gère le reste — sont pensées pour ne pas décourager les contributions.

Les premiers partenaires : bâtir avec, pas seulement pour

Un protocole ouvert n'a de valeur que si d'autres acteurs s'en emparent. Dès l'annonce, Anthropic met en avant deux catégories de partenaires : des entreprises qui intègrent MCP dans leurs propres systèmes, et des éditeurs d'outils de développement qui l'adoptent pour enrichir leurs assistants de code.

Block, la société de paiement dirigée par Jack Dorsey, et Apollo, spécialiste des API GraphQL, comptent parmi les tout premiers partenaires cités par Anthropic. Leur intérêt illustre un usage moins grand public mais tout aussi concret du protocole : construire, en interne, des systèmes agentiques capables d'interagir avec des API métier existantes, sans réinventer une couche d'intégration à chaque nouveau projet.

Du côté des outils de développement, quatre noms reviennent systématiquement dans les annonces de lancement : Zed, l'éditeur de code performant fondé par d'anciens ingénieurs d'Atom ; Replit, la plateforme de développement dans le navigateur ; Codeium, l'assistant de complétion de code ; et Sourcegraph, dont l'assistant Cody annonce le jour même du lancement de MCP le support du protocole via son extension OpenCtx, avec des exemples concrets de serveurs pour Linear, Postgres ou Google Drive intégrés directement dans l'éditeur.

Ce choix de partenaires n'est pas anodin : en s'associant d'emblée à des outils utilisés quotidiennement par des développeurs, Anthropic ancre le protocole dans des flux de travail réels plutôt que de le cantonner à une démonstration de faisabilité. C'est une différence de posture qui compte, dans un secteur où beaucoup de standards proposés restent des exercices de style sans adoption concrète.

Sécurité et confiance : les quatre principes posés dès le départ

Ouvrir un protocole qui permet à un modèle de langage de lire des fichiers, d'exécuter des requêtes ou d'envoyer des messages soulève, presque mécaniquement, des questions de sécurité. Anthropic ne les élude pas : la documentation de lancement identifie explicitement quatre zones d'attention pour quiconque développe un serveur ou un client MCP.

• Le consentement et le contrôle de l'utilisateur : chaque accès à une donnée ou chaque exécution d'une action doit obtenir une autorisation explicite, et l'utilisateur doit conserver la possibilité de refuser ou de révoquer cet accès à tout moment.
• La confidentialité des données : les hôtes doivent obtenir un consentement explicite avant de transmettre des données utilisateur à un serveur, et ne pas transmettre de données de conversation ailleurs sans accord.
• La sécurité des outils : un outil exposé par un serveur MCP peut, dans le cas général, déclencher l'exécution de code arbitraire côté serveur. La documentation recommande donc une prudence particulière avant de faire confiance à la description d'un outil fourni par un tiers non vérifié.
• Les contrôles sur le sampling : lorsqu'un serveur demande à l'hôte de solliciter le modèle pour générer du texte, l'utilisateur doit pouvoir approuver la requête, en contrôler le contenu exact envoyé au modèle, et limiter la visibilité du serveur sur les réponses produites.

Cette liste n'a rien de cosmétique : elle pose, dès le premier jour, un cadre de responsabilités entre l'hôte, le serveur et l'utilisateur, plutôt que de laisser chaque implémentation improviser ses propres règles. C'est une différence notable avec la manière dont beaucoup d'intégrations ad hoc avaient été bricolées jusque-là, souvent sans documentation claire sur ce qui était transmis à qui.

Comment la communauté technique a accueilli le protocole

La publication du code source, accompagnée d'une spécification complète, déclenche rapidement des discussions nourries dans les communautés de développeurs. Sur Hacker News, le fil consacré à l'annonce rassemble en quelques heures des dizaines de commentaires, mêlant enthousiasme prudent et questions techniques précises.

Un développeur, sous le pseudonyme jascha_eng, interroge directement la portée du protocole : il se demande si « LLM applications » ne désigne, dans les faits, que des applications de conversation, et s'interroge sur la pertinence de MCP pour des systèmes plus intégrés, comme un agent de recherche documentaire interne qui ne passerait pas par une interface de chat classique. La question touche un point réel : au moment du lancement, l'essentiel des exemples et des serveurs de référence sont pensés pour des interactions conversationnelles, pas pour des pipelines automatisés sans supervision humaine directe.

« The separate concepts of prompts and resources are extremely useful for expressing different intents » — Justin Spahr-Summers, co-créateur du protocole chez Anthropic, répondant sur Hacker News à des questions sur l'utilité des primitives au-delà des simples outils.

Cette réponse de Justin Spahr-Summers, l'un des deux ingénieurs à l'origine du protocole avec David Soria Parra, éclaire une distinction souvent négligée dans les premières lectures rapides de MCP : le protocole n'est pas qu'un mécanisme d'appel de fonctions. En distinguant nettement outils, ressources et prompts, ses concepteurs cherchent à couvrir un spectre d'intentions plus large qu'un simple « function calling » — consulter une donnée n'est pas la même chose que déclencher une action, et les deux méritent un traitement différencié.

Du côté de la presse spécialisée francophone, la couverture est tout aussi rapide. Dès le lendemain de l'annonce, Le Monde Informatique consacre un article à l'initiative, résumant l'ambition d'Anthropic à « standardiser la contextualisation des modèles » et détaillant les quatre principes de sécurité évoqués plus haut. La rapidité de cette couverture, à peine 24 heures après la publication du billet original, témoigne de l'attention immédiate suscitée par le protocole dans les cercles techniques, bien au-delà du seul écosystème Anthropic.

Ce que MCP ne fait pas encore

Il serait malhonnête de présenter uniquement les promesses du protocole sans mentionner ses limites, au moment de son lancement. D'abord, la portée conversationnelle : comme le note la discussion Hacker News évoquée plus haut, la plupart des exemples et des cas d'usage documentés supposent une interface de conversation avec un utilisateur qui valide chaque action. Des systèmes plus autonomes, qui chaîneraient des dizaines d'appels d'outils sans intervention humaine à chaque étape, ne sont pas le scénario central des premiers exemples publiés.

Ensuite, l'écosystème de clients reste, à ce stade, concentré. Claude Desktop est l'implémentation de référence côté hôte, et si Sourcegraph Cody et Zed annoncent un support dès les premiers jours, la liste des applications compatibles est encore courte comparée à celle des serveurs disponibles. Un protocole n'a de valeur que si les deux côtés — clients et serveurs — se développent en parallèle ; au lancement, c'est indéniablement le côté serveurs qui est le plus fourni.

Enfin, la question de la découverte reste largement artisanale. Il n'existe pas encore, à ce stade, d'annuaire centralisé et vérifié qui permettrait de parcourir l'ensemble des serveurs disponibles avec un niveau de confiance homogène : le dépôt officiel d'Anthropic recense les implémentations de référence, mais un développeur qui souhaite connecter un outil non couvert doit, pour l'instant, écrire son propre serveur ou faire confiance à une implémentation tierce dont la qualité et la sécurité restent à évaluer au cas par cas.

Ce que cela change, concrètement, pour un praticien

Au-delà de l'architecture, que peut faire aujourd'hui, dès son lancement, quelqu'un qui veut relier une IA à ses propres outils ?

Pour un utilisateur individuel de Claude Desktop, le chemin le plus court consiste à partir des serveurs de référence déjà publiés : filesystem pour un accès contrôlé aux fichiers locaux, Git ou GitHub pour le contexte d'un projet de code, Brave Search pour compléter les réponses avec de l'information web à jour. La configuration se limite à éditer un fichier JSON et à redémarrer l'application — un investissement de quelques minutes pour qui est à l'aise avec une ligne de commande.

Pour une équipe technique qui souhaite exposer un outil interne — une API métier, une base de connaissances, un système de tickets — la logique change de nature : il s'agit alors d'écrire un serveur MCP sur mesure, en s'appuyant sur les kits de développement Python ou TypeScript publiés par Anthropic. Le bénéfice attendu n'est pas immédiat pour le premier assistant connecté, mais cumulatif : chaque nouveau client compatible qui apparaîtra ensuite pourra se brancher sur ce même serveur sans travail supplémentaire côté équipe.

Pour un éditeur de logiciel qui construit un produit s'appuyant sur un modèle de langage, l'enjeu est différent encore : adopter MCP côté client permet d'hériter, sans les développer soi-même, de tous les serveurs déjà écrits par la communauté et par Anthropic. C'est précisément le calcul qu'ont fait Zed, Replit, Codeium et Sourcegraph dès les premières semaines : plutôt que de construire chacun leur propre catalogue d'intégrations, ils misent sur un écosystème partagé qui grandira plus vite collectivement que ce qu'aucun d'entre eux n'aurait pu construire seul.

Le vrai test d'un protocole d'intégration ne se joue pas le jour de son annonce, mais dans les mois qui suivent : combien de serveurs indépendants voient le jour, et combien de clients différents apprennent à s'y connecter.

Un connecteur, pas une révolution du modèle

Il faut, pour finir, remettre les choses à leur juste échelle. Le Model Context Protocol n'améliore en rien les capacités de raisonnement d'un modèle de langage : il ne rend pas Claude plus intelligent au sens strict. Ce qu'il change, c'est la facilité avec laquelle ce modèle peut atteindre l'information et les outils dont il a besoin pour être utile dans un contexte réel — un fichier sur un disque, une ligne dans une base de données, un message dans un canal Slack.

C'est précisément ce qui rend l'initiative intéressante à suivre plutôt que spectaculaire à annoncer : un standard d'intégration ne se juge pas sur sa présentation, mais sur son adoption dans la durée. Les premiers signaux sont, à ce stade, encourageants — un catalogue de serveurs de référence déjà étoffé, des partenaires venus d'horizons différents (paiement, API, éditeurs de code), une documentation qui prend au sérieux les questions de sécurité et de consentement dès le premier jour, et une communauté technique qui s'empare du sujet avec des questions précises plutôt qu'un enthousiasme de façade.

Pour qui suit l'évolution des assistants IA, la bonne posture consiste à observer, dans les semaines et les mois qui viennent, deux indicateurs simples : combien de nouveaux serveurs, écrits par des tiers indépendants d'Anthropic, viennent enrichir le catalogue initial ; et combien d'applications, au-delà de Claude Desktop, apprennent à leur tour à parler ce même protocole. C'est cette double dynamique — côté offre et côté demande — qui déterminera si MCP devient effectivement le connecteur universel qu'il ambitionne d'être, ou s'il reste une bonne idée parmi d'autres dans un secteur qui n'en manque pas.

Sources

Cet article s'appuie sur des sources publiques et vérifiables, consultées à la date de rédaction :

• Anthropic, « Introducing the Model Context Protocol » — anthropic.com (annonce officielle, partenaires, principes de sécurité).
• Model Context Protocol, documentation officielle — « Architecture overview » — modelcontextprotocol.io (hôtes, clients, serveurs, primitives, JSON-RPC).
• Model Context Protocol, documentation officielle — « Connect to local MCP servers » — modelcontextprotocol.io (configuration pratique de Claude Desktop).
• GitHub, dépôt « modelcontextprotocol/servers » — github.com (liste des serveurs de référence maintenus par Anthropic).
• GitHub, dépôt « modelcontextprotocol/servers-archived » — github.com (catalogue des premiers serveurs de référence).
• Sourcegraph, « Cody supports additional context through Anthropic's Model Context Protocol » — sourcegraph.com (adoption par un éditeur d'outils de développement).
• Le Monde Informatique, « Anthropic veut standardiser la contextualisation des modèles » — lemondeinformatique.fr (couverture francophone, principes de sécurité).
• InfoQ, « Anthropic Publishes Model Context Protocol Specification for LLM App Integration » — infoq.com (réactions de la communauté, citation de Justin Spahr-Summers).
• Hacker News, discussion sur l'annonce du Model Context Protocol — news.ycombinator.com (questions et retours de développeurs).
• Wikipedia, « Model Context Protocol » — en.wikipedia.org (repères généraux et chronologiques).