Mis à jour le 2026-09-10

MCP 2026-07-28: ce qui change (faits spec)

La spécification MCP 2026-07-28 a été publiée le 28 juillet 2026. Le billet officiel décrit notamment un cœur de protocole sans état, les requêtes multi-allers-retours, le routage par en-têtes et un renforcement de l’autorisation. Il faut vérifier la compatibilité de chaque client et SDK avant une migration.

Quatre blocs sont à retenir:

  • Un core stateless au niveau du protocole
  • Des extensions de première classe (MCP Apps, Tasks)
  • Une autorisation alignée sur OAuth et OpenID Connect
  • Une politique de dépréciation formelle, avec au moins 12 mois entre la dépréciation et un retrait possible

Si ton équipe branche des MCP remote en production, traite cette release comme un runbook d'infra et de sécurité, pas comme une note « nice to have ».

Core stateless: fini le sticky session protocolaire

Avant, avec la version 2025-11-25 par exemple, tu avais un handshake initialize, un header Mcp-Session-Id, des instances collées et souvent un store de session partagé. Après la 2026-07-28, les requêtes deviennent auto-contenues, la version de protocole s'indique par requête, et les headers Mcp-Method et Mcp-Name permettent de router sans ouvrir le body.

Le protocole ne gère plus la session pour toi. L'état applicatif passe par des handles explicites, comme un basket_id, que le modèle repasse en argument d'outil. C'est plus visible pour l'agent et plus simple pour un load balancer en round-robin.

Le Multi Round-Trip suit la même logique: le serveur peut renvoyer un InputRequiredResult (elicitation), puis le client rejoue l'appel avec les réponses. N'importe quelle instance peut reprendre, parce que l'état utile vit dans le payload.

MCP OAuth: ce que l'auth exige maintenant

Plusieurs SEP durcissent l'authorization. Côté pratique d'équipe, les clients doivent maintenant valider le paramètre iss sur les réponses d'auth (RFC 9207), pour limiter les attaques de mix-up, fréquentes quand un client parle à beaucoup de serveurs MCP.

Les serveurs remote se comportent de plus en plus comme des resource servers OAuth 2.x, avec des métadonnées de ressource protégée, des resource indicators et des credentials liés à l'issuer. Les synthèses d'implémentation, chez WorkOS par exemple, insistent aussi sur l'évolution du client registration: le CIMD est recommandé et le DCR passe en retrait.

La policy minimale tient en quatre lignes:

  • Aucun token passthrough aveugle
  • Des scopes minimaux
  • Des logs d'auth
  • Un re-register si un serveur change d'issuer

L'approbation humaine sur les outils à impact reste hors protocole: c'est du HITL métier.

Extensions: Apps, Tasks, dépréciations

Les MCP Apps apportent une UI HTML rendue côté serveur dans une iframe sandboxée, et leurs actions retraversent le même chemin d'audit que les tools. Tasks sort du core expérimental pour devenir une extension au lifecycle aligné stateless, avec un handle de tâche et les opérations get, update et cancel.

Roots, Sampling et Logging sont dépréciés par annotation et restent un temps sous la politique de lifecycle. Les remplacements indiqués sont les paramètres d'outils et les URIs, les API LLM directes, puis stderr ou OpenTelemetry pour les logs.

Ne confonds pas « on a un MCP » avec « on a la bonne version de spec et le bon tier de SDK ». Versionne le protocolVersion et teste la conformité.

Checklist migration PME (1 page)

La migration tient sur une page:

  1. Inventorie tes MCP, en séparant le local stdio du remote
  2. Note qui expose quoi (scopes, données)
  3. Fixe les SDK et le protocolVersion cibles
  4. Cadre l'auth: issuer, registration, refresh, logs
  5. Vérifie le load balancing sans sticky session protocolaire
  6. Ajuste le TTL et le cache des listes de tools
  7. Branche des traces OpenTelemetry
  8. Nomme un owner, une date de cutover et un plan de rollback

Le guide evergreen MCP (model-context-protocol-mcp) explique pourquoi brancher des outils; cette actu date le delta de juillet 2026.

Les sources principales sont le blog officiel MCP pour la RC 2026-07-28 et les notes d'implémentation OAuth, chez WorkOS notamment. Relis le changelog draft avant le cutover.

Si vous voulez auditer vos MCP remote et la policy OAuth sur un process réel, on peut cadrer en 20-40 minutes.

Questions fréquentes

Qu'est-ce que MCP OAuth ?

MCP OAuth désigne l'alignement de l'autorisation MCP sur les pratiques OAuth 2 et OIDC: resource servers, validation d'issuer, scopes et registration client. La spec 2026-07-28 durcit l'ensemble.

La spec 2026-07 casse-t-elle mon serveur MCP ?

Oui, des breaking changes sont annoncés, notamment sur les sessions protocolaires et le Tasks expérimental. Prévois une migration SDK et des tests. Les features dépréciées restent un temps sous lifecycle.

Faut-il encore des sticky sessions ?

Tu n'en as plus besoin au niveau protocole si tu es sur la 2026-07-28. L'état métier passe par des handles explicites, et ton app peut rester stateful ailleurs.

Lien avec le guide MCP kengdev ?

Le guide couvre les concepts et le cadrage, pendant que cet article date le delta auth et ops de juillet 2026. Chaque page garde une seule intention de recherche.

Roots et Sampling disparaissent ?

Ils sont dépréciés, pas retirés immédiatement. La politique de lifecycle garantit au moins 12 mois avant un retrait possible.

Que prioriser en PME ?

Commence par l'inventaire des MCP remote, l'auth (iss, scopes), la version des SDK, un owner nommé et des tests de non-régression sur une dizaine de tools critiques.

Sources et repères

Passons à votre cas concret.

Parlons de votre projet