MCP : Architecture du Model Context Protocol

Qu'est-ce que MCP ?

Le Model Context Protocol (MCP) est un protocole ouvert, initié par Anthropic, qui standardise la manière dont les grands modèles de langage se connectent à des sources de données et des outils externes. Pensez-y comme le USB-C de l'intelligence artificielle : avant MCP, chaque intégration LLM–outil nécessitait un connecteur propriétaire différent. MCP propose une interface universelle qui permet à n'importe quel modèle compatible de communiquer avec n'importe quel serveur d'outils, de manière sécurisée et structurée.

L'analogie USB-C est particulièrement éclairante. Tout comme USB-C a unifié les câbles de charge, de données et de vidéo en un seul connecteur, MCP unifie l'accès aux fichiers locaux, aux bases de données, aux APIs tierces et aux outils de développement derrière un protocole unique. Cette standardisation élimine la fragmentation qui caractérisait l'écosystème des « function calling » propriétaires.

MCP repose sur JSON-RPC 2.0 comme couche de transport, ce qui garantit une communication structurée, bidirectionnelle et indépendante du langage de programmation. Le protocole est conçu pour être stateful : une connexion persistante est maintenue entre le client et le serveur, permettant des interactions contextuelles riches au fil d'une conversation.

Architecture Client-Serveur

L'architecture MCP s'articule autour de trois rôles fondamentaux, chacun avec des responsabilités clairement délimitées :

Les trois rôles

Host — L'application hôte (IDE, chatbot, agent autonome) qui initie la connexion. Le host est le point d'entrée utilisateur : il orchestre un ou plusieurs clients MCP et applique les politiques de sécurité (consentement utilisateur, sandboxing).
Client — Le composant intermédiaire qui maintient une connexion 1:1 avec un serveur MCP spécifique. Le client traduit les requêtes du host en messages JSON-RPC conformes au protocole.
Server — Le processus qui expose des capacités (outils, ressources, prompts) via le protocole MCP. Chaque serveur est spécialisé : un serveur pour le filesystem, un autre pour GitHub, un autre pour une base de données, etc.

architecture_mcp.txt Diagramme

┌─────────────────────────────────────────────┐
│                    HOST                     │
│           (IDE, Chatbot, Agent)              │
│                                             │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ Client A │  │ Client B │  │ Client C │  │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  │
│       │              │              │       │
└───────┼──────────────┼──────────────┼───────┘
        │              │              │
   JSON-RPC       JSON-RPC       JSON-RPC
   (stdio)        (SSE/HTTP)     (stdio)
        │              │              │
   ┌────▼────┐    ┌────▼────┐   ┌────▼────┐
   │ Server  │    │ Server  │   │ Server  │
   │  Files  │    │ GitHub  │   │   DB    │
   └─────────┘    └─────────┘   └─────────┘

Ce modèle d'architecture garantit une séparation des préoccupations stricte. Le host ne connaît pas les détails d'implémentation des serveurs. Les serveurs ne savent rien du modèle de langage utilisé. Le client assure la médiation en respectant le contrat du protocole.

Primitives du Protocole

MCP définit trois catégories de capacités qu'un serveur peut exposer. Chaque primitive a un rôle distinct dans l'enrichissement du contexte du LLM :

Tools (Outils)

Fonctions exécutables que le LLM peut invoquer pour agir sur le monde extérieur : lire un fichier, exécuter une requête SQL, appeler une API REST, lancer un build CI/CD. Le modèle décide quand et avec quels arguments appeler l'outil ; le serveur exécute et retourne le résultat.

Resources (Ressources)

Données contextuelles exposées par le serveur sous forme d'URIs (fichiers, entrées de base de données, pages web). Contrairement aux outils, les ressources sont contrôlées par l'application : c'est le host qui décide quelles ressources inclure dans le contexte du modèle, pas le modèle lui-même.

Prompts (Templates)

Templates de messages pré-configurés avec des arguments dynamiques. Ils permettent aux serveurs de proposer des workflows réutilisables : « Explique ce code », « Résume ce document », « Génère les tests pour cette fonction ». Les prompts sont déclenchés par l'utilisateur, pas par le modèle.

Flux d'Invocation d'un Outil

Lorsqu'un LLM détermine qu'il a besoin d'un outil externe pour répondre à une requête, le protocole MCP orchestre un flux en six étapes :

Découverte — Au démarrage de la connexion, le client interroge le serveur via tools/list pour obtenir la liste des outils disponibles, avec leur nom, description et schéma JSON des paramètres attendus.
Injection dans le contexte — Le host injecte les descriptions d'outils dans le prompt système du LLM, lui permettant de « connaître » les capacités disponibles.
Décision du modèle — Le LLM analyse la requête utilisateur et décide s'il doit invoquer un outil. Si oui, il génère un appel structuré avec le nom de l'outil et les arguments au format JSON.
Exécution — Le client relaie la requête tools/call au serveur approprié via JSON-RPC. Le serveur exécute l'opération (lecture fichier, requête API, calcul).
Retour du résultat — Le serveur renvoie le résultat au format structuré (texte, JSON, image encodée). Le client transmet au host.
Intégration dans la réponse — Le host ré-injecte le résultat dans le contexte du LLM, qui l'utilise pour formuler sa réponse finale à l'utilisateur.

tools_call.jsonrpc JSON-RPC 2.0

// ── Requête (Client → Server) ──
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "read_file",
    "arguments": {
      "path": "/src/models/rag_pipeline.py"
    }
  }
}

// ── Réponse (Server → Client) ──
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "import chromadb\nfrom sentence_transformers import..."
      }
    ]
  }
}

MCP vs. Appels API Directs

La question naturelle est : pourquoi ne pas simplement appeler des APIs directement depuis le LLM, comme le font les systèmes de « function calling » classiques ? Le tableau ci-dessous illustre les différences architecturales fondamentales.

Critère	MCP	API Directe
Standardisation	Protocole ouvert et universel	Intégration propriétaire par fournisseur
Découverte d'outils	Automatique via `tools/list`	Manuelle, codée en dur dans le prompt
Sécurité	Sandboxing natif, processus isolés	Dépend de l'implémentation applicative
État de la connexion	Stateful — contexte persistant	Stateless — chaque appel est indépendant
Composabilité	Multiples serveurs simultanés	Intégration point-à-point
Portabilité	Fonctionne avec tout LLM compatible	Liée au format du fournisseur (OpenAI, Anthropic…)

Sécurité & Sandboxing

La sécurité est un pilier fondamental de l'architecture MCP. Contrairement aux approches « function calling » où le LLM a souvent un accès direct et non contrôlé aux APIs, MCP impose un modèle de sécurité multi-couches qui protège à la fois l'utilisateur, le système hôte et les données.

Isolation des processus

Chaque serveur MCP s'exécute dans son propre processus, avec ses propres permissions et son propre espace mémoire. Un serveur compromis ne peut pas affecter les autres serveurs ni le host. Cette isolation est renforcée par les mécanismes de sandboxing du système d'exploitation (conteneurs Docker, politiques macOS Sandbox, Linux namespaces).

Principe du moindre privilège

Chaque serveur ne reçoit que les permissions strictement nécessaires à son fonctionnement. Un serveur de lecture de fichiers n'aura pas accès au réseau.
Le host contrôle finement quels outils sont exposés au modèle et peut imposer un consentement utilisateur avant chaque invocation destructive (écriture, suppression, envoi d'email).
Les arguments des outils sont validés côté serveur contre un schéma JSON strict, empêchant les injections et les dépassements de périmètre.

Sécurité du transport

MCP supporte deux mécanismes de transport : stdio (communication par entrée/sortie standard entre processus locaux) et HTTP + SSE (Server-Sent Events pour les connexions réseau). Pour les transports réseau, le protocole recommande TLS obligatoire, l'authentification OAuth 2.0 et la validation de l'origine des requêtes. Le transport stdio, naturellement confiné au système local, offre une isolation de facto contre les attaques réseau.

Pour aller plus loin

Le Model Context Protocol représente une avancée majeure vers un écosystème d'IA interopérable et sécurisé. En standardisant la couche de communication entre LLMs et outils, MCP réduit drastiquement le coût d'intégration et ouvre la voie à des agents véritablement autonomes capables de naviguer dans un paysage d'outils hétérogènes sans configuration ad hoc.

L'adoption rapide du protocole par les principaux acteurs de l'industrie (Anthropic, Google, Microsoft, Cursor, Replit) confirme qu'MCP est en passe de devenir le standard de facto pour le « tool use » en IA. Pour approfondir les concepts de retrieval qui alimentent souvent les serveurs MCP, consultez notre article sur le Retrieval-Augmented Generation (RAG).