Le Protocole Modèle-Contexte (Model Context Protocol | MCP)
Mes notes traduites du cours sur les MCP d’HuggingFace
Concepts clés et terminologie
Le problème d’intégration
Le protocole modèle-contexte sert a résoudre le problème d’intégration, où lorsqu’on considère $M$ modèles et $N$ capacités externes il faudrait alors développer une interface unique pour chaque modèle et chaque capacité externe soit $M\times N$ interfaces.

Le protocole modèle contexte permet de résoudre ceci en proposant une unique interface qui transforme ainsi le problème en M+N.

Terminologie
Composants
- Hôte : L’application IA côté utilisateur, avec laquelle ils interagissent directement. L’hôte initie les connections aux serveurs MCP et orchestre les requêtes des utilisateurs, les traitement des modèles et les outils externes.
- Client : Il s’agit d’un composant à l’intérieur de l’hôte qui s’occupe des communications avec un serveur MCP spécifique. Chaque client maintient une connection 1:1 avec un seul serveur, s’occupant des détails protocolaire du serveur MCP et agissant comme intermédiaire entre la logique de l’hôte et le serveur externe.
- Serveur : C’est un programme externe ou un service qui expose des capacités (Outils, Ressources, Prompts) via le protocole MCP.
Capacités
MCP peut se connecter avec n’importe quel service logiciel, cependant il y a des types de capacités communs qui sont utilisés par de nombreux modèles d’IA:
Capability | Description | Example |
---|---|---|
Tools | Executable functions that the AI model can invoke to perform actions or retrieve computed data. Typically relating to the use case of the application | A tool for a weather application might be a function that returns the weather in a specific location. |
Resources | Read-only data sources that provide context without significant computation. | A researcher assistant might have a resource for scientific papers. |
Prompts | Pre-defined templates or workflows that guide interactions between users, AI models, and the available capabilities. | A summarization prompt. |
Sampling | Server-initiated requests for the Client/Host to perform LLM interactions, enabling recursive actions where the LLM can review generated content and make further decisions. | A writing application reviewing its own output and decides to refine it further. |
Le protocole de communication
JSON-RPC
MCP utilise en son centre le format de message JSON-RPC 2.0. Ce protocole différencie 3 types de messages.
Les requêtes
Envoyées depuis le client vers le serveur, elles incluent :
- un identifiant unique
id
- le nom de la méthode à invoquer
tools/call
- les paramètres de la méthode (s’il y en a).
Exemple :
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "weather",
"arguments": {
"location": "San Francisco"
}
}
}
Les réponses
Envoyées depuis le serveur vers le client, elles incluent :
- le même identifiant unique
id
que la requête correspondante - soit un résultat
result
(si succès de la requête) ou une erreurerror
(en cas d’échec).
Exemple de réponse réussie:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"temperature": 62,
"conditions": "Partly cloudy"
}
}
Exemple de réponse échouée:
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32602,
"message": "Invalid location parameter"
}
}
Les notifications
Des messages à sens unique ne nécessitant pas de réponses typiquement envoyées du serveur vers le client pour lui fournir des mises à jours ou des notifications sur les évènements.
Exemple :
{
"jsonrpc": "2.0",
"method": "progress",
"params": {
"message": "Processing data...",
"percent": 50
}
}
Méchanismes de communication
MCP définit le format mais également comment ces messages sont transportés entre le client et le serveur. Deux méchanismes de communication principaux sont utilisés.
stdio (standard input/output)
Utilisé lorsque client et serveur tournent sur la même machine : l’application hôte lance le serveur comme sous-processus et communique avec en écrivant à son entrée standard stdin et en lisant de sa sortie standard stdout
HTTP + SSE (Serveur-Sent Events) / Streamable HTTP
- Utilisé pour de la communication à distance entre client et serveur (machines différentes) : la communication arrive par http, avec le serveur qui utilise des SSE (évènements envoyés par le serveur) afin de
push
des mises à jours au Client à travers une connection persistantes. - Une mise à jour récente du standard MCP à introduit ou raffiné le “HTTP streamable” qui offre plus de flexibilité en permettant aux serveurs de passer dynamiquement aux SSE si besoin, tout en maintenant la compatibilité avec les environnements sans serveur.
Cycle de vie d’une interaction
- Initialisation : Le client se connecte au serveur et ils échangent les versions du protocole et leur capacités, et le serveur répond avec sa version de protocole supportée et les capacités. Le client confirme que l’initialisation est complète via un message de notification (donc client $\rightarrow$ initialise $\rightarrow$ serveur $\rightarrow$ réponse $\rightarrow$ client $\rightarrow$ initialisé (notif) $\rightarrow$ serveur )
- Découverte : Le client demande des informations sur les capacités disponibles sur le serveur, qui répond par une liste des outils disponibles. Ce processus peut être répété pour chaque outil, ressource ou type de prompt (=invite). Donc client $\rightarrow$ tools/list $\rightarrow$ serveur $\rightarrow$ réponse $\rightarrow$ client .
- Exécution : Le client invoque des capacités selon les besoins de l’hôte. Donc client $\rightarrow$ tools/call $\rightarrow$ serveur ($\rightarrow$ notification (progrès optionnel) $\rightarrow$ client) ; sinon serveur $\rightarrow$ réponse $\rightarrow$ client
- Fin : La connection est fermée lorsqu’elle n’est plus nécessaire et le serveur reconnaît la requête d’arrêt. Le client envoie le message de sortie final pour compléter cette phase. Soit client $\rightarrow$ shutdown $\rightarrow$ serveur $\rightarrow$ réponse $\rightarrow$ client $\rightarrow$ exit $\rightarrow$ serveur.
Références
Enjoy Reading This Article?
Here are some more articles you might like to read next: