Architecture MCP

MCP définit surtout un protocole standard d’échange de contexte entre une application IA et des serveurs qui exposent des données, des outils ou des templates de prompts.

Le projet inclut plusieurs éléments :

• La spécification MCP : les règles du protocole.
• Les SDKs : bibliothèques pour implémenter clients et serveurs.
• Des outils de développement : par exemple l’inspector.
• Des serveurs de référence : implémentations exemples.

La data layer repose sur JSON-RPC 2.0. Clients et serveurs s’échangent des requêtes, des réponses et des notifications.

• Lifecycle management : initialisation, négociation des capacités, terminaison.
• Fonctionnalités serveur : tools, resources, prompts.
• Fonctionnalités client : sampling, elicitation, logging.
• Utilitaires : notifications, suivi de progression, opérations longues.

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

Elle gère la communication entre participants MCP : ouverture de connexion, encadrement des messages, sécurité, authentification.

MCP est un protocole stateful. Cela veut dire qu’on ne fait pas juste un appel isolé : il existe une relation de session où client et serveur doivent d’abord se mettre d’accord sur ce qu’ils supportent.

Pourquoi cette phase existe

1. Négocier la version du protocole.
2. Déclarer les capacités disponibles de chaque côté.
3. Échanger des informations d’identité pour le debug et la compatibilité.

Séquence mentale

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "elicitation": {}
    },
    "clientInfo": {
      "name": "example-client",
      "version": "1.0.0"
    }
  }
}

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

Les primitives définissent ce que client et serveur peuvent offrir l’un à l’autre. C’est le cœur fonctionnel de MCP.

Pattern général

tools/list       → découvrir les tools
tools/call       → exécuter un tool

resources/list   → découvrir les resources
resources/read   → lire une resource

prompts/list     → découvrir les prompts
prompts/get      → récupérer un prompt

Étape 1 — Initialisation

Le client ouvre la session et négocie les capacités.

Client  → initialize
Server  → répond avec protocolVersion + serverInfo + capabilities
Client  → notifications/initialized

Étape 2 — Découverte des tools

Une fois prêt, le client demande la liste des tools.

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

La réponse contient un tableau de tools avec leurs métadonnées.

Étape 3 — Exécution d’un tool

Le client utilise tools/call avec le nom exact du tool et ses arguments.

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "San Francisco",
      "units": "imperial"
    }
  }
}

Éléments clés de l’exécution

1. name doit correspondre exactement au nom retourné par tools/list.
2. arguments doit respecter inputSchema.
3. Le tout reste enveloppé dans un message JSON-RPC 2.0 classique avec un id.

Réponse d’exécution

MCP renvoie un tableau content, ce qui permet des réponses riches et multi-formats.

• texte,
• images,
• références à des ressources,
• autres formats structurés.

MCP supporte des notifications JSON-RPC, donc des messages envoyés sans attendre de réponse.

Exemple : changement dans la liste des tools

{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed"
}

Ce qu’il faut comprendre

1. Pas de champ id → donc ce n’est pas une requête classique, aucune réponse n’est attendue.
2. Basé sur les capacités annoncées → par exemple si le serveur avait déclaré "tools": {"listChanged": true}.
3. Orienté événements → le serveur prévient le client quand son état change.

Réaction typique du client

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

Donc le cycle est :

1. Le host configure un ou plusieurs serveurs MCP.
2. Pour chaque serveur, il crée un client MCP.
3. Le client initialise la session et récupère les capacités.
4. Le host agrège tools/resources/prompts disponibles.
5. Le LLM peut alors choisir ou suggérer l’usage d’un tool.
6. Le host route l’exécution vers le bon serveur MCP.
7. Le résultat revient et alimente la conversation.

# Vision simplifiée
for each server:
    connect()
    initialize()
    list_tools()

when llm requests a tool:
    find matching MCP server
    call tools/call
    inject result into conversation

• MCP ≠ LLM : c’est un protocole de contexte, pas un modèle.
• Le host n’est pas le client MCP : le host pilote, le client maintient la connexion.
• Un serveur MCP peut être local ou distant.
• JSON-RPC 2.0 est la base logique commune, quel que soit le transport.
• La découverte vient avant l’exécution : on fait souvent tools/list avant tools/call.
• Les notifications n’attendent pas de réponse.

Qu’est-ce que MCP en une phrase ?

Un protocole standard pour permettre à une application IA d’obtenir du contexte et d’exécuter des capacités exposées par des serveurs.

Quels sont les 3 acteurs principaux ?

Le host, le client MCP, et le serveur MCP.

Quelle est la différence entre host et client MCP ?

Le host orchestre l’application IA ; le client MCP est le composant qui gère la connexion avec un serveur précis.

Quelles sont les deux couches de MCP ?

La data layer et la transport layer.

Sur quoi repose la data layer ?

Sur JSON-RPC 2.0.

Quels sont les 3 types principaux de primitives côté serveur ?

Tools, resources, prompts.

Quelles sont les primitives importantes côté client ?

Sampling, elicitation, logging.

Pourquoi initialise-t-on la session ?

Pour négocier version, capacités et identité avant les échanges utiles.

Quel est l’ordre typique d’un échange ?

initialize → notifications/initialized → tools/list → tools/call → notifications si changement.

À quoi servent les notifications ?

À informer le client en temps réel d’un changement sans qu’il ait besoin de demander en boucle.

MCP est un protocole standard qui permet à une application IA de parler à des serveurs fournissant des outils, des ressources et des prompts. L’application joue le rôle de host et crée un client MCP par serveur. Les échanges logiques utilisent JSON-RPC 2.0, tandis que le transport peut être en STDIO ou en HTTP. Le protocole commence par une initialisation, puis le client découvre les capacités disponibles via des requêtes comme tools/list, exécute via tools/call, et peut être tenu à jour grâce aux notifications.