Door het team van Kiwop · Digital Agency gespecialiseerd in Softwareontwikkeling en toegepaste Kunstmatige Intelligentie · Gepubliceerd op 29 juli 2026 · Laatst bijgewerkt: 29 juli 2026
TL;DR — Op 28 juli 2026 verscheen de vijfde revisie van MCP, en het is de grootste verandering sinds het protocol ontstond. Sessies en de `initialize`-handshake verdwijnen: elk verzoek reist alleen, met zijn versie en capabilities in `_meta`. De verzoeken die de server eerder zelf startte (sampling, elicitation, roots) gaan naar het multi round-trip patroon. Er komen verplichte headers om te routeren zonder de body te openen, cachebare lijsten en strengere autorisatie. Draait uw server lokaal via stdio, dan is er geen haast. Is hij remote en houdt hij een sessie vast, dan begint het herontwerp vandaag. Wat afgeschreven is, houdt twaalf maanden stand.
Er zijn protocolupdates die in één changelog-regel passen, en updates die veranderen hoe de software die ze spreekt wordt uitgerold. Revisie 2026-07-28 van Model Context Protocol is van de tweede soort. Ze voegt geen functie toe aan een protocol dat u al kende: ze neemt het zijn geheugen af. En als een protocol stopt met onthouden, verandert niet de API maar de architectuur van alles wat eronder draait.
In april publiceerden we onze vergelijking van MCP, WebMCP en A2A en schreven we dat de volgende relevante mijlpaal de consolidatie van Streamable HTTP en het uitfaseren van legacy SSE zou zijn. Beide zijn uitgekomen, en er kwam onderweg flink wat meer bij dan we verwachtten. Dit artikel is de technische lezing van wat er precies verandert, wat breekt, en wat een team met MCP-servers in productie moet doen. Met de specificatie in de hand, niet met de samenvatting uit het persbericht.
Wat er op 28 juli verscheen
MCP ontstond in november 2024 zodat een model met externe tools kon praten zonder dat elke integratie een maatwerkadapter werd. Sinds december 2025 bestuurt Anthropic het niet meer alleen: het protocol leeft onder de Agentic AI Foundation, binnen de Linux Foundation, met Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare en Bloomberg onder de leden. Dat gedeelde bestuur verklaart de toon van deze revisie, die veel meer klinkt als een infrastructuurstandaard dan als de API van één leverancier.
Revisie 2026-07-28 is de vijfde van de specificatie en komt met twee procesnieuwtjes die net zo zwaar wegen als de technische wijzigingen. Ten eerste: er is eindelijk een formeel feature-lifecyclebeleid, met drie toestanden (Actief, Afgeschreven, Verwijderd) en een minimumvenster van twaalf maanden voordat er iets verdwijnt. Ten tweede: er is een openbaar register van afgeschreven functies met de vroegste datum waarop elk mag sneuvelen. Voor wie software in productie onderhoudt is dat net zoveel waard als het protocol zelf, want het maakt planning tot iets dat in een roadmap past.
De kernverandering: van sessie naar zelfstandig verzoek
Tot deze revisie betekende MCP spreken: een gesprek openen. De client stuurde initialize, de server antwoordde met zijn capabilities, de client bevestigde met notifications/initialized, en vanaf dat moment namen beide de context als bekend aan: welke versie werd gesproken, wat elk kon, wie wie was. Over HTTP kreeg dat gesprek de vorm van een Mcp-Session-Id-header die de server uitgaf en de client bij elke aanroep herhaalde.
Dat is allemaal verdwenen.
Wat verdwijnt
Weg zijn de initialize-handshake en de bijbehorende notifications/initialized. Weg is de Mcp-Session-Id-header en daarmee het begrip sessie op protocolniveau. Weg is het GET-endpoint van Streamable HTTP, waarlangs de server zijn kanaal opende om op eigen initiatief te spreken. Weg zijn resources/subscribe en resources/unsubscribe. Weg zijn ping, logging/setLevel en notifications/roots/list_changed. En weg is de hervatbaarheid van SSE-streams: er zijn geen Last-Event-ID en geen event-identifiers meer, dus een gebroken stream verliest het lopende verzoek en de client moet het opnieuw versturen als nieuw verzoek met een nieuwe identifier.
Het is een lange lijst, en dat is geen toeval. Alles wat verdween had dezelfde eigenschap: het ging ervan uit dat de verbinding iets betekende.
Wat ervoor in de plaats komt
Nu verklaart elk verzoek zichzelf. Wat eerder één keer aan het begin werd vastgelegd, reist in het veld _meta van elke aanroep, onder door de specificatie gereserveerde sleutels:
protocolVersion en clientCapabilities zijn verplicht bij elk verzoek: ontbreekt er één, dan moet de server afwijzen met -32602 en, over HTTP, met een 400 Bad Request. clientInfo is aan te raden, tenzij u een reden hebt om zich niet te identificeren. Aan serverkant luidt de aanbeveling om io.modelcontextprotocol/serverInfo op te nemen in de _meta van elk resultaat. Lees de opmerking van de specificatie over deze twee velden goed: ze zijn zelfgerapporteerd, niemand verifieert ze, en ze mogen geen beveiligingsbeslissingen dragen of gedrag veranderen.
Ook de versieonderhandeling verandert van aard. Er is geen moment van overeenstemming meer: de client verklaart bij elk verzoek welke versie hij spreekt en de server accepteert of weigert elk verzoek apart. Ondersteunt hij die niet, dan antwoordt hij met UnsupportedProtocolVersionError (code -32022) en een lijst van versies die hij wel ondersteunt, zodat de client het opnieuw probeert met een compatibele.
Voor clients die het vooraf willen weten is er een nieuwe methode, server/discover, die ondersteunde versies, capabilities en identiteit in één aanroep teruggeeft. Servers moeten die implementeren. Clients mogen kiezen: gewoon de aanroep doen die u nodig hebt en de versiefout afhandelen als die opduikt, is prima.
Waarom dit goed nieuws is
Het praktische gevolg is dat een MCP-server geen geheugen meer nodig heeft tussen aanroepen, en dat verandert alles aan de uitrol. Zonder sessie is er geen sticky routing op de load balancer nodig, geen gedeelde opslag tussen instanties, geen langlevende processen. Een MCP-server wordt wat elk platformteam al jaren kan draaien: een stateless HTTP-endpoint dat horizontaal schaalt, serverless of aan de edge wordt uitgerold, en op- en afgaat zonder iets mee te slepen.
De specificatie is expliciet dat zelfs een open stdio-proces geen gesprek is: de client mag ongerelateerde verzoeken over hetzelfde transport door elkaar sturen, en de server mag procesidentiteit niet als vervanger van continuïteit gebruiken. Heeft uw server wel echte staat tussen aanroepen nodig (een werksessie, een winkelwagen, een analysecontext), dan is de juiste route nu expliciet: geef zelf een identifier uit en laat de client die als gewoon argument van de tool meesturen.
Multi Round-Trip Requests: het einde van server-verzoeken
De tweede grote verandering raakt de meeste code in servers die iets interessants doen.
Tot nu toe opende een server die halverwege een operatie iets van de client nodig had (een gebruikersantwoord via elicitation, een modelaanroep via sampling, de mappenlijst via roots) zijn eigen JSON-RPC-verzoek in tegengestelde richting. Dat vereiste een open kanaal en, in de praktijk, dat dezelfde instantie de hele operatie afhandelde.
Het nieuwe patroon heet Multi Round-Trip Requests en draait de stroom om: de server vraagt niet, de server beëindigt het verzoek met een vraag. Hij geeft een resultaat terug met resultType: "input_required" met daarin een map inputRequests met wat hij nodig heeft, en optioneel een ondoorzichtige requestState. De client verzamelt die informatie en probeert het oorspronkelijke verzoek opnieuw met de antwoorden in inputResponses en de requestState ongewijzigd terug.
Drie details die je bij snel lezen mist en die later een middag debuggen kosten. De JSON-RPC-id van de nieuwe poging moet verschillen van het oorspronkelijke verzoek, want het zijn onafhankelijke verzoeken. requestState is ondoorzichtig voor de client, die het niet mag inspecteren of wijzigen, maar vanuit de server bezien is het door de aanvaller gestuurde invoer: beïnvloedt het autorisatie of bedrijfslogica, dan moet het beschermd worden met HMAC of AEAD, kort geldig zijn, gebonden aan de geauthenticeerde principal en het oorspronkelijke verzoek, en geweigerd worden als de verificatie faalt. En InputRequiredResult mag alleen worden teruggegeven bij prompts/get, resources/read en tools/call, nergens anders.
Als neveneffect dragen alle resultaten nu een verplicht veld resultType, met "complete" voor het gewone geval. Praat u met een server van een eerdere revisie die het weglaat, dan geldt het als "complete".
De rest van de veranderingen die u merkt
Verplichte headers voor routing. Elk POST-verzoek over Streamable HTTP moet Mcp-Method met de methode dragen, en Mcp-Name met de toolnaam of resource-URI bij tools/call, resources/read en prompts/get. Dat klinkt als papierwerk tot u bedenkt wie er vóór uw server staat: een load balancer, gateway of WAF kan nu routeren, meten en beleid toepassen zonder de JSON-body te openen. De server moet controleren dat header en body overeenkomen, en anders afwijzen met 400 en HeaderMismatch (-32020). Er is zelfs een mechanisme om specifieke toolparameters naar headers te spiegelen (x-mcp-header), bedoeld voor zaken als routeren per regio.
Cachebare lijsten. De resultaten van tools/list, prompts/list, resources/list, resources/read en resources/templates/list dragen nu ttlMs en cacheScope (public of private). Het eerste is een versheidshint zodat de client cachet in plaats van polt; het tweede zegt of een gedeelde tussenlaag het mag bewaren. En er is een kleine aanbeveling met groot effect: geef tools uit tools/list in een deterministische volgorde terug, zodat de prompt van het model niet verandert tussen aanroepen en de prompt-cache van de LLM vaker raak is.
Abonnementen. Wat eerst via een GET liep, vraagt u nu aan met subscriptions/listen, een verzoek waarvan het antwoord een stream is die open blijft. De client kiest waarop hij zich abonneert (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions) en de server labelt elke notificatie met io.modelcontextprotocol/subscriptionId. Voortgangs- en lognotificaties reizen nog steeds over de stream van het verzoek waar ze bij horen, niet hierlangs.
Autorisatie. Drie aanscherpingen. Autorisatieservers zouden de parameter iss moeten meesturen volgens RFC 9207, en de client moet die valideren tegen de vastgelegde issuer voordat hij de code inwisselt. Credentials zijn gebonden aan de issuer die ze uitgaf: opgeslagen onder die sleutel, nooit hergebruikt met een andere, en opnieuw registreren als de autorisatieserver wijzigt. En dynamische clientregistratie (DCR, RFC 7591) is afgeschreven ten gunste van Client ID Metadata Documents, al blijft ze beschikbaar voor autorisatieservers die CIMD nog niet ondersteunen.
Fouten. Er is eindelijk een toewijzingsbeleid: -32000 tot -32019 blijft erfgoed dat niemand nieuw zou moeten gebruiken, en -32020 tot -32099 is exclusief terrein van de specificatie. De drie nieuwe codes zijn HeaderMismatch (-32020), MissingRequiredClientCapability (-32021) en UnsupportedProtocolVersion (-32022). Daarnaast gaat de fout voor niet-gevonden resource van -32002 naar -32602, al zouden clients de oude van oudere servers moeten blijven accepteren.
Tasks buiten de kern. De experimentele taken verlaten het basisprotocol en worden een officiële extensie (io.modelcontextprotocol/tasks), met polling via tasks/get in plaats van het blokkerende tasks/result. In dezelfde lijn krijgen client- en server-capabilities een veld extensions om alles buiten de kern te onderhandelen.
Wat breekt en wat niet
Dit is de tabel om bij de hand te hebben voordat u iets aanraakt. De specificatie noemt modern de versies die metadata bij elk verzoek dragen (vanaf 2026-07-28) en legacy die met handshake (2025-11-25 en eerder).
Het belangrijkste staat in de twee rijen die falen: een oude client kan niet praten met een uitsluitend moderne server, en kan daar niets aan doen. Daarom vraagt de specificatie dat een uitsluitend moderne server in de fout waarmee hij op een initialize antwoordt de ondersteunde versies noemt: het kan de enige diagnose zijn die de gebruiker van die client ooit ziet.
Een server die beide werelden wil bedienen kan dat, en beslist op basis van hoe de client opent: draagt het verzoek modern _meta, dan bedient hij het stateless; komt er een initialize, dan gaat hij in oude modus. Een client die hetzelfde wil, herkent het tijdperk van de server per transport: bij stdio door te sonderen met server/discover en terug te vallen op initialize bij elke fout die geen herkenbare moderne fout is; over HTTP door een modern verzoek te sturen en de body van de 400 te bekijken voordat hij beslist. Dat resultaat wordt per server gecachet, niet per verzoek.
Wat u moet aanpassen, per geval
Gebruikt u MCP-servers lokaal via stdio, wat geldt voor de meeste persoonlijke assistenten en vrijwel alles wat in een IDE draait, dan is er geen haast. Uw client en uw servers onderhandelen de versie die beide spreken, en de vorige revisie blijft geldig. Wat u moet doen is de SDK bijwerken wanneer u die server toch om een andere reden aanraakt, niet er een aparte migratie van maken. Precies dat gaan wij doen met de servers van de persoonlijke assistent die we met Claude Code bouwden.
Hebt u een remote server die een sessie vasthoudt, dan ligt hier architectuurwerk, en wel nu. Dit is geen bibliotheek vervangen: dit is de staat uit het proces halen. Inventariseer wat u vandaag tussen aanroepen bewaart en beslis per onderdeel of het verdwijnt (omdat de client het nu in _meta meestuurt), of het een expliciete handle wordt die de client als argument meedraagt, of dat het naar een externe opslag gaat, geïndexeerd op die handle. Alles wat ervan afhangt dat twee aanroepen op dezelfde instantie landen, kunt u als dood beschouwen. De beloning is echt: aan het eind draait uw server serverless.
Opent uw server verzoeken naar de client (sampling, elicitation of roots), dan moet u die stroom herbouwen met MRTR. Dit is de wijziging die de meeste logica verzet, want u gaat van een gespreksmodel naar een model waarin elke poging zelfstandig is en de context reist in de requestState die u ondertekent en verifieert. Begin daar, niet bij de rest.
Begint u een nieuwe MCP-server, bouw dan direct op 2026-07-28. Er is geen reden om vandaag op het sessiemodel te bouwen, en er is er één om het niet te doen: over twaalf maanden migreert u wat u net hebt geschreven.
Onderhoudt u een client, dan is het werk anders en waarschijnlijk groter: u moet beide tijdperken nog lang ondersteunen, cachen wat elke server spreekt en degradatie met verstand afhandelen. De vier tier-1 SDK's (TypeScript, Python, Go en C#) ondersteunen de nieuwe revisie al, die van Rust is in bèta, dus een flink deel krijgt u kant-en-klaar als u bijblijft.
Het echte tijdpad
Het mooiste aan het lifecyclebeleid is dat u met data kunt plannen in plaats van met geruchten. Dit is wat afgeschreven is en hoe lang het standhoudt:
Let op die laatste rij, dat is de echt urgente. Het HTTP+SSE-transport was al sinds maart 2025 afgeschreven en valt nu formeel onder het beleid, met een venster van slechts drie maanden. Praat er bij u nog iets over, dan is dat de dringende migratie, niet de andere.
Verwijderbaar betekent niet dat het die dag verdwijnt: die beslissing nemen de maintainers per release en kan later vallen. Maar het is de datum om op te plannen.
Wat wij zouden doen
Drie criteria die we op dit soort veranderingen toepassen, en die hier extra gelden.
Migreer niet om bij te blijven, migreer om een reden. Een stdio-server die werkt hoeft deze week niet aangeraakt. De kosten van migreren zonder reden zijn niet alleen tijd: het is het risico dat u introduceert in iets dat goed liep. Het venster van twaalf maanden bestaat om gebruikt te worden.
Wat wél urgent is, is wat nu wordt ontworpen. Elke nieuwe MCP-server, en elk platform dat zijn API voor agents opengaat zetten, wordt vanaf dag één stateless ontworpen. Dat is de beslissing die later het duurst is om te wijzigen, want het is geen bibliotheek maar hoe u werk over instanties verdeelt. Bij ons raakt dat direct hoe Nexo zijn capaciteiten aan de agents van zijn klanten gaat aanbieden: het ontwerp wordt gemaakt tegen de nieuwe revisie, niet tegen de bekende.
Wees voorzichtig met product bouwen op experimentele oppervlakken. Dat leerden we met WebMCP: we bouwden op een origin trial van Chrome en een wijziging aan browserzijde brak de navigatie van onze eigen site, met onze health checks op groen. MCP 2026-07-28 is niet experimenteel, maar de les geldt onverkort: adopteert u iets pas gepubliceerds, weet dan hoe u het uitzet als het misgaat, en controleer het resultaat met handen en ogen, niet alleen met een code 200.
Veelgestelde vragen
Breekt er vandaag iets als ik niets doe? Nee, zolang uw client en uw servers dezelfde revisie spreken. Wat werkte blijft werken, en de vorige revisie blijft ondersteund. Het breekt als u tijdperken mengt: een oude client tegen een server die alleen de nieuwe spreekt, of andersom.
Hoeveel tijd heb ik echt? Minimaal twaalf maanden voor Roots, Sampling, Logging en dynamische clientregistratie, gerekend vanaf 28 juli 2026. De uitzondering is het HTTP+SSE-transport, dat drie maanden na finalisering van zijn voorstel kan sneuvelen.
Moet ik `server/discover` implementeren? Schrijft u een server, dan ja: het is verplicht. Schrijft u een client, dan niet: u kunt de aanroep doen die u nodig hebt en de versiefout afhandelen als die verschijnt. Bij stdio is het bovendien de aanbevolen manier om te bepalen of de server tegenover u modern of oud is.
Wat doe ik met de staat die ik in de sessie bewaarde? Haal die uit het proces. Wat protocolcontext was, reist nu in de _meta van elk verzoek. Wat applicatiestaat is, wordt een expliciete identifier die u uitgeeft en de client als argument teruggeeft, met de echte data zo nodig in een externe opslag.
Raakt dit WebMCP? Nee. WebMCP is het browservoorstel, aangejaagd door Chrome en uitgewerkt bij het W3C, en volgt zijn eigen pad. Het is een andere laag: MCP verbindt de agent met serverside tools, WebMCP stelt acties beschikbaar vanuit de website die de gebruiker openheeft.
En desktopclients zoals Claude of ChatGPT? Producten nemen de nieuwe revisie in hun eigen tempo over, en geen enkele heeft concrete data gepubliceerd. Intussen onderhandelen ze per server een versie, dus samenleven is bij ontwerp voorzien.
Conclusie
De korte lezing van 2026-07-28 is dat MCP zich niet langer gedraagt als een gesprek maar als een API. Elk verzoek verklaart zichzelf, de server onthoudt niets, en alles wat geheugen nodig had is herontworpen of geschrapt. Dat maakt het protocol saaier om te lezen en veel makkelijker om te draaien, en dat is precies wat iets nodig heeft dat infrastructuur wil zijn.
Voor de meeste teams luidt het praktische antwoord deze week: doe niets urgents en plan goed. Voor wie remote servers met sessie heeft, of op het punt staat te ontwerpen hoe het platform opengaat voor agents, is het antwoord omgekeerd: het werk begint nu, en het begint met de staat uit de weg halen.
Zit u in het tweede geval en wilt u het ontwerp toetsen bij iemand die het al heeft gedaan, dan praten we. We bouwen al twee jaar in productie op LLM's, we draaien MCP-servers en we hebben de rekening betaald voor te vroeg adopteren.
