Spec 2026-07-28 · zes dagen oud

MCP werd staatloos

Op 28 juli 2026 verscheen de grootste herziening sinds MCP bestaat. De sessie is weg, de initialize-handshake is weg, en de server mag jouw client niet meer uit zichzelf iets vragen. Dit is geen optionele opfrisbeurt — wie een remote MCP-server draait, moet er langs. Scan hieronder wat er in jouw geval breekt, wat over twaalf maanden verdwijnt, en wat het je oplevert.

01

Wat er veranderde

Vier verschuivingen dragen de rest. De onderliggende beweging is telkens dezelfde: een verbinding was iets dat je onderhield, en wordt iets dat je per bericht opnieuw beschrijft.

Geen sessie meer

De Mcp-Session-Id-header en de initialize/notifications/initialized-handshake zijn verdwenen. Elk verzoek draagt zijn eigen protocolversie, client-identiteit en capabilities mee in _meta. Heb je toch state nodig tussen aanroepen, dan geef je die als gewoon tool-argument door — een handle die de server zelf uitgeeft.

De server vraagt niet meer terug

Server-initiated requests (roots/list, sampling/createMessage, elicitation/create) zijn vervangen door Multi Round-Trip Requests. De server antwoordt met resultType: "input_required" plus een lijst inputRequests; de client stuurt het oorspronkelijke verzoek opnieuw, nu met inputResponses erbij.

Lijsten zijn cachebaar

tools/list en zijn broertjes moeten nu ttlMs en cacheScope teruggeven, en de lijst mag niet meer per verbinding verschillen. Daarnaast reizen Mcp-Method- en Mcp-Name-headers mee op elke POST, zodat een gateway kan routeren zonder de JSON open te maken.

De randen zijn extensies geworden

Tasks verhuisde uit de experimentele kern naar de officiële extensie io.modelcontextprotocol/tasks. Naast Tasks staan MCP Apps (interactieve HTML in een sandbox-iframe) en Enterprise-Managed Authorization in hetzelfde extensie-raamwerk. Extensies zijn altijd uit tenzij je ze aanzet.

Hoeveel tijd heb je

Er zijn twee snelheden. Wat weg is, is weg zodra je op de nieuwe protocolversie overstapt. Wat deprecated is, blijft minimaal twaalf maanden werken onder het nieuwe lifecycle-beleid.

25 november 2025
Vorige revisie. Sessies, handshake, roots, sampling en logging zijn hier nog gewoon de norm.
28 juli 2026 — nu
Staatloze kern, MRTR, server/discover, cachebare lijsten. Tier 1-SDK's (TypeScript, Python, Go, C#) zijn bij; Rust volgt in bèta.
Ten minste tot juli 2027
Roots, sampling, logging, het HTTP+SSE-transport en Dynamic Client Registration blijven werken, maar bouw er niets nieuws meer op. Minimaal twaalf maanden deprecatievenster.
02

Migratiescan

Dertien vragen over je eigen server of client. Het rapport eronder groeit mee: rood breekt bij de overstap, geel verdwijnt binnen het deprecatievenster, groen is iets dat nu pas kan. Je antwoorden blijven in deze browser.

0 van 13 beantwoord
03

Voor en na

Zes plekken waar het bericht zelf van vorm verandert. Links de oude revisie, rechts 2026-07-28.

Vóór 2025-11-25

    
Na 2026-07-28

    
04

Wat het oplevert

De migratie kost werk. Dit is wat je ervoor terugkrijgt — en de twee dingen die je kwijtraakt en niet zomaar terugbouwt.

Je infrastructuur wordt saai, en dat is de winst

  • Sticky sessions kunnen weg. Zonder Mcp-Session-Id mag elke aanroep bij een willekeurige instantie landen. Een gewone round-robin load balancer volstaat.
  • Serverless en edge worden haalbaar. Er is geen verbinding meer die je open moet houden tussen aanroepen, dus een functie die per verzoek opstart en afsluit past nu op het protocol.
  • Horizontaal schalen zonder gedeelde sessieopslag. De Redis of database die alleen bestond om sessie-state tussen instanties te delen, heeft geen taak meer.
  • Gateways routeren op headers. Mcp-Method en Mcp-Name staan in de HTTP-headers, dus je proxy hoeft de JSON-body niet te parsen om te weten waar het heen moet.
  • Minder verkeer door caching. Met ttlMs stopt de client met pollen op je tool-lijst; met cacheScope: "public" mag een tussenliggende cache het antwoord zelfs delen.
  • Betere prompt-cache-treffers. De spec vraagt om een deterministische volgorde in tools/list — dezelfde volgorde betekent dezelfde prefix, en dus een goedkopere aanroep bij het model.
  • Kwijt: hervatbare streams. Last-Event-ID en SSE-event-ID's zijn geschrapt. Breekt de stream, dan is het verzoek weg en moet de client het opnieuw sturen met een nieuw request-ID. Idempotentie is nu jouw verantwoordelijkheid.
  • Kwijt: de server als initiatiefnemer. Wil je iets van de client weten, dan moet je je werk kunnen onderbreken en hervatten wanneer het antwoord bij een volgende poging binnenkomt. Dat is een echte herstructurering, geen zoekopdracht-vervangactie.

De volgorde die het minst pijn doet

Als je nog moet beginnen: dit is de route waarbij je server het langst blijft werken.

  • Eén. Werk je SDK bij en implementeer server/discover. Dat is puur additief — oude clients merken er niets van.
  • Twee. Zet resultType, ttlMs en cacheScope op je results. Ook additief; velden die een oude client negeert.
  • Drie. Maak je sessie-state expliciet: verplaats wat in de sessie zat naar een handle die je als tool-argument teruggeeft en accepteert.
  • Vier. Herstructureer server-initiated calls naar MRTR. Dit is het echte werk, en het gaat over je eigen uitvoeringsmodel — niet over het protocol.
  • Vijf. Vervang het GET-endpoint en resources/subscribe door subscriptions/listen, en pas je auth aan op Client ID Metadata Documents.
  • Zes. Pas dan de handshake en de sessie-header slopen.
05

Bronnen

Alles op deze pagina komt uit de officiële specificatie en het bijbehorende releasebericht. Waar de spec een SEP-nummer noemt, staat de discussie in die pull request.