MCP 2026-07-28 : Le Guide du Protocole Sans État

Le Model Context Protocol s'apprête à évoluer en profondeur. Le release candidate de la spécification 2026-07-28 est désormais disponible, marquant le changement architectural le plus important depuis l'open-source de MCP. Le titre : MCP devient sans état (stateless) — et tout ce qui concerne la construction, le déploiement et la mise à l'échelle des serveurs d'outils IA découle de cette décision.

La spécification finale sort le 28 juillet. Voici ce qui change, ce qui est déprécié, et comment migrer.

Le grand changement : MCP devient sans état

Les versions précédentes de MCP exigeaient une poignée de main de session. Chaque relation client-serveur débutait par un échange initialize / initialized établissant une session, après quoi l'en-tête Mcp-Session-Id fixait toutes les requêtes suivantes sur une instance de serveur spécifique. Ce design fonctionnait pour les déploiements sur un seul nœud, mais créait des frictions réelles dans les environnements distribués : routage collant au niveau du load balancer, magasins de sessions partagés entre instances, et contournements ajoutant de la complexité opérationnelle sans valeur ajoutée.

Le release candidate 2026-07-28 supprime tout cela. La poignée de main initialize est supprimée. L'en-tête Mcp-Session-Id n'existe plus. Toute requête MCP peut désormais atterrir sur n'importe quelle instance de serveur, ce qui signifie qu'un load balancer round-robin standard suffit — aucune couche de coordination n'est requise.

Les métadonnées client qui résidaient auparavant dans la poignée de main de session voyagent maintenant dans _meta à chaque requête. Les capacités du serveur sont récupérées à la demande via une nouvelle méthode server/discover. La gestion de l'état au niveau applicatif fonctionne exactement comme avant — vous transmettez des identifiants de handles explicites à travers les appels d'outils plutôt que de vous appuyer sur l'état de transport caché.

Impact sur l'infrastructure

Pour les équipes qui font tourner des serveurs MCP à grande échelle, c'est le changement que vous attendiez :

• Plus de routage collant au niveau du load balancer
• Plus de magasins de sessions partagés entre instances
• Mise à l'échelle horizontale sans coordination au niveau protocole
• Reprise après sinistre simplifiée — les instances de serveur sont entièrement interchangeables

MCP Apps : des interfaces interactives dans vos outils

MCP Apps est une nouvelle extension de première classe qui permet aux serveurs de fournir des interfaces interactives à l'intérieur du client. Au lieu de texte brut ou de JSON structuré, un outil peut retourner un iframe sécurisé contenant une interface HTML complète rendue côté serveur.

Les outils déclarent des templates d'interface à l'avance pour le préchargement et la revue de sécurité. Une fois rendu, les interactions avec l'interface transitent par le même protocole JSON-RPC que les appels d'outils standard — même piste d'audit, mêmes mécanismes de consentement.

Les cas d'usage que cela ouvre incluent : des workflows d'approbation avec des interfaces de formulaire riches, des tableaux de bord de visualisation de données intégrés dans la réponse de l'agent, et des flux de configuration multi-étapes qui paraissent natifs au client. Tout cela se passe dans la couche MCP, sans aucun canal latéral personnalisé.

Extension Tasks : le travail longue durée officialisé

Les Tasks étaient auparavant une fonctionnalité expérimentale dans la spec principale. Le RC 2026-07-28 les élève au rang d'extension officielle avec un cycle de vie repensé adapté au modèle sans état.

Le nouveau flux :

1. Une réponse tools/call retourne un handle de tâche plutôt qu'un résultat immédiat
2. Les clients pilotent l'exécution via tasks/get, tasks/update et tasks/cancel
3. tasks/list est supprimée — sans sessions, lister toutes les tâches en cours n'a pas de définition sûre

Si vous avez une implémentation Tasks construite sur l'API expérimentale 2025-11-25, la migration est requise. Le cycle de vie dirigé par le serveur est une reconception significative du modèle précédent.

Requêtes multi-allers-retours (MRTR)

Un nouveau pattern InputRequiredResult — appelé Multi Round-Trip Requests (MRTR) — permet aux outils de s'arrêter en milieu d'exécution et de demander des entrées supplémentaires à l'utilisateur. Le client affiche la demande, collecte la réponse, et reprend l'exécution avec les données fournies.

Cela est particulièrement utile pour les outils qui ont besoin de clarifications avant d'effectuer une action irréversible, ou pour les workflows dont les paramètres corrects dépendent de résultats intermédiaires qui n'émergent qu'au moment de l'exécution.

Renforcement de l'autorisation

Six propositions d'amélioration rapprochent l'autorisation MCP des pratiques standard OAuth 2.0 et OpenID Connect :

• Les clients doivent valider le paramètre iss selon la RFC 9207 pour prévenir les attaques par confusion
• Les clients déclarent application_type lors de l'enregistrement OpenID Connect
• Les identifiants sont liés au serveur d'autorisation émetteur
• Les patterns de requête de token de rafraîchissement sont désormais documentés
• Les mécanismes d'accumulation de scope et de découverte sont clarifiés

Ce ne sont pas des changements rétrocompatibles au sens strict. Ils formalisent des pratiques que les déploiements MCP sécurisés suivaient déjà.

Ce qui est déprécié

Trois fonctionnalités reçoivent une dépréciation formelle sous une nouvelle politique de cycle de vie de douze mois. Elles restent fonctionnelles — c'est une annotation, pas une suppression :

La politique de dépréciation formelle garantit au minimum douze mois entre l'annotation de dépréciation et toute considération de suppression. Plus de changements cassants surprises dans le prochain cycle de révision.

Routage de passerelle sans analyse du corps

Deux nouveaux en-têtes de transport — Mcp-Method et Mcp-Name — permettent aux passerelles API de router les requêtes par méthode et nom d'outil sans analyser le corps de la requête JSON-RPC. C'est un ajout pratique pour les déploiements en périphérie et les architectures de sécurité qui doivent router des appels d'outils spécifiques vers différents backends.

Checklist de migration

Deux changements nécessitent une action avant la spécification finale :

Code d'erreur : les ressources non trouvées retournaient auparavant le code personnalisé -32002. La spec impose désormais le code JSON-RPC standard -32602. Mettez à jour toute logique de correspondance d'erreurs côté client.

Suppression de session : si votre client ou serveur définit ou lit Mcp-Session-Id, supprimez ce code. Si votre serveur pousse les capacités pendant initialize, passez à la réponse à server/discover à la place.

Les betas SDK sont disponibles maintenant

Des versions bêta pour les quatre SDK Tier 1 sont disponibles dès aujourd'hui :

# Python
pip install "mcp[cli]==2.0.0b1"
 
# TypeScript
npm install @modelcontextprotocol/server@beta
 
# Go
go get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1
 
# C#
dotnet add package ModelContextProtocol --prerelease

Les utilisateurs TypeScript bénéficient d'un codemod automatisé pour la migration v1 vers v2 :

npx @modelcontextprotocol/codemod@beta v1-to-v2 .

Python et TypeScript incluent tous deux des guides de migration. La compatibilité ascendante est maintenue — les serveurs v2 répondent aux requêtes du protocole legacy, vous pouvez donc migrer à votre rythme.

Calendrier

• Release candidate : disponible maintenant
• Spécification finale : 28 juillet 2026
• Versions stables SDK Tier 1 : dans les dix semaines suivant la spec finale

Prochaines étapes

Le passage au modèle sans état est la bonne décision architecturale pour les outils IA à grande échelle, et le chemin de migration est bien soutenu par les betas SDK. Lisez l'annonce officielle du RC et le billet sur les betas SDK pour comprendre votre périmètre de migration spécifique.

Le 28 juillet approche. Les outils sont prêts. Commencez la migration maintenant.