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.

Interfaces (MxN) sans MCP

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

Interfaces (M+N) avec MCP

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 erreur error (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

  1. 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 )
  2. 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 .
  3. 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
  4. 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:

  • L'encodage positionnel
  • Réseaux de Kolmogorov Arnold (KAN)