Un serveur MCP est un programme qui offre des outils, des ressources et des prompts aux applications d'IA via le Model Context Protocol. Voyez les vrais messages JSON, étape par étape.
Qu'est-ce qu'un serveur MCP ?
Un serveur MCP est un programme qui donne aux applications d'IA de quoi travailler via le Model Context Protocol : des outils qu'elles peuvent appeler, des ressources qu'elles peuvent lire et des prompts que les utilisateurs peuvent choisir. L'application se connecte via un client MCP, et les deux côtés échangent des messages JSON-RPC 2.0 sur stdio en local ou sur Streamable HTTP à distance.
Les trois choses qu'un serveur peut offrir
Primitive
Ce que c'est
Qui décide de l'utiliser
Méthodes principales
Outils
Des fonctions qui effectuent une action, avec un JSON Schema pour leur entrée
Le modèle
tools/list, tools/call
Ressources
Des données en lecture seule désignées par une URI, comme un fichier ou un schéma
L'application
resources/list, resources/read
Prompts
Des modèles d'instructions réutilisables avec des arguments
L'utilisateur
prompts/list, prompts/get
Parcourez ci-dessous un véritable échange. Chaque étape montre le JSON qu'envoie un client et ce que répond le serveur, avec les formes de messages de la spécification actuelle (version 2026-07-28). Lire les messages bruts est le moyen le plus rapide de cesser de voir un serveur comme de la magie.
Choisissez une étape : découverte, liste des outils, appel d'un outil ou réception d'une notification de changement.
Lisez la requête à gauche et la réponse à droite.
Consultez la note sous la paire pour le champ le plus important de cette étape.
Copiez n'importe quel message pour le comparer à ce qu'envoie votre propre serveur ou client.
Nommez les outils avec un préfixe clair, comme weather_current plutôt que get. Un hôte peut charger des outils de nombreux serveurs à la fois, et les noms vagues entrent en collision.
Écrivez la description de chaque outil pour le modèle, pas pour un humain qui survole une liste. Dites ce que fait l'outil et quand il doit être choisi.
Exposez le contexte en lecture seule sous forme de ressources plutôt que d'outils. Les ressources laissent l'application décider de ce qu'elle inclut, ce qui évite au modèle de récupérer des données dont il n'a pas besoin.
Considérez comme risqué tout outil qui modifie quelque chose. Le protocole laisse la validation à l'hôte, concevez donc des outils qu'il est sûr de confirmer un appel à la fois.
Questions fréquentes
Un serveur MCP est-il la même chose qu'une API ?
Il en enveloppe généralement une. Un serveur typique appelle une API ou une base de données existante et décrit ces opérations de façon standard, pour que toute application compatible MCP puisse les découvrir et les appeler sans code d'intégration sur mesure.
Un serveur MCP tourne-t-il sur mon ordinateur ou dans le cloud ?
Les deux sont possibles. Un serveur local est lancé par l'application et communique via l'entrée et la sortie standard. Un serveur distant tourne ailleurs et se joint via Streamable HTTP, où il peut servir de nombreux clients.
Un serveur MCP contient-il un modèle de langage ?
Non. Le serveur offre uniquement des outils, des ressources et des prompts. L'application hôte possède le modèle et décide de ce qu'elle lui envoie. La spécification marque le sampling demandé par le serveur comme obsolète depuis la version 2026-07-28.
Qu'est-ce qui a changé dans la version 2026-07-28 du protocole ?
Le protocole est devenu sans état : chaque requête porte la version du protocole et les capacités dans son champ _meta, et les serveurs répondent à une requête server/discover obligatoire. Les notifications de changement sont désormais facultatives et s'activent via un flux subscriptions/listen.
Qui valide un appel d'outil ?
L'hôte. La documentation du protocole suggère des boîtes de dialogue de validation, des réglages de permissions et des journaux d'activité, mais les faire respecter est le rôle de l'application, donc un serveur ne doit jamais supposer qu'une personne a vérifié un appel.
Hôte, client et serveur
Trois rôles apparaissent dans chaque configuration. L'hôte est l'application d'IA qu'utilise la personne. Pour chaque serveur auquel il se connecte, l'hôte crée un client, et chaque client garde une connexion dédiée à exactement un serveur.
Un hôte relié à un serveur de fichiers et à un serveur de base de données détient donc deux clients. Le serveur est simplement le programme qui répond, où qu'il tourne.
Deux couches : données et transport
La couche de données définit les messages : requêtes, réponses et notifications JSON-RPC 2.0 pour la découverte, les outils, les ressources et les prompts. La couche de transport achemine ces messages et gère l'établissement de la connexion et l'autorisation.
Il existe deux transports standard. Stdio fait passer les messages par l'entrée et la sortie standard entre des processus d'une même machine. Streamable HTTP utilise HTTP POST du client vers le serveur, avec des Server-Sent Events optionnels pour le streaming, et prend en charge les bearer tokens, les clés d'API et OAuth.
Ce que le client peut offrir en retour
Les serveurs peuvent aussi demander des choses au client. L'élicitation permet à un serveur de demander à l'utilisateur plus d'informations ou une confirmation via la méthode elicitation/create.
Le sampling, où un serveur demande à l'hôte une complétion du modèle, et la journalisation au niveau du protocole sont obsolètes depuis la version 2026-07-28. Les nouveaux serveurs doivent journaliser sur stderr en stdio ou utiliser OpenTelemetry.
Stdio ou Streamable HTTP ?
Choisir un transport
Stdio
Streamable HTTP
Où tourne le serveur
Même machine, lancé par l'hôte
N'importe où, tant qu'il est joignable par le réseau
stderr (stdout transporte les messages du protocole)
Vos journaux de serveur habituels
À quoi ressemble un modèle de ressource
Un modèle de ressource avec un paramètre d'URI
Les clients trouvent les modèles avec resources/templates/list, remplissent les accolades et lisent le résultat avec resources/read.
1. Découverte
server/discover est facultatif pour le client mais chaque serveur doit y répondre. L'objet capabilities indique quelles primitives existent ; listChanged signifie que le serveur peut notifier les changements d'outils.
2. Lister les outils
Chaque outil porte un name, une description et un inputSchema écrit en JSON Schema. L'hôte les transmet au modèle pour qu'il sache ce qu'il peut appeler.
3. Appeler un outil
Le nom doit correspondre exactement à l'outil listé et les arguments doivent respecter son inputSchema. Les résultats reviennent sous forme de tableau content, ici un seul élément texte.
4. Notification de changement
Les notifications n'ont pas d'id, donc personne n'y répond. Le client ne reçoit celle-ci que parce qu'il a ouvert un flux subscriptions/listen demandant toolsListChanged.