Maîtriser le Model Context Protocol
Architecture MCP
L'architecture MCP
Les modèles de langage (LLM) sont puissants, mais leur connaissance est limitée aux données sur lesquelles ils ont été entraînés. Pour effectuer des tâches dans le monde réel, comme lire un fichier sur votre ordinateur ou interroger une base de données, ils ont besoin d'accéder à des outils externes. Historiquement, chaque intégration était une solution personnalisée, fragile et difficile à maintenir. Le Model Context Protocol (MCP) résout ce problème en créant un standard ouvert pour cette communication.
Le MCP est essentiellement une interface universelle qui remplace une multitude de connecteurs ad-hoc par un langage commun et structuré.
Au cœur du MCP se trouve une architecture client-serveur classique. Les rôles sont clairement définis pour garantir une communication simple et fiable.
| Rôle | Description |
|---|---|
| Hôte MCP (Client) | C'est l'application que vous utilisez, comme un IDE (environnement de développement intégré) ou Claude Desktop. L'hôte initie les connexions et envoie des requêtes au nom du LLM. |
| Serveur MCP | C'est un service qui expose des outils et des ressources. Il écoute les requêtes de l'hôte, exécute la tâche demandée (par exemple, lire un fichier) et renvoie le résultat. |
Le protocole de communication
Pour que cette architecture fonctionne, le client et le serveur doivent parler le même langage. MCP utilise comme protocole de transport. C'est un protocole léger d'appel de procédure à distance qui utilise JSON pour formater les messages. L'hôte envoie une requête contenant le nom d'une méthode à exécuter et ses paramètres, et le serveur renvoie une réponse, également au format JSON.
Ce choix rend la communication efficace et facile à déboguer, car les messages sont lisibles par l'homme.
// Requête de l'hôte au serveur
{
"jsonrpc": "2.0",
"method": "fs/readFile",
"params": {
"path": "/home/user/document.txt"
},
"id": 1
}
// Réponse du serveur à l'hôte
{
"jsonrpc": "2.0",
"result": {
"content": "Ceci est le contenu du fichier."
},
"id": 1
}
Capacités et flux de messages
Comment l'hôte sait-il quelles méthodes il peut appeler ? Le serveur ne se contente pas d'exécuter des commandes ; il doit d'abord annoncer ce qu'il peut faire. C'est là qu'intervient le concept de (capabilities).
Lorsqu'un client se connecte à un serveur MCP, la première chose qu'il fait est de demander la liste des capacités du serveur. Cette liste est une description structurée et lisible par machine de tous les outils disponibles, y compris les noms des méthodes, les paramètres qu'elles attendent et le format des données qu'elles retournent. C'est comme un menu que le LLM peut lire pour décider quelle action entreprendre.
Le flux de communication standardisé se déroule donc comme suit :
- Connexion : L'hôte MCP établit une connexion avec le serveur MCP.
- Découverte : L'hôte demande au serveur sa liste de capacités (
mcp/capabilities).- Exécution : Le LLM, via l'hôte, décide d'utiliser un outil et envoie une requête JSON-RPC pour exécuter la méthode correspondante.
- Réponse : Le serveur exécute la tâche et renvoie le résultat (ou une erreur) à l'hôte.
Cette architecture simple mais puissante permet à n'importe quel LLM, via un hôte compatible MCP, de se connecter et d'utiliser n'importe quel outil exposé par un serveur MCP, sans avoir besoin de code d'intégration personnalisé. C'est cette standardisation qui rend MCP si prometteur pour l'écosystème de l'IA.
Quel est le problème principal que le Protocole de Contexte de Modèle (MCP) cherche à résoudre ?
Quel protocole de transport est utilisé par le MCP pour formater les messages entre le client et le serveur ?
Dans la section suivante, nous verrons comment construire votre propre serveur MCP.