Qu’est-ce que MCP ? Model Context Protocol, JSON-RPC, agents IA et appels d’outils

D’emblée : MCP (Model Context Protocol) n’est pas un autre nom pour Function Calling, et ce n’est pas un modèle. C’est un protocole ouvert entre une application IA (le Host) et des processus d’outils externes (MCP Servers). Les messages sont du JSON-RPC 2.0. Le modèle parle toujours le Tool Calling / Function Calling de chaque fournisseur. Le Host traduit tools/list en tableau tools du modèle, puis traduit tool_calls en tools/call. Ces trois couches, ensemble, c’est ainsi que la plupart des agents 2026 invoquent des outils.

Cet article est daté du 7 septembre 2026. La spec actuelle est 2026-07-28 : pas de session de protocole, pas de handshake initialize, chaque requête porte _meta, et la découverte des capacités passe par server/discover. Notre article d’août Flux de données JSON des agents montre encore l’ancien exemple initialize ; pour la lecture à jour, c’est ce guide qui fait foi. Pour « dois-je modifier le code du Server ? », voir le guide de migration MCP 2026.

Ce qu’est MCP

Model Context Protocol est un standard ouvert pour la façon dont les applications IA découvrent, lisent et invoquent un contexte externe. Anthropic l’a publié en novembre 2024 ; la gouvernance a ensuite basculé vers l’Agentic AI Foundation. Il spécifie comment le contexte s’échange. Il ne spécifie pas quel modèle vous utilisez, comment vous orchestrez un agent multi-étapes, ni comment vous écrivez la logique métier.

Pensez USB-C : la prise est standard ; disque, écran ou alimentation branchés derrière, hors périmètre. MCP standardise la prise Host ↔ Server. Un système de fichiers, GitHub, une API de commandes interne, ou un validateur JSON comme ce site : ce sont tous des Servers.

Deux couches : la couche données est JSON-RPC 2.0 (méthodes, params, codes d’erreur, notifications) ; la couche transport est la façon dont ces trames JSON circulent — stdio sur la même machine, Streamable HTTP à distance. Changez le transport, la forme du message reste. C’est pourquoi le débogage MCP commence par séparer : « l’enveloppe est du JSON-RPC ; la charge métier est souvent du JSON aussi. »

Host, Client, Server

Le triangle de la spec se mélange facilement avec le « client / serveur » du quotidien :

• Host : l’application IA que l’utilisateur a ouverte. Il crée des Clients, nourrit le modèle avec les schemas d’outils, autorise et valide avant l’exécution, et réécrit les résultats dans le fil.
• Client : un objet de connexion dans le Host. Un Server, un Client. VS Code qui parle à un système de fichiers et à Sentry, ce sont deux Clients à l’exécution.
• Server : le programme qui sert le contexte. Il peut partager la machine du Host (stdio) ou tourner ailleurs (Streamable HTTP). « Server » est un rôle, pas l’obligation d’un nom d’hôte public.

Le modèle n’est pas dans ce triangle. GPT-5.5, Claude 4.8 et Gemini 3.7 voient le tableau tools traduit par le Host. Ils ne voient pas le JSON-RPC, et ils ne voient pas Mcp-Session-Id (l’en-tête de session a disparu en 2026-07-28). « Le modèle parle MCP » est du marketing. En ingénierie, il y a toujours un Host au milieu.

Comment lire JSON-RPC 2.0

JSON-RPC est une convention d’appels de procédures distantes en JSON — plus proche de « appeler une fonction » que de REST. MCP l’a choisi parce que les noms de méthodes restent stables (tools/list, tools/call), le découpage requête / réponse / notification est net, et toute l’enveloppe est du JSON lisible par un modèle.

Un tools/call sous la spec 2026-07-28 ressemble à ceci. À noter : pas de handshake, pas d’en-tête de session. Version et identité client vivent dans _meta, donc n’importe quelle instance Server peut traiter la trame.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "validate_json",
    "arguments": {
      "payload": {"orderId": "A-1001", "total": 42.5},
      "schemaId": "order.v1"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "json-toolbox-host",
        "version": "1.0.0"
      }
    }
  }
}

Une réponse de succès est la même enveloppe. Le résultat métier est dans result.content, souvent type: "text", et ce texte peut lui-même être une chaîne JSON — protocole dehors, charge utile dedans. Au débogage, faites d’abord correspondre id à la requête, puis validez le schema de l’objet interne.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "{\"valid\":true,\"schemaId\":\"order.v1\"}"
      }
    ]
  }
}

Les échecs utilisent l’objet error JSON-RPC : code, message, data optionnel. 2026-07-28 a changé « ressource introuvable » du code MCP spécifique -32002 vers le standard -32602 (Invalid Params). Les clients qui testent l’ancien code en dur passeront à côté. Les notifications n’ont pas d’id et n’attendent pas de réponse — par exemple un changement de liste d’outils.

Tools, Resources, Prompts

Un Server peut exposer trois primitives. Les agents vivent sur Tools ; les deux autres sont faciles à laisser de côté et évitent souvent un tour de devinette du modèle.

Un outil, c’est name, description et inputSchema. inputSchema est du JSON Schema (2020-12 depuis 2026-07-28 ; la racine doit toujours être type: "object" ; oneOf / $ref / $defs sont autorisés). outputSchema optionnel contraint la forme de retour. Les Hosts recopient presque 1:1 inputSchema dans parameters / input_schema de l’API modèle.

{
  "name": "validate_json",
  "title": "Validate JSON",
  "description": "Check a JSON payload against a named schema. Returns valid and errors.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "payload": { "type": "object", "description": "Already parsed JSON object, not a raw string" },
      "schemaId": { "type": "string", "description": "Stable schema id such as order.v1" }
    },
    "required": ["payload", "schemaId"]
  }
}

Resources collent à « lire, puis réfléchir » : charger schema://order.v1 coûte moins cher que de faire mémoriser au modèle un schema de 200 lignes dans le fil. Prompts collent aux amorces figées d’une équipe. Roots, Sampling et Logging sont dépréciés en 2026-07-28 : passez les chemins de workspace en arguments d’outil ou en URI de ressource ; les Servers ne doivent plus demander une complétion au Host ; les logs vont vers stderr ou OpenTelemetry.

Comment ça s’empile avec Tool Calling

Trois noms se retrouvent aplatis en un seul. Ce n’est pas la même couche — l’article sur le flux de données JSON des agents suit chaque saut. Ici, seulement le mapping :

Function Calling est le nom d’origine d’OpenAI ; Tool Calling est le terme générique plus tardif (Claude tools, Gemini Function Calling, OpenAI Tools API). Pour les développeurs, c’est un seul flux : le Host envoie un schema, le modèle renvoie un appel avec des arguments JSON, le Host l’exécute, puis réinjecte un résultat JSON dans le fil.

MCP ne remplace pas cette couche. Un Host qui n’appelle que des fonctions in-process via Tool Calling reste valide. MCP rend les outils découvrables, inter-processus, et réutilisables d’un Host à l’autre. Les agents d’entreprise empilent presque toujours les deux ; les scripts et démos sautent souvent MCP.

Deux pièges de mapping : les API modèles donnent souvent arguments en chaîne ; MCP params.arguments est un objet. Et le name de tools/list doit arriver au modèle et à tools/call inchangé — n’inventez pas d’alias « plus amical » au milieu. Validez avant le vrai tools/call ; voir Tool Calling et validation JSON Schema.

Un appel d’outil complet

L’utilisateur dit : « Valide ce JSON de commande avec order.v1. » Sur 2026-07-28, le chemin est :

1. Host → Server : server/discover (peut être mis en cache) pour confirmer les tools ; ou envoyer la requête suivante et réessayer sur une erreur de version.
2. Host → Server : tools/list renvoie des items avec inputSchema ; le résultat peut porter ttlMs / cacheScope.
3. Host → modèle : mapper la liste vers tools[].parameters (toujours du JSON Schema).
4. Modèle → Host : tool_calls avec name validate_json ; arguments est souvent du JSON stringifié.
5. Le Host valide : JSON.parse, puis contrôle inputSchema. En cas d’échec, écrire l’erreur comme résultat d’outil — ne pas toucher le vrai Server.
6. Host → Server : tools/call avec arguments objet et la version de protocole dans _meta.
7. Server → Host : result.content ; le Host peut revérifier outputSchema.
8. Host → modèle : une chaîne JSON role: tool ; le modèle répond à l’utilisateur ou lance un autre tour d’outil.

Langage naturel utilisateur
    │
    ▼
Host ──JSON Schema──► LLM Tool Calling
    │                      │
    │                      ▼
    │                 arguments JSON
    ▼                      │
MCP JSON-RPC ◄──── tools/call seulement après validation
    │
    ▼
result JSON ──► tool message ──► réponse finale du modèle

En transport distant, les en-têtes HTTP doivent inclure MCP-Protocol-Version, Mcp-Method et Mcp-Name, et ils doivent coller au body, sinon le Server doit refuser. Les équilibreurs de charge peuvent router sur les en-têtes sans parser le JSON. Le stdio local n’a pas ces en-têtes ; les noms de méthodes JSON-RPC sont les mêmes.

Ce qu’il faut retenir de 2026-07-28

La spec de juillet est la plus grande révision depuis le lancement, et le 28 juillet 2026 est la date de publication finale. Pour « qu’est-ce que MCP », retenez la liste ci-dessous. Savoir si votre Server doit changer de code reste l’arbre de décision de l’article de migration.

• Pas de handshake, pas de session de protocole : initialize / initialized et Mcp-Session-Id ont disparu. Chaque requête est auto-contenue. Chaînez l’état applicatif avec un basket_id explicite (ou équivalent) comme argument normal. N’attendez pas du transport qu’il se souvienne de vous.
• La découverte, c’est server/discover : optionnel, mais un appel renvoie les versions supportées, les capabilities et serverInfo. Les résultats de liste portent ttlMs ; un long flux SSE n’est plus le seul moyen de savoir que les outils ont changé.
• Les schemas sont du JSON Schema 2020-12 : la racine d’entrée reste un object ; composition et refs sont autorisés ; ne déréférencez pas automatiquement un $ref externe. Les schemas de sortie ne sont plus limités au type object.
• Roots / Sampling / Logging sont dépréciés : les méthodes restent valides pendant la fenêtre d’un an. Les nouveaux Servers ne doivent plus implémenter Sampling pour demander une complétion au Host.
• Extensions : Tasks et MCP Apps sont des extensions officielles, pas des prérequis du cœur. Le travail long utilise un task handle + tasks/get. N’inventez pas votre propre session.

Les Hosts et Servers encore sur 2025-11-25 continuent d’utiliser initialize. En cas de versions mélangées, suivez le protocolVersion négocié. N’envoyez pas les trames sans session de cet article à un ancien Server. Pour quoi installer, voir les classements MCP Server 2026.

Que faire maintenant

1. Dessinez trois couches avant d’écrire du code : le Tool Calling de l’API modèle, l’orchestration Host, le MCP Server. Un script peut s’arrêter aux deux premières. La réutilisation inter-IDE, c’est le moment d’écrire un Server.
2. Utilisez un SDK officiel ; n’écrivez pas les trames JSON-RPC à la main : @modelcontextprotocol/sdk et les autres packs officiels par langage gèrent déjà la découverte, le transport et les codes d’erreur. SSE écrit à la main ou champs privés : c’est le cas typique « il faut changer le code » du guide de migration.
3. Écrivez inputSchema comme un contrat que vous pouvez valider tout seul : additionalProperties: false, required, enums, plafonds de longueur. Les modèles omettent des champs et passent les nombres en chaînes. Filtrez une fois avec le même schema avant l’exécution.
4. stdio en local, Streamable HTTP à distance : le débogage personnel n’a pas besoin de HTTP. Accès d’équipe partagé, plusieurs clients, ou une passerelle : c’est là qu’on passe à distance — plus OAuth et le moindre privilège.
5. Mettez les listes en cache, taillez les résultats : respectez ttlMs. Ne renvoyez pas les stacks brutes au modèle. Une fenêtre plus large n’assainit pas un JSON sale — voir fenêtres de contexte 1M tokens.
6. Vérifiez les fixtures dans le navigateur avant de toucher un Server réel : enregistrez inputSchema, des arguments bons / mauvais, et des retours Server d’exemple en JSON ; validez et Diff sur ce site. Rien n’est envoyé. Même habitude que pour tester un contrat REST.

FAQ

À retenir

MCP est la prise d’outils des agents 2026 : JSON-RPC 2.0 transporte découverte et invocation entre Host et Server ; côté modèle, c’est toujours Tool Calling ; JSON Schema est le contrat partagé. Ce n’est pas un modèle, pas un framework, et pas un remplaçant d’OpenAPI. La spec 2026-07-28 a retiré les sessions du protocole, donc les requêtes doivent être auto-contenues. Les trois primitives — Tools, Resources, Prompts — n’ont pas changé.

Ce guide n’établit que le découpage en couches. La forme des octets à chaque saut est dans l’article sur le flux de données ; savoir si un ancien Server doit changer de code est dans l’article de migration ; quels Servers installer est dans l’article de classement. Avant de brancher quoi que ce soit en réel, validez le schema et les JSON d’exemple en local — vous pouvez changer de modèle ; les noms de champs et required ne doivent pas bouger.