Glossaire

Glossaire du MCP et de l’accès des agents

Les 36 termes employés dans cet annuaire, expliqués simplement : les composants du Model Context Protocol, la façon de joindre les serveurs et de s’y authentifier, ce qu’enregistre le MCP Registry et les fichiers qu’un site peut publier à l’intention des systèmes d’IA. Chacun renvoie à l’article ou à l’index qui approfondit le sujet.

Le protocole

Model Context Protocol (MCP)
Protocole ouvert permettant de connecter des applications d’IA à des outils et à des données externes. Il définit comment une application et un serveur se décrivent mutuellement leurs capacités et échangent des requêtes, de sorte qu’un même serveur fonctionne avec toutes les applications qui prennent en charge le protocole. Publié par Anthropic en novembre 2024, il est développé de manière ouverte ; les versions de la spécification portent le nom d’une date, par exemple 2024-11-05, 2025-03-26 et 2025-06-18. Qu’est-ce qu’un serveur MCP ? →
Serveur MCP
Programme qui met des outils, des ressources ou des prompts à la disposition d’applications d’IA via MCP. Il peut être distant, c’est-à-dire exploité par son éditeur et accessible à une URL, ou local, c’est-à-dire lancé sur l’ordinateur de l’utilisateur. Un serveur couvre généralement un seul service ou un seul type de données : un moteur de réservation, une carte, un hébergeur de code, une base de données. Serveurs du MCP Registry ayant une page ici →
Client MCP
Partie d’une application d’IA qui maintient la connexion avec un serveur MCP. Une application connectée à trois serveurs fait tourner trois clients, chacun dialoguant avec son propre serveur. Comment ajouter un serveur à un assistant →
Hôte MCP
Application d’IA dans laquelle travaille l’utilisateur : assistant conversationnel, application de bureau, éditeur de code, agent en ligne de commande. L’hôte lance les clients, décide à quels serveurs ils se connectent, transmet au modèle de langage ce que proposent les serveurs et demande le consentement de l’utilisateur avant toute action.
Outil
Fonction qu’un serveur propose au modèle d’appeler : elle possède un nom, une description qui indique au modèle quand l’utiliser et un JSON Schema pour ses entrées. Rechercher des vols, obtenir un tableau des départs ou créer un ticket sont des outils. Le modèle décide quand en appeler un ; les hôtes demandent généralement à l’utilisateur d’approuver un appel qui modifie quelque chose.
Ressource
Données qu’un serveur met à disposition en lecture, chacune identifiée par une URI : un fichier, un enregistrement de base de données, un document. C’est en général l’application, et non le modèle, qui décide quelles ressources intégrer à la conversation.
Prompt
Modèle de message réutilisable proposé par un serveur, souvent avec des arguments, que l’utilisateur choisit dans l’application (par exemple sous forme de commande slash) pour lancer une tâche de la manière prévue par l’auteur du serveur.
Sampling (échantillonnage)
Requête d’un serveur au client pour que le modèle de langage de l’application génère du texte, ce qui permet à un serveur d’utiliser un modèle sans détenir sa propre clé d’API. L’hôte garde le contrôle et peut montrer la requête à l’utilisateur.
Elicitation (élicitation)
Requête par laquelle un serveur, via le client, demande des informations supplémentaires à l’utilisateur (une date manquante, une confirmation), qui y répond dans un formulaire affiché par l’application. Ajoutée dans la révision 2025-06-18 de la spécification.
JSON-RPC 2.0
Format de message utilisé par MCP : chaque requête, réponse ou notification est un petit objet JSON. Une connexion commence par un échange initialize, au cours duquel le client et le serveur s’accordent sur la version du protocole et déclarent les capacités que chacun prend en charge.

Transports et authentification

Transport
Manière dont les messages MCP circulent entre le client et le serveur. La spécification définit stdio pour les serveurs locaux et Streamable HTTP pour les serveurs distants ; l’ancien transport HTTP avec Server-Sent Events se rencontre encore. L’entrée d’un serveur dans le registre indique les transports qu’il prend en charge. Serveurs par transport →
stdio
Le transport local : le client lance le serveur comme programme sur le même ordinateur et échange les messages via son entrée et sa sortie standard, à raison d’un message JSON par ligne. Rien n’écoute sur le réseau, et le programme s’exécute avec les droits de l’utilisateur. Serveurs locaux en stdio →
Streamable HTTP
Le transport actuel des serveurs distants, introduit dans la révision 2025-03-26 : un unique point de terminaison HTTPS auquel le client envoie ses messages en POST, et qui répond par une réponse JSON unique ou par un flux Server-Sent Events. Un serveur peut maintenir une session, identifiée dans un en-tête Mcp-Session-Id. Serveurs distants en Streamable HTTP →
SSE (HTTP + Server-Sent Events)
Le transport distant de la première révision (2024-11-05) : le client garde ouvert un flux Server-Sent Events pour recevoir les messages et envoie les siens en POST à une seconde URL indiquée par le serveur. Streamable HTTP l’a remplacé dans la révision 2025-03-26 ; de nombreux clients l’acceptent encore. Les transports MCP expliqués →
Serveur distant
Serveur MCP exploité par son éditeur et accessible à une URL HTTPS. Rien n’est installé ; l’éditeur l’exploite et le met à jour, et vos demandes transitent par ses systèmes. Distant ou local ? →
Serveur local
Serveur MCP installé à partir d’un paquet et lancé sur l’ordinateur de l’utilisateur, généralement en stdio. Il peut accéder aux fichiers et aux applications locales, et ses clés restent dans la configuration du client. Distant ou local ? →
OAuth pour MCP (autorisation MCP)
Manière dont un serveur distant demande à un utilisateur de se connecter. La partie autorisation de la spécification, apparue dans la révision 2025-03-26, s’appuie sur OAuth 2.1 : le client envoie l’utilisateur vers la page de connexion du service lui-même, reçoit un jeton d’accès et l’envoie avec chaque requête. Depuis la révision 2025-06-18, un serveur MCP est traité comme un serveur de ressources OAuth qui publie des métadonnées désignant son serveur d’autorisation (RFC 9728). Elle s’applique aux transports HTTP ; un serveur stdio local tire plutôt ses identifiants de variables d’environnement. Avant de connecter un serveur →
En-têtes déclarés
En-têtes HTTP qu’un client doit envoyer selon l’entrée d’un serveur distant dans le registre, comme Authorization avec une clé d’API. L’entrée indique pour chacun s’il est obligatoire ou facultatif, et s’il est secret ou non.
Variables d’environnement
Valeurs nommées, souvent des clés d’API, qu’un serveur local lit lorsque le client le lance. L’entrée du registre liste celles qu’attend son paquet ; la configuration du client les définit.

Le MCP Registry

MCP Registry
Le catalogue public officiel des serveurs MCP, à l’adresse registry.modelcontextprotocol.io, géré par le projet MCP et lancé en préversion en septembre 2025. Il ne contient que des métadonnées (noms, descriptions, versions, points de terminaison et paquets), avec une API ouverte en lecture seule, et compte sur les catalogues construits à partir de lui, comme cet annuaire, pour ajouter leur propre sélection. Qu’est-ce que le MCP Registry officiel ? →
Espace de noms (namespace)
Partie d’un nom de registre située avant la barre oblique, en notation DNS inversée. io.github.<compte> est attribué à quiconque se connecte au registre avec GitHub sous ce compte utilisateur, ou avec les droits que le registre exige dans cette organisation (sa documentation demande désormais un propriétaire de l’organisation) ; un domaine inversé comme com.example, à quiconque prouve qu’il contrôle example.com par un enregistrement DNS (qui couvre aussi ses sous-domaines) ou par un fichier servi à l’adresse /.well-known/mcp-registry-auth. Il indique qui a publié une entrée, et non que l’entrée est approuvée par le produit avec lequel elle fonctionne. Serveurs par éditeur →
server.json
Fichier qu’un éditeur soumet au registre pour décrire un serveur : son nom, sa description, sa version, éventuellement un titre, un site web et un dépôt, et la manière de le joindre (remotes et packages).
Types de paquets
Registres de paquets sur lesquels un serveur local peut être publié, indiqués dans son entrée de registre : npm (Node.js), PyPI (Python), images OCI (Docker et autres registres de conteneurs), NuGet (.NET), Cargo (crates Rust) et MCP Bundles. Le type indique au client l’environnement d’exécution nécessaire. Serveurs par registre de paquets →
Paquet npm
Paquet Node.js issu du registre npm. Les clients le lancent généralement avec npx, qui le télécharge à la première utilisation ; Node.js doit être installé. Serveurs npm →
Paquet PyPI
Paquet Python issu de PyPI. Les clients le lancent généralement avec uvx, de l’outil uv, qui l’exécute dans un environnement isolé, ou après l’avoir installé avec pip. Serveurs PyPI →
Image OCI
Image de conteneur hébergée dans un registre OCI comme Docker Hub ou GitHub Container Registry, lancée avec docker run. Le serveur s’exécute dans le conteneur plutôt que directement sur l’ordinateur. Serveurs en image de conteneur →
MCP Bundle (.mcpb)
Archive unique contenant un serveur MCP local et un fichier manifest.json qui le décrit, afin qu’un client compatible avec ce format puisse l’installer en une seule étape. Le format s’appelait auparavant Desktop Extensions (.dxt). Serveurs MCP Bundle →
Version et statut
Chaque publication dans le registre ajoute une version qui ne change plus ensuite ; la plus récente est marquée comme dernière version (latest). Le statut d’une entrée est actif (active), obsolète (deprecated) ou supprimé (deleted). Cet annuaire lit la dernière version et écarte les entrées obsolètes et supprimées.

Fichiers et descriptions sur le site du service

llms.txt
Fichier Markdown placé à la racine d’un site, /llms.txt, proposé en septembre 2024 sur llmstxt.org, qui indique aux modèles de langage ce qu’est le site et donne des liens vers ses pages les plus utiles, chacune avec une courte note. Il n’autorise ni n’interdit rien : c’est un plan. Cet annuaire ne le compte comme présent que si le site répond avec un vrai fichier texte, et non une page HTML. Que mettre dans un fichier llms.txt →
OpenAPI
Format standard, lisible par une machine, pour décrire une API HTTP (ses points de terminaison, paramètres, réponses et mode d’authentification) en JSON ou en YAML, anciennement connu sous le nom de Swagger. Les frameworks d’agents peuvent transformer ses opérations en outils. OpenAPI pour les agents IA →
ai-plugin.json
Manifeste situé à l’adresse /.well-known/ai-plugin.json, introduit en 2023 pour les plugins ChatGPT : il nomme le service, le décrit pour le modèle et pointe vers une description OpenAPI. Le système de plugins a depuis été abandonné, mais certains sites servent encore le fichier. OpenAPI pour les agents IA →
/.well-known/mcp.json
Fichier que certains sites servent pour décrire leur serveur MCP (point de terminaison, transport et connexion), afin que les clients et les catalogues puissent le trouver à partir du seul domaine. Il ne fait partie d’aucune révision publiée de la spécification, et les fichiers rencontrés en pratique diffèrent par leur structure ; cet annuaire enregistre si un site y répond avec un objet JSON.
agents.json
Fichier JSON proposé, servi à l’adresse /agents.json, qui décrit les opérations d’une API et les enchaînements en plusieurs étapes qu’un agent peut réaliser avec elles, en s’appuyant sur OpenAPI. Peu de sites en publient un ; cet annuaire enregistre si un site y répond avec un objet JSON.
Application ChatGPT
Application qu’un service publie dans ChatGPT. Les applications sont développées avec l’Apps SDK d’OpenAI, fondé sur MCP, et peuvent afficher des résultats interactifs dans la conversation ; l’utilisateur doit connecter une application avant que ChatGPT puisse l’appeler. Services avec une application ChatGPT →
Connecteur Claude
Serveur MCP distant ajouté à Claude, depuis le répertoire de connecteurs d’Anthropic ou par URL, pour que Claude puisse lire des données de ce service ou y effectuer des actions une fois que l’utilisateur l’a connecté. Services avec un connecteur Claude →
API publique
API documentée que chacun peut appeler après inscription, généralement avec une clé fournie par le service. C’est ainsi que les agents développés sur mesure accèdent à un service qui n’a pas de serveur MCP. Services avec une API publique →

Pour aller plus loin

Tous les articles de la rubrique Comprendre · Serveurs du MCP Registry · Éditeurs · Charte éditoriale