De 2026-07-28-specificatie van het Model Context Protocol is op 28 juli 2026 uitgebracht en de maintainers noemen het de belangrijkste release sinds remote MCP ruim een jaar geleden verscheen. De protocolkern is nu stateless: de initialize-handshake en de Mcp-Session-Id-header zijn verdwenen, server-geïnitieerde verzoeken zijn herontworpen rond een retry-patroon genaamd MRTR, autorisatie is aangescherpt, en Roots, Sampling en Logging zijn afgeschreven met een klok van twaalf maanden. Wat u vandaag draait, stopt niet — maar de migratie is echt, en de volgorde waarin u die doet, telt.
Wat er werkelijk breekt, in de volgorde waarin het u raakt
Drie weken geleden behandelden we de strategische afweging rond het stateless-ontwerp, toen dit nog een release candidate was, in MCP wordt stateless. Dat artikel beantwoordde de vraag óf u erop moet bouwen. Dit artikel beantwoordt wat u nu aanpast, nu de spec definitief is en alle vier de Tier 1-SDK's zijn uitgebracht. Zit u eerder in het traject en wilt u eerst de basis in plaats van de migratieverschillen, begin dan bij Wat is MCP?. Dat onderscheid telt, want de definitieve spec bracht details die de meeste berichtgeving over de release candidate oversloeg — MRTR voorop.
De belangrijkste verandering is de bekende: de initialize/initialized-uitwisseling en de Mcp-Session-Id-header zijn geschrapt. Elk verzoek draagt nu zijn eigen protocolversie, clientidentiteit en capabilities in een _meta-veld, en een nieuwe optionele server/discover-RPC laat een client die capabilities vooraf ophalen als hij dat wil. Elk verzoek kan bij elke instantie terechtkomen achter een gewone round-robin load balancer, zonder gedeelde sessieopslag. Leest uw servercode ergens een sessie-id? Dan is dat uw eerste en grootste aanpassing.
Het subtielere punt dat de officiële aankondiging maakt en dat de meeste secundaire berichtgeving mist: het schrappen van de sessie op protocolniveau dwingt uw applicatie niet om stateless te zijn. Heeft uw server echt state nodig over meerdere aanroepen, dan raden de maintainers aan een expliciete handle vanuit een tool uit te geven en die door het model als argument te laten terugsturen — state die het model kan zien en tussen tools kan doorgeven, in plaats van state verborgen in de transportlaag. Dat is een ontwerpinstructie, niet alleen een migratienotitie, en teams die dit missen bouwen sessies vaak slecht na bovenop een protocol dat ze net heeft verwijderd.
MRTR: de wijziging die stilletjes uw goedkeuringsstappen breekt
Multi Round-Trip Requests is het onderdeel dat u twee keer moet lezen. Server-geïnitieerde verzoeken — elicitation/create, sampling/createMessage en roots/list — vereisten voorheen een openstaande bidirectionele stream. Dat overleeft een stateless protocol niet, dus MRTR (SEP-2322) vervangt het: heeft een tool halverwege iets nodig, zoals een bevestiging of een ontbrekende parameter, dan geeft de server resultType: "input_required" terug met de verzoeken die beantwoord moeten worden, waarna de client de oorspronkelijke aanroep opnieuw doet met de antwoorden in inputResponses.
In de praktijk is dit de wijziging die het vaakst iets breekt waar een bedrijf echt op leunt, want menselijke goedkeuringsstappen zijn precies de flows die op elicitation gebouwd zijn. Pauzeert uw agent om iemand te vragen voordat een factuur de deur uitgaat, een prijs wijzigt of een record wordt verwijderd, dan draait die pauze op het oude server-geïnitieerde pad. Onder MRTR wordt diezelfde interactie een terugkeer-en-opnieuw-proberen-cyclus, wat betekent dat uw client dezelfde aanroep idempotent moet kunnen herhalen met verzamelde antwoorden. Teams die dit als een transportdetail behandelen, ontdekken op de harde manier dat het een herschrijving van de besturingslogica is. De head of product van Supabase omschreef MRTR publiekelijk als de wijziging die een stateless MCP-server eindelijk laat bevestigen bij een gebruiker vóórdat hij handelt — de kosten van een nieuw project, of een query die data zou verwijderen — precies het patroon waar mkb'ers om geven.
Autorisatie werd strenger, en DCR verdwijnt
Autorisatie is waar implementeerders de meeste integratietijd aan kwijt zijn, en deze revisie verzet meerdere dingen tegelijk. Autorisatieservers horen nu de iss-parameter terug te geven conform RFC 9207, en clients moeten die valideren voordat ze een code inwisselen — dat sluit een mix-up-gat bij autorisatieservers. Clientgegevens zijn nu gebonden aan de issuer die ze heeft uitgegeven, dus geen hergebruik tussen autorisatieservers. Clients zetten application_type tijdens Dynamic Client Registration, zodat autorisatieservers localhost-redirects voor desktop- en CLI-apps niet langer weigeren — de werkelijke oorzaak achter heel wat raadselachtige redirect_uri-fouten.
Het strategische punt in dat rijtje is het laatste: Dynamic Client Registration is nu formeel afgeschreven ten gunste van Client ID Metadata Documents. DCR blijft werken voor achterwaartse compatibiliteit en verdwijnt in een toekomstige revisie. Scoopt u dit kwartaal een integratie, bouw dan op CIMD en sla een migratie over die u anders twee keer doet.
Afschrijvingen lopen op twaalf maanden, niet op een deadline
Roots, Sampling en Logging zijn afgeschreven (SEP-2577). Ze werken nog en blijven minstens twaalf maanden werken onder het nieuwe formele afschrijvingsbeleid, dat een minimumtermijn van twaalf maanden vastlegt zodat teams upgrades kunnen plannen in plaats van erop te reageren. Het oude HTTP+SSE-transport is eveneens officieel afgeschreven, met een afrit van een jaar. Nieuwe implementaties horen geen van deze te gebruiken.
Tasks verhuisde ondertussen uit de experimentele kern naar de extensie io.modelcontextprotocol/tasks, met een poll-gebaseerde tasks/get en een nieuwe tasks/update. Wijzigingsmeldingen verhuizen van het oude HTTP GET-endpoint naar één subscriptions/listen-stream waarop clients zich per meldingstype abonneren. Twee andere extensies staan er nu als eersteklas naast: MCP Apps en Enterprise Managed Authorization.
Twee operationele voordelen die u gratis krijgt
Streamable HTTP-verzoeken moeten nu de headers Mcp-Method en Mcp-Name bevatten, zodat een gateway, rate limiter of WAF kan routeren en meten op headers in plaats van JSON-bodies te ontleden. Wie ooit een MCP-server per tool heeft proberen te rate-limiten, weet waarom dat uitmaakt. Daarnaast dragen antwoorden van tools/list, prompts/list, resources/list en resources/read nu ttlMs en cacheScope met een deterministische volgorde, zodat clients toolcatalogi kunnen cachen en upstream prompt-caches stabiel blijven over herverbindingen heen.
Dat tweede heeft een direct kostengevolg. Een onstabiele volgorde van de toollijst maakt upstream prompt-caches stilletjes ongeldig bij elke herverbinding, en missers in de prompt-cache zijn pure tokenkosten. Deterministische volgorde plus expliciete cache-hints is een stille efficiëntiewinst die op de factuur opduikt in plaats van in een benchmark — het soort winst dat u alleen opmerkt als u tokenkosten per aanroep traceert, de discipline die we beschreven in AI-agent observability.
Hoe groot is dit ecosysteem inmiddels echt
Een paar concrete adoptiecijfers van de maintainers, bruikbaar voor wie afweegt of MCP een veilige keuze is: over de Tier 1-SDK's heen ziet het project bijna een half miljard downloads per maand, waarbij zowel de TypeScript- als de Python-SDK de grens van één miljard totale downloads passeerde. Alle vier de Tier 1-SDK's — TypeScript, Python, Go en C# — spreken 2026-07-28 vanaf de releasedag, met de Rust-SDK in bèta. Honeycomb meldde dat inmiddels bijna 20% van al zijn maandelijkse interactieve queries door agents wordt gedaan. Manufact, de maintainer van het mcp-use-framework, meldde de pakketgrootte met ongeveer 83% te hebben teruggebracht en zo'n 25% sneller te draaien op de nieuwe client-serversplitsing.
Een migratievolgorde voor een mkb'er die in 2025 een integratie opleverde
- Begin met triage: grep op Mcp-Session-Id en op de initialize-handshake. Komt geen van beide voor, dan is uw migratie vooral een SDK-versiebump en het toevoegen van headers.
- Zoek elke menselijke goedkeuringsstap op. Alles wat op elicitation is gebouwd, vraagt de MRTR-herschrijving naar terugkeren-en-opnieuw-proberen, en de herhaalde aanroep moet idempotent zijn. Reserveer hier echte tijd voor, geen middag.
- Ga na waar u afhankelijk bent van Roots, Sampling en Logging. U heeft minstens twaalf maanden, maar verplaats Sampling naar provider-API's en Logging naar OpenTelemetry in plaats van te wachten op de verwijderingsmelding.
- Zet nieuw autorisatiewerk om naar CIMD, voeg iss-validatie conform RFC 9207 toe aan de client, en hergebruik clientgegevens niet meer tussen autorisatieservers.
- Voeg Mcp-Method en Mcp-Name toe op de gateway en gebruik ze vervolgens voor rate limiting per tool — de goedkoopste beveiligingsmaatregel in dit rijtje. Agent-specifieke dreigingen verdwijnen niet met een spec-update; zie AI-agentbeveiliging voor het dreigingsmodel dat onverminderd geldt.
Scoopt u een nieuwe integratie in plaats van een migratie, richt u dan vanaf dag één op 2026-07-28 en u slaat het bovenstaande volledig over. De stateless kern is echt eenvoudiger te beheren: gewone HTTP-hosting, geen sticky sessions, geen gedeelde sessieopslag, en horizontaal schalen zoals de rest van uw infrastructuur dat al doet. De operationele gewoonten voor dag twee veranderen niet door deze revisie — MCP draaien in productie behandelt die apart. Dat is het echte verhaal voor een bedrijf van 20 tot 50 fte — niet dat MCP capabeler werd, maar dat het saai genoeg werd om te draaien op de hosting die u toch al betaalt. Wij bouwen en migreren MCP-integraties tegen de actuele spec, en de triage hierboven is dezelfde die we op dag één van een traject uitvoeren.
Eén kanttekening om helder te benoemen: een protocolrevisie lost governance niet op. Toegangsbeheer, audit trails voor compliance en menselijke goedkeuringsstappen blijft u zelf ontwerpen — de spec verplaatst uw data betrouwbaar en houdt daar op. Geverifieerd tegen de specificatie en de SDK-release notes zoals gepubliceerd op 28 juli 2026; raadpleeg de officiële changelog voordat u een architectuur vastlegt, want het ecosysteem beweegt nog wekelijks.
