MCP : Plongée dans l’Architecture Client-Serveur MCP

Le Model Context Protocol (MCP), introduit par Anthropic et désormais adopté par un écosystème croissant (Cursor, Zed, Cloudflare, Google Cloud), s’impose comme le “USB-C” de l’intelligence artificielle.

Pour les ingénieurs, MCP n’est pas simplement une couche de tool calling. C’est un protocole de communication stateful (à état) qui normalise la manière dont un LLM accède aux données et aux outils.

1. L’Architecture Tripartite : Host, Client et Serveur

L’écosystème MCP repose sur une séparation stricte des responsabilités. Comprendre cette hiérarchie est crucial pour concevoir des intégrations robustes.

Rôle	Composant	Responsabilité
Hôte (Host)	IDE, App Desktop	Orchestre l’UX et détient le contexte global de la session.
Client MCP	Couche Protocolaire	Maintient la connexion, découvre les capacités et traduit les requêtes.
Serveur MCP	Processus local/distant	Expose des ressources spécifiques (BBDD, API, Fichiers).

2. Le Transport : JSON-RPC 2.0 et Canaux de Communication

Le MCP utilise JSON-RPC 2.0 comme format d’échange. Ce choix permet une sérialisation simple et une interopérabilité maximale. Le protocole supporte principalement deux types de transport :

Stdio (Standard Input/Output) : Utilisé pour les serveurs locaux. L’Hôte lance le serveur comme un processus fils et communique via les flux stdin et stdout.
SSE (Server-Sent Events) : Utilisé pour les serveurs distants. Le client envoie des requêtes via HTTP POST, et le serveur répond via un flux d’événements persistants.

Exemple d’une requête de découverte (`tools/list`)

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

Les Primitives Fondamentales

Un serveur MCP expose trois types de capacités via des points de terminaison standardisés :

Resources (Données Passives)

Les ressources sont des sources de données en lecture seule. Elles permettent au modèle de “lire” un contexte.

Exemple : Un log de serveur ou le contenu d’un fichier .csv.

Identification : Les ressources utilisent des URI (ex: postgres://db/table/schema).

Tools (Actions Actives)

Contrairement aux ressources, les outils permettent au modèle d’effectuer des actions.

Exemple : Exécuter une requête SQL ou envoyer un email.

Validation : Chaque outil définit un schéma JSON (paramsSchema) pour valider les arguments.

Prompts (Modèles Réutilisables)

Les serveurs peuvent exposer des “Prompts” pré-configurés (templates) qui aident l’utilisateur à structurer ses interactions avec les données du serveur.

Le Cycle de Vie d’une Connexion (Handshake)

L’établissement d’une connexion MCP suit une séquence rigoureuse de négociation :

Initialize : Le client envoie ses capacités (version du protocole, fonctionnalités supportées).

Response : Le serveur répond avec ses propres métadonnées.

Initialized Notification : Le client confirme la fin de la négociation. Le flux est ouvert.

Implémentation : Créer un Serveur FastMCP (Python)

Grâce au SDK de FastMCP, la création d’un serveur est devenue triviale. Voici un exemple d’un serveur exposant un outil météo :

from mcp.server.fastmcp import FastMCP

# Initialisation du serveur
mcp = FastMCP("WeatherService")

@mcp.tool()
def get_temperature(city: str) -> str:
    """Récupère la température actuelle pour une ville donnée."""
    # Logique d'appel API réelle ici
    return f"La température à {city} est de 22°C"

if __name__ == "__main__":
    mcp.run()

Conclusion : Pourquoi MCP change la donne ?
Avant les MCP, chaque développeur devait écrire des connecteurs personnalisés pour chaque plateforme. Avec un MCP, vous écrivez votre serveur une seule fois, et il devient instantanément compatible avec n’importe quel client (Claude Desktop, Cursor, etc.).

Note technique : L’abstraction déplace l’intelligence de l’intégration vers la donnée elle-même, rendant les agents IA véritablement portables.

Plongée dans l’Architecture Client-Serveur MCP