MCP 2026-07-28 Guide de migration : serveurs sans état

TL;DR : MCP 2026-07-28 supprime les sessions au niveau du protocole et la poignée de main d’initialisation obligatoire. Les équipes de production devraient trouver les dépendances cachées aux sessions, adopter des métadonnées de protocole par requête, implémenter les Multi Round-Trip Requests, mettre à jour les politiques de passerelle et déployer en canari le nouveau protocole avant de retirer le comportement hérité.

La spécification Model Context Protocol publiée le 28 juillet 2026 introduit le plus grand changement architectural de MCP depuis l’ajout de la prise en charge du transport distant.

Le protocole utilise désormais un noyau sans état basé sur des requêtes et des réponses. L’échange obligatoire initialize et notifications/initialized disparaît, Mcp-Session-Id est supprimé, et chaque requête transporte les informations de protocole nécessaires à son traitement.

La version introduit également les Multi Round-Trip Requests, des en-têtes de routage HTTP, des réponses de liste mises en cache, un comportement d’autorisation plus strict, un cadre d’extensions, ainsi qu’un cycle de dépréciation formel. Voir l’annonce officielle de la version MCP 2026-07-28 et le journal complet des modifications de la spécification pour les détails au niveau du protocole.

Ces changements facilitent la mise à l’échelle des serveurs MCP distants derrière une infrastructure HTTP standard. Ils ne rendent pas automatiquement une application existante sans état.

Un serveur de production peut encore dépendre de workspaces en mémoire, d’affinité de session, d’identifiants liés à la session, de flux longue durée ou d’interactions initiées par le serveur. Ce guide se concentre sur l’identification et le remplacement de ces dépendances.

Pour une introduction plus didactique de l’implémentation, lisez How to Create an MCP Server for Claude Code avant de démarrer la migration.

Qui doit migrer ?

Le niveau d’effort dépend de la manière dont MCP est utilisé dans votre système.

Un serveur local qui ne préserve pas d’état entre les requêtes peut ne nécessiter qu’une mise à niveau du SDK et des tests de compatibilité.

Un déploiement distant utilisant des sessions, OAuth, du streaming ou des requêtes initiées par le serveur nécessite une migration par étapes.

Qu’est-ce qui a changé dans MCP 2026-07-28 ?

1. Auditer l’implémentation existante

Avant la mise à niveau, recherchez dans le client, le serveur, la passerelle et la configuration de déploiement les hypothèses liées à l’ancien protocole.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

Ensuite, répondez aux questions suivantes :

1. Le serveur rejette-t-il les appels jusqu’à ce que l’initialisation soit terminée ?
2. Un ID de session sélectionne-t-il un utilisateur, des identifiants, un workspace ou une conversation ?
3. Une autre instance de serveur peut-elle continuer un workflow démarré par la première ?
4. L’équilibreur de charge exige-t-il une affinité de session ?
5. Un outil effectue-t-il un effet de bord avant de demander une confirmation ?
6. La passerelle parse-t-elle le corps pour identifier la méthode ou l’outil ?
7. Les identifiants OAuth sont-ils stockés sans leur serveur d’autorisation émetteur ?
8. Le client dépend-il de la reconnexion SSE ou de la rediffusion de messages ?
9. Les listes d’outils ou de ressources varient-elles selon la connexion ?
10. Quelles fonctionnalités dépréciées reçoivent encore du trafic en production ?

Ne retirez pas Mcp-Session-Id avant de comprendre ce que l’application stocke derrière lui.

Un serveur qui supprime l’en-tête mais conserve l’état en mémoire locale peut fonctionner en développement et échouer de manière intermittente une fois les requêtes réparties sur plusieurs instances.

2. Remplacer l’état de session caché

MCP 2026-07-28 supprime les sessions au niveau du protocole, pas l’état applicatif.

L’état nécessaire entre les appels doit suivre l’un des trois schémas.

Handles explicites

Retournez un handle émis par le serveur depuis un outil, puis rendez-le requis dans les appels ultérieurs.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

Une requête ultérieure transmet le handle comme un argument ordinaire :

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

Cela rend la dépendance visible dans le contrat de l’outil et permet à toute instance de serveur compatible de traiter la requête.

Stockage partagé

Utilisez une base de données, un cache distribué, un object store ou un système de tâches durables lorsque :

• plusieurs travailleurs ont besoin du même état ;
• le workflow doit survivre à un redémarrage ;
• l’état est trop volumineux pour un handle ;
• le workflow dure plus longtemps qu’une seule requête ;
• un comportement transactionnel ou à usage unique est requis.

requestState protégé

MRTR peut renvoyer une valeur requestState opaque que le client renvoie lorsqu’il retente la requête d’origine.

Comme la valeur transite par le client, protégez-la avec un HMAC ou un chiffrement authentifié. Lieez-la au principal authentifié, à l’opération d’origine, aux paramètres importants, à une date d’expiration et à un nonce si une protection contre la relecture est nécessaire.

Ne faites jamais confiance à une valeur requestState non signée simplement parce que le client l’a renvoyée inchangée.

3. Adopter des requêtes autonomes et la découverte

Les requêtes MCP modernes incluent le contexte de protocole dans _meta.

Un appel d’outil Streamable HTTP peut ressembler à ceci :

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

Les serveurs ciblant le nouveau protocole doivent implémenter server/discover, qui annonce les versions prises en charge, les capacités et l’identité du serveur. Les clients peuvent l’appeler avant une autre opération ou l’utiliser pour déterminer si un repli hérité est nécessaire.

Lisez la server/discover documentation officielle pour le contrat de réponse.

Négociation de version du SDK TypeScript

Mettre à jour le SDK TypeScript seul ne bascule pas automatiquement un client vers le nouveau protocole.

Un client utilisant le SDK v2 doit explicitement l’activer :

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

En mode automatique, le SDK effectue une sonde avec server/discover et peut revenir à l’ancien flux d’initialisation lorsqu’il contacte un serveur hérité.

Les équipes utilisant encore @modelcontextprotocol/sdk v1 doivent d’abord suivre le guide de migration du SDK TypeScript v1 vers v2. Les équipes déjà sur v2 doivent utiliser le guide de prise en charge du protocole 2026-07-28 distinct.

4. Remplacer les requêtes initiées par le serveur par MRTR

Les implémentations MCP précédentes pouvaient envoyer des requêtes telles que elicitation/create, sampling/createMessage ou roots/list du serveur vers le client.

Le nouveau protocole remplace ce modèle par les Multi Round-Trip Requests.

Le flux est :

1. Le client envoie la requête d’origine.
2. Le serveur renvoie resultType: "input_required".
3. Le client recueille les informations ou l’approbation demandées.
4. Le client retente l’opération d’origine avec un nouvel ID JSON-RPC.
5. La nouvelle tentative inclut inputResponses et le requestState d’origine.
6. Le serveur termine la requête ou démarre un autre tour.

Exemple de réponse :

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Le client retente l’opération d’origine :

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Une implémentation MRTR en production doit définir :

• un nombre maximal de tours ;
• l’expiration du request-state ;
• le comportement d’annulation et de rejet ;
• la validation des schémas de réponse ;
• des vérifications d’autorisation à chaque tentative ;
• une protection contre la relecture ;
• l’idempotence des effets de bord ;
• le comportement lorsqu’un client ne prend pas en charge la capacité demandée.

Évitez de finaliser un achat, une suppression, une déduction de crédit ou une écriture externe avant de renvoyer input_required.

Utilisez une opération par étapes ou une clé d’idempotence afin que les retentatives ne dupliquent pas l’action. Voir la spécification MRTR pour le modèle d’interaction complet.

5. Mettre à jour les passerelles, la mise en cache et l’autorisation

Les changements d’infrastructure sont étroitement liés et doivent être testés ensemble.

Valider les en-têtes de routage MCP

Les requêtes POST Streamable HTTP incluent désormais :

• MCP-Protocol-Version
• Mcp-Method
• Mcp-Name

Ces en-têtes permettent aux passerelles de router, mesurer, autoriser et limiter le trafic sans parser chaque corps JSON.

Elles peuvent prendre en charge des contrôles tels que :

• des limites de débit spécifiques à l’outil ;
• des politiques distinctes pour les méthodes de liste et d’exécution ;
• des pools de travailleurs dédiés pour les outils coûteux ;
• un accès restreint aux opérations à haut risque ;
• des métriques de latence et d’erreur par outil ;
• l’attribution des coûts d’infrastructure.

Les valeurs restent fournies par le client. Comparez-les au corps JSON-RPC avant d’appliquer une politique.

Une requête ne doit pas pouvoir revendiquer un outil à faible risque dans Mcp-Name tout en invoquant un autre outil dans le corps. Les divergences entre en-tête et corps doivent être rejetées et journalisées.

Utiliser des clés de cache sensibles à l’autorisation

Le nouveau protocole ajoute ttlMs et cacheScope aux résultats pouvant être mis en cache, notamment :

• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

Une clé de cache doit normalement inclure :

protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version

Ne réutilisez pas une entrée de cache privée entre utilisateurs ou tenants simplement parce que le TTL n’a pas expiré.

L’ordre déterministe des outils compte également. Un catalogue stable évite des ratés de cache inutiles et peut améliorer la réutilisation du cache d’invite du modèle lorsque les définitions d’outils sont insérées dans les prompts.

Renforcer la gestion de l’émetteur OAuth

Pendant la migration d’autorisation :

• validez une valeur iss renvoyée par rapport à l’émetteur enregistré pour le flux ;
• indexez les identifiants client stockés par émetteur ;
• ne réutilisez jamais des identifiants avec un autre serveur d’autorisation ;
• définissez un application_type approprié lors de DCR ;
• préparez les nouvelles intégrations pour Client ID Metadata Documents.

Dynamic Client Registration reste disponible pour la compatibilité descendante, mais il est déprécié comme approche privilégiée d’enregistrement.

6. Migrer les notifications, les Tasks et les fonctionnalités dépréciées

L’ancien chemin de notifications HTTP GET et les flux resources/subscribe ou resources/unsubscribe ont été remplacés par subscriptions/listen.

Les clients ouvrent un flux de réponse POST longue durée et optent pour les catégories de notification dont ils ont besoin. Les notifications de progression et de journal spécifiques à une requête restent attachées au flux de réponse de la requête qu’elles décrivent.

Pour les déploiements multi-instances, utilisez un bus d’événements partagé lorsque les notifications générées sur une instance doivent atteindre un abonnement connecté à une autre.

Extension Tasks

Le travail de longue durée a été déplacé hors du protocole cœur expérimental vers :

io.modelcontextprotocol/tasks

L’extension utilise :

• tasks/get pour le polling ;
• tasks/update pour les mises à jour client-vers-serveur ;
• des handles de tâches durables ;
• subscriptions/listen pour des mises à jour souscrites.

Les anciens schémas tasks/result et tasks/list ne doivent pas être reconduits dans une nouvelle implémentation.

Fonctionnalités dépréciées

Les fonctionnalités suivantes sont dépréciées :

Les fonctionnalités dépréciées restent disponibles pendant la fenêtre de dépréciation, mais les nouvelles implémentations ne doivent pas les adopter. La politique de cycle de vie MCP prévoit une période de dépréciation minimale de douze mois ; cela ne signifie pas que chaque fonctionnalité a la même date de suppression confirmée.

Consultez le registre des fonctionnalités obsolètes avant de fixer une date de retrait.

7. Déployer la migration en toute sécurité

Ne modifiez pas les clients, serveurs, passerelles, la mise en cache et l’autorisation dans une seule version sans observation.

Ordre de migration recommandé

1. Inventorier les versions de protocole, SDK, sessions, trafic SSE, clients DCR et méthodes dépréciées.
2. Mettre à niveau les SDK hors production.
3. Ajouter server/discover et la négociation de version.
4. Remplacer les dépendances cachées aux sessions.
5. Implémenter et sécuriser MRTR.
6. Ajouter des en-têtes de routage validés et des caches à portée définie.
7. Tester les frontières d’émetteur d’autorisation.
8. Déployer en canari le protocole moderne en parallèle du chemin hérité.
9. Retirer l’ancien comportement uniquement après examen de la télémétrie.

Compatibilité pendant le canari

Modern client + modern server
→ Use MCP 2026-07-28

Modern client + legacy server
→ Probe and fall back when supported

Legacy client + dual-version server
→ Continue on the legacy path

Unsupported combination
→ Return a clear protocol-version error

La publication d’une nouvelle spécification MCP n’est pas un basculement à l’échelle de l’écosystème. Les clients, serveurs, SDK et plates-formes hébergées migreront à des rythmes différents.

Télémétrie à enregistrer

Des requêtes tools/call one-shot réussies ne suffisent pas à mesurer la migration. Un workflow qui expire à répétition, demande des entrées inutiles ou duplique une écriture externe reste un échec en production.

Intégration de CometAPI dans une architecture MCP

MCP ne remplace pas une API de modèle. Les deux couches résolvent des problèmes d’intégration différents.

Une architecture de production typique ressemble à ceci :

Application or agent
        ↓
MCP clients and servers
Tools, resources, approvals, tasks
        ↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models

MCP standardise la façon dont les agents interagissent avec les outils et le contexte. Il ne standardise pas la tarification des modèles, les identifiants de fournisseurs, les endpoints d’inférence ou la bascule entre fournisseurs.

Cette séparation devient particulièrement utile lors de la migration hors de la fonctionnalité Sampling dépréciée. Si un serveur MCP ou l’agent qui le consomme a encore besoin d’inférence de modèle, l’application peut appeler directement une API de modèle au lieu de dépendre de l’ancien flux Sampling de MCP.

Quand une passerelle de modèles unifiée est utile

Une passerelle de modèles unifiée peut réduire le travail opérationnel lorsque :

• plusieurs serveurs MCP ont besoin d’accéder à différents fournisseurs de modèles ;
• différents outils nécessitent différents modèles ;
• les équipes veulent changer de modèles sans réécrire des intégrations spécifiques aux fournisseurs ;
• les identifiants, l’usage et la facturation doivent être gérés de manière centralisée ;
• l’accès aux modèles doit rester indépendant des changements de transport MCP.

CometAPI fournit un endpoint compatible OpenAI qui peut servir de couche d’accès aux modèles derrière les applications MCP. Cela maintient la logique de fournisseurs de modèles séparée des outils MCP, des ressources et de l’orchestration des tâches.

Par exemple, un outil MCP peut appeler un modèle via le même client compatible OpenAI utilisé ailleurs dans l’application :

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

Le serveur MCP reste responsable du contrat de l’outil, de l’autorisation, de l’état et du traitement des résultats. La passerelle de modèles gère la sélection des modèles, l’accès au fournisseur et les réponses d’inférence.

Garder ces couches séparées apporte deux avantages pratiques :

1. Les clients et serveurs MCP peuvent migrer vers le nouveau protocole sans changer la couche d’intégration des modèles.
2. Les fournisseurs de modèles peuvent être changés sans redessiner les outils MCP ni le comportement de transport.

Pour plus de détails d’implémentation, voir le Quickstart CometAPI, la documentation API et le guide des applications multi-modèles.

Liste de contrôle de migration MCP 2026-07-28

Client

• Mettre à niveau vers un SDK compatible.
• Activer la négociation de version moderne.
• Prendre en charge server/discover.
• Inclure les métadonnées de protocole dans chaque requête.
• Gérer resultType.
• Prendre en charge MRTR ou le rejeter explicitement.
• Utiliser un nouvel ID JSON-RPC pour les retentatives.
• Préserver et renvoyer requestState.
• Valider les émetteurs OAuth.
• Stocker les identifiants par émetteur.
• Respecter les indications de cache.
• Prendre en charge subscriptions/listen si nécessaire.

Serveur

• Retirer les verrous d’initialisation modern-request.
• Supprimer les dépendances à Mcp-Session-Id.
• Implémenter server/discover.
• Remplacer l’état caché par des handles ou du stockage partagé.
• Renvoyer resultType.
• Remplacer les requêtes initiées par le serveur par MRTR.
• Protéger requestState.
• Valider toutes les inputResponses.
• Ajouter l’idempotence pour les effets de bord.
• Renvoyer des listes déterministes.
• Publier des indications de cache conservatrices.
• Migrer le travail longue durée vers l’extension Tasks.

Passerelle et infrastructure

• Valider les en-têtes de requête MCP.
• Comparer les en-têtes avec le corps de la requête.
• Supprimer l’affinité de session inutile.
• Tester les requêtes sur plusieurs instances.
• Partitionner les caches par périmètre d’autorisation.
• Ajouter un bus de notifications partagé si nécessaire.
• Suivre le trafic hérité et déprécié.
• Maintenir une voie de retour arrière pendant le canari.

FAQ

Qu’est-ce que MCP 2026-07-28 ?

MCP 2026-07-28 est la spécification Model Context Protocol publiée le 28 juillet 2026. Elle introduit un noyau de protocole sans état, les Multi Round-Trip Requests, des en-têtes de routage HTTP, des résultats mis en cache, des changements d’autorisation, des extensions et un cycle de dépréciation formel.

Mcp-Session-Id est-il supprimé ?

Oui. Le nouveau protocole Streamable HTTP n’utilise plus Mcp-Session-Id.

Les applications peuvent toujours préserver l’état via des handles explicites, du stockage partagé, des tâches durables ou des valeurs de request-state protégées.

La poignée de main d’initialisation MCP est-elle supprimée ?

Oui. Les requêtes modernes ne requièrent plus l’échange initialize et notifications/initialized.

Les serveurs doivent implémenter server/discover, bien que les clients n’aient pas besoin de l’appeler avant chaque opération.

MCP sans état signifie-t-il que les outils ne peuvent pas préserver l’état ?

Non. Sans état se réfère à la couche protocole.

Un outil peut toujours stocker de l’état, mais le traitement des requêtes ne doit pas dépendre d’une affinité de transport cachée ni d’un processus serveur spécifique.

Qu’est-ce que MRTR ?

Les Multi Round-Trip Requests permettent à un serveur de demander des informations ou une saisie utilisateur supplémentaires sans envoyer une requête initiée par le serveur sur une connexion bidirectionnelle continuellement ouverte.

Le serveur renvoie input_required, et le client retente l’opération d’origine avec les réponses demandées.

HTTP+SSE est-il supprimé immédiatement ?

Non. Il est déprécié plutôt qu’immédiatement supprimé.

Les nouveaux serveurs doivent utiliser Streamable HTTP, tandis que les systèmes existants doivent mesurer et migrer le trafic HTTP+SSE restant.

Les clients SDK TypeScript v2 utilisent-ils MCP 2026-07-28 automatiquement ?

Non. Le SDK TypeScript v2 nécessite une configuration explicite de négociation de version pour utiliser le protocole moderne.

Utilisez la négociation automatique lorsque le client doit fonctionner avec des serveurs modernes et hérités.

Recommandations finales

MCP 2026-07-28 facilite la mise à l’échelle, le routage, la mise en cache et l’observabilité de l’infrastructure MCP distante. Le principal risque de migration n’est pas simplement la suppression d’un en-tête ou d’une poignée de main. Ce sont l’état applicatif caché et la logique d’interaction qui peuvent encore en dépendre.

Avant de déployer le nouveau protocole :

Trouvez chaque dépendance à l’initialisation et à Mcp-Session-Id.

1. Déplacez l’état requis vers des handles explicites ou du stockage partagé.
2. Implémentez MRTR avec expiration, protection contre la relecture et idempotence.
3. Validez les en-têtes MCP par rapport au corps JSON-RPC.
4. Partitionnez les caches par tenant et périmètre d’autorisation.
5. Renforcez la validation de l’émetteur OAuth.
6. Mesurez les méthodes dépréciées et le trafic de transport hérité.
7. Déployez en canari les chemins de protocole moderne et hérité avant leur retrait.

Traitez la migration comme un changement d’infrastructure plutôt qu’une simple mise à jour de SDK.

Une fois la couche MCP sans état et observable, conservez l’accès aux modèles derrière une interface séparée. Cela permet au protocole d’outils et à la couche de fournisseurs de modèles d’évoluer indépendamment.