MCP 2026-07: OAuth, core stateless, migration équipe

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

La release candidate MCP 2026-07-28 est présentée par le blog officiel comme la plus grande révision depuis le lancement. Cible: final le 28 juillet 2026. Breaking changes assumés, avec une fenêtre de validation pour les SDK.

Quatre blocs à retenir: (1) core stateless au niveau protocole, (2) extensions de première classe (MCP Apps, Tasks), (3) autorisation alignée OAuth / OpenID Connect, (4) politique de dépréciation formelle (fenêtre d'au moins 12 mois entre dépréciation et retrait possible).

Si ton équipe brancher des MCP remote en prod, ce n'est pas une note « nice to have ». C'est un runbook d'infra et de sécu.

Core stateless: fini le sticky session protocolaire

Avant (ex. 2025-11-25): handshake initialize, header Mcp-Session-Id, instances collées et souvent un store de session partagé. Après 2026-07-28: requêtes auto-contenues, version de protocole par requête, headers Mcp-Method / Mcp-Name pour router sans ouvrir le body.

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

Multi Round-Trip: le serveur peut renvoyer un InputRequiredResult (elicitation) puis le client rejoue l'appel avec les réponses. Toute instance peut reprendre parce que l'état utile est dans le payload.

MCP OAuth: ce que l'auth exige maintenant

Plusieurs SEP durcissent l'authorization. Côté pratique équipe: les clients doivent 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: métadonnées de ressource protégées, resource indicators, binding des credentials à l'issuer. Les synthèses d'implémentation (ex. WorkOS) insistent aussi sur l'évolution du client registration (CIMD recommandé, DCR en retrait).

Policy minimale: pas de token passthrough aveugle, scopes minimaux, logs d'auth, re-register si un serveur change d'issuer. L'approbation humaine sur les outils à impact reste hors protocole (HITL métier).

Extensions: Apps, Tasks, dépréciations

MCP Apps: UI HTML server-rendered en iframe sandboxed, actions retraversent le même chemin d'audit que les tools. Tasks sort du core expérimental pour une extension avec lifecycle aligné stateless (handle de tâche, get/update/cancel).

Roots, Sampling et Logging sont dépréciés (annotation): ils restent un temps sous la politique de lifecycle. Remplacements indiqués: paramètres d'outils / URIs, API LLM directes, stderr ou OpenTelemetry.

Ne mélange pas « on a un MCP » et « on a la bonne version de spec + SDK tier ». Versionne protocolVersion et teste la conformité.

Checklist migration PME (1 page)

1) Inventaire des MCP (local stdio vs remote). 2) Qui expose quoi (scopes, données). 3) SDK et protocolVersion cibles. 4) Auth: issuer, registration, refresh, logs. 5) Load balancing sans sticky session protocolaire. 6) TTL / cache des listes tools. 7) Traces OpenTelemetry. 8) Owner + date de cutover + plan de rollback.

Le guide evergreen MCP explique pourquoi brancher des outils. Cet actu date le delta 2026-07. Lien: model-context-protocol-mcp.

Sources: blog officiel MCP RC 2026-07-28; notes d'implémentation OAuth (ex. WorkOS). Relis le changelog draft avant cutover.

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