Types de messages JSON

Le MCP (Model Context Protocol) utilise des messages JSON pour gérer la communication entre clients et serveurs. Comprendre ces types de messages est crucial pour travailler avec MCP, en particulier quand vous utilisez différentes méthodes de transport comme le transport StreamableHTTP. À la fin de cette leçon, vous saurez distinguer requêtes, résultats et notifications, lire la spécification, et expliquer pourquoi la bidirectionnalité pèse sur le choix du transport.

Format des messages

Toute la communication MCP se fait via des messages JSON. Chaque type de message sert un objectif spécifique — qu’il s’agisse d’appeler un outil, de lister des ressources disponibles, ou d’envoyer des notifications sur des événements système.

Exemple typique : quand Claude doit appeler un outil fourni par un serveur MCP, le client envoie un message “Call Tool Request”. Le serveur traite cette requête, exécute l’outil, et répond avec un message “Call Tool Result” contenant le résultat.

La spécification MCP

La liste complète des types de messages est définie dans le dépôt officiel de spécification MCP sur GitHub. Cette spécification est séparée des différents dépôts SDK (Python, TypeScript, etc.) et constitue la source de référence pour le fonctionnement de MCP.

Les types de messages sont écrits en TypeScript pour leur clarté — pas parce qu’ils sont exécutés comme code TypeScript, mais parce que TypeScript fournit un moyen clair de décrire les structures de données et les types.

Catégories de messages

Les messages MCP se divisent en deux catégories principales :

Messages Requête-Résultat

Ces messages viennent toujours par paires. Vous envoyez une requête et attendez un résultat en retour :

Messages de Notification

Ces messages sont unidirectionnels — ils informent sur des événements mais ne nécessitent pas de réponse :

Messages Client vs Serveur

La spécification MCP organise les messages selon qui les envoie :

Messages clients → requêtes que les clients envoient aux serveurs (appels d’outils) et notifications que les clients peuvent envoyer.

Messages serveurs → requêtes que les serveurs envoient aux clients (ex: sampling via CreateMessageRequest) et notifications que les serveurs diffusent.

Pourquoi c’est important

Comprendre que les serveurs peuvent envoyer des messages aux clients est particulièrement important quand vous travaillez avec différentes méthodes de transport. Certains transports, comme le transport StreamableHTTP, ont des limitations sur les types de messages pouvant circuler dans chaque direction.

L’insight clé : MCP est conçu comme un protocole bidirectionnel (avant 2026-07-28) : clients et serveurs peuvent tous deux initier la communication. C’est crucial quand vous choisissez la méthode de transport appropriée pour votre cas d’usage spécifique.

Sur le fil, tout cela est du JSON-RPC 2.0 : une requête porte method, params et un id ; le résultat reprend cet id ; une notification a un method mais pas d’id, personne n’y répond. Les noms TypeScript de la spécification (CallToolRequest) correspondent à des méthodes sur le fil (tools/call). La version 2026-07-28 réorganise ce vocabulaire : plus de InitializeRequest (chaque requête porte version et capacités dans _meta), un nouvel appel server/discover, un champ obligatoire resultType (complete ou input_required) sur chaque résultat, et les requêtes du serveur vers le client (CreateMessageRequest, ListRootsRequest, élicitation) remplacées par le pattern des requêtes en plusieurs allers-retours : le serveur renvoie un résultat input_required, le client relance avec l’information manquante. Les notifications restent, mais notifications/roots/list_changed et logging/setLevel disparaissent.

Dans les prochaines leçons, nous examinerons comment les deux transports principaux, STDIO et StreamableHTTP, gèrent cette communication bidirectionnelle.

À vous de jouer

1. Ouvrez le schéma de la spécification (schema.ts) dans le dépôt officiel et retrouvez CallToolRequest, CallToolResult et ProgressNotification : notez pour chacun le method sur le fil.
2. Classez ces messages : qui les envoie, et attendent-ils une réponse ? ListResourcesRequest, LoggingMessageNotification, CreateMessageRequest, InitializedNotification.
3. Trouvez dans le changelog 2026-07-28 ce qui remplace CreateMessageRequest.

Sources officielles : JSON message types (Claude Academy) · Dépôt de la spécification MCP · Changelog 2026-07-28 · Requêtes en plusieurs allers-retours (MRTR)

Points clés à retenir

• Deux catégories : paires requête/résultat (même id) et notifications unidirectionnelles (sans id), en JSON-RPC 2.0.
• La spécification, écrite en TypeScript dans son propre dépôt, est la référence ; les SDK l’implémentent.
• Avant 2026-07-28, client et serveur peuvent tous deux initier une requête : c’est ce qui contraint le choix du transport.
• Depuis 2026-07-28 : _meta à la place de initialize, server/discover, resultType, et MRTR à la place des requêtes du serveur vers le client.