← L'édition
IANouveau2 min de lecture

Protocole MCP : suppression du handshake pour passer au full stateless

La révision 2026-07-28 du protocole MCP marque la fin des sessions persistantes et de la négociation initiale lors de la connexion. Désormais, chaque requête transporte ses propres métadonnées, ce qui simplifie la mise à l'échelle des serveurs d'outils IA en équipe.

Fil « Suppression du handshake de session dans le protocole MCP »

Une rupture de protocole axée sur le stateless

Le protocole MCP (Model Context Protocol, un standard ouvert permettant d'interconnecter des modèles de langage à des outils ou bases de données) fait évoluer sa structure globale. Dans sa révision 2026-07-28, la phase initiale de négociation (handshake, échange initial pour établir la connexion) et les sessions persistantes identifiées par l'en-tête Mcp-Session-Id disparaissent. Jusqu'à la version 2025-11-25, un client devait exécuter la requête initialize pour négocier la version et échanger les capacités une seule fois au démarrage.

Fonctionnement des requêtes autonomes

Désormais, le protocole bascule vers un fonctionnement totalement stateless (sans conservation d'état entre deux requêtes). Chaque requête transportée contient sa propre enveloppe de métadonnées incluant la révision du protocole, l'identité du client et ses capacités déclarées. Côté HTTP, chaque requête POST transporte des en-têtes comme MCP-Protocol-Version et Mcp-Method. Cette approche permet à n'importe quel processus serveur de répondre à n'importe quelle requête sans avoir à partager un état de session global.

Simplification de l'architecture serveur

Pour les équipes de développement qui conçoivent des serveurs MCP, cette mise à jour supprime la complexité liée à la gestion de sessions ou au flux d'évènements SSE (Server-Sent Events, technique de streaming de données du serveur vers le client) et leur reprise via Last-Event-ID. Les fonctionnalités de publication et d'écoute migrent vers subscriptions/listen, tandis que des endpoints comme initialize, notifications/initialized, ping ou logging/setLevel renvoient désormais des erreurs 404 et -32601.

Un exemple concret d'initialisation côté client

Du côté du code client (ici illustré avec le SDK PHP), le basculement sélectionne le cycle de vie moderne lors de la configuration de la connexion sans altérer le reste des appels :

$client = Client::builder()
    ->setClientInfo('my-client', '1.0.0')
    ->setProtocolVersion(ProtocolVersion::V2026_07_28)
    ->setCapabilities(new ClientCapabilities(elicitation: true))
    ->addRequestHandler($myElicitationHandler)
    ->build();
$client->connect(new HttpTransport('https://example.com/mcp'));
$client->callTool('greet', []);

Évolutions et dépréciations à anticiper

Cette révision introduit également des dépréciations majeures régies par la spécification SEP-2577, avec une suppression définitive prévue au plus tôt le 2027-07-28 :

  • Roots : passer les répertoires via les arguments d'outils ou des URI (identifiants uniques de ressources) de ressources plutôt que via les racines.
  • Sampling : s'intégrer directement avec un fournisseur de LLM (Large Language Model, grand modèle de langage) au lieu de déléguer l'échantillonnage.
  • Logging : écrire les journaux d'évènements dans stderr ou OpenTelemetry (standard ouvert de collecte de métriques et traces) plutôt que d'utiliser les notifications du protocole.
  • Codes d'erreur : le code d'erreur -32002 (ressource non trouvée) est retiré au profit du code standard -32602.