Het Model Context Protocol heeft een belangrijke infrastructuurmijlpaal bereikt: de herziening van 28-07-2026 verplaatst het protocol naar een staatloze kern. Voor teams die agentsystemen, toolservers, IDE-integraties of orkestratielagen met meerdere modellen bouwen, is dit geen cosmetische specificatie-update. Het verandert aannames over sessies, initialisatie, schaling, compatibiliteit en beheer.
De MCP release candidate beschreef de specificatie van 28 juli als het toevoegen van een staatloze protocolkern, een Extensieframework, Taken, MCP Apps, autorisatieverharding en een formeel beëindigingsbeleid. De officiële MCP blog waarschuwde ook dat de release belangrijke wijzigingen bevat. GitHub, dat een van de meest zichtbare MCP serverimplementaties beheert, zei voorafgaand aan de definitieve release dat de MCP Server de nieuwe specificatie al ondersteunde en beschreef het protocol op 28 juli als 'stateless gaan'.
De praktische betekenis is duidelijk: MCP krijgt minder de vorm van een sessie-zware lokale integratielaag en meer van een protocol op internetschaal voor externe toegang tot tools. Dat is van belang omdat agentsystemen niet langer beperkt zijn tot desktopontwikkelaarstools. Ze draaien steeds vaker binnen cloudservices, CI-systemen, workflows voor klantenondersteuning, probleemtrackers en platforms voor bedrijfsautomatisering.
Wat er is veranderd in MCP
De belangrijkste verandering is de overstap naar een staatloze protocolkern. Volgens de changelog van GitHub verwijdert de nieuwe core sessies en initialiseert deze, met als doel externe implementaties van MCP eenvoudiger schaalbaar te maken. Dat is een belangrijke architecturale verschuiving. Stateful protocollen kunnen goed werken voor lokale tools en gecontroleerde omgevingen, maar ze compliceren horizontale schaling, serverloze uitvoering, failover, edge-implementatie en taakverdeling.
Een staatloze kern geeft implementeerders meer vrijheid om MCP servers achter de gewone webinfrastructuur te laten draaien. Verzoeken kunnen over instances worden gedistribueerd zonder dat een langdurige sessie op een specifieke backend behouden blijft. Voor grote organisaties kan dit de operationele complexiteit verminderen. Voor kleinere teams kan het gehoste MCP-servers eenvoudiger implementeren met behulp van beheerde rekenkracht in plaats van een aangepaste, langlopende infrastructuur.
De bredere release van 28-07-2026 introduceert ook een extensieframework en taken, volgens het materiaal van de releasekandidaat. Deze toevoegingen suggereren dat MCP modulairer en explicieter wordt over langerlopend werk. MCP De verharding van apps en autorisatie wijst in dezelfde richting: het protocol rijpt van vroege ecosysteemlijm naar een meer formele laag voor interactie tussen agent en tool.
De kosten van die rijping zijn compatibiliteitswerk. De MCP blog typeerde de release als een release met belangrijke wijzigingen, en het TypeScript- en C# SDK-materiaal dat rond de herziening werd gepubliceerd, concentreerde zich op migratieondersteuning en staatloze concepten. Elk team dat een MCP server beheert, MCP in een IDE-extensie insluit of agentoproepen via de interne infrastructuur doorstuurt, moet de revisie behandelen als een technische gebeurtenis en niet als een update van de achtergrondstandaarden.
Waarom stateless MCP van belang is voor ontwikkelaars en operators
Agenttools hebben een schaalprobleem dat er anders uitziet dan gewone API schaling. Eén gebruikersverzoek kan vele tooloproepen, modelwisselingen, nieuwe pogingen, het lezen van bestanden, zoekopdrachten en goedkeuringsstappen activeren. Wanneer het toolprotocol uitgaat van duurzame sessies, moeten productie-operators de status van die interacties behouden of oplossingen rond het protocol bedenken.
Door sessies uit de kern te verwijderen, MCP past het beter bij omgevingen waar de werklasten van agenten onregelmatig, gedistribueerd en asynchroon zijn. Serverloze functies, edge-workers, Kubernetes-implementaties en systemen met meerdere regio's profiteren allemaal wanneer verzoeken onafhankelijk kunnen worden afgehandeld.Dat elimineert de status niet van agenttoepassingen; het verplaatst de status naar applicatiedatabases, taakwachtrijen, identiteitssystemen of expliciete werkstroomlagen in plaats van deze in te bedden in de protocolkern.
Voor ontwikkelaars zou de verandering uiteindelijk het gebruik van externe toolservers gemakkelijker moeten maken. Voor platformteams kan het de observatie en capaciteitsplanning vereenvoudigen. In plaats van het debuggen van ondoorzichtig sessie-affiniteitsgedrag, kunnen operators zich concentreren op traceringen op aanvraagniveau, latentie van toolaanroepen, autorisatiebeslissingen en foutpatronen.
Er is ook een governance-invalshoek. Naarmate MCP steeds gebruikelijker wordt bij codeerassistenten en bedrijfsagenten, zullen bedrijven beleid nodig hebben rond welke tools agenten kunnen aanroepen, tot welke gegevens ze toegang hebben en welke gebruikers of services deze mogen aanroepen. Authorization verharding in de nieuwe revisie is daarom niet incidenteel. Het weerspiegelt de realiteit dat toegang tot tools nu een veiligheidsgrens is, en niet alleen een gemak voor ontwikkelaars.
Wie wordt hierdoor getroffen
De meest direct getroffen groepen zijn MCP serverbeheerders, SDK gebruikers, agentplatformteams en organisaties die interne tools blootstellen aan AI-agenten. Als een server afhankelijk is van sessiegedrag of oudere initialisatiestromen, moet deze worden getest aan de hand van de nieuwe specificatie. Als een applicatie meerdere MCP versies ondersteunt, heeft deze mogelijk versieonderhandeling, compatibiliteitslagen of een gefaseerd migratieplan nodig.
Verkopers van IDE en ontwikkelaarstools vallen hier ook onder. MCP verschijnt steeds vaker naast codeeragenten, aangepaste agenten en functies voor modelbeheer. Een stateless protocolkern maakt het gemakkelijker voor deze producten om externe tools betrouwbaar aan te roepen, maar alleen als hun integraties gelijke tred houden met de specificaties.
Bedrijven die agentautomatisering gebruiken, moeten opletten, zelfs als ze de MCP specificatie nooit lezen. De wijziging kan van invloed zijn op de betrouwbaarheid van agenten die verbinding maken met opslagplaatsen, ticketingsystemen, databases, interne kennisbanken of implementatietools. Tijdens de migratieperiodes zijn de waarschijnlijke fouten niet alleen voor de hand liggende storingen. Het kan gaan om ontbrekende toolmogelijkheden, veranderd authenticatiegedrag of agenten die verschillende paden volgen omdat een toolserver zich niet langer gedraagt zoals verwacht.
Voor een AI API-gateway zoals Model Gate is de verbinding praktisch. Een uniforme AI API bevindt zich steeds vaker in de buurt van modelroutering, API sleutelbeheer, gebruiksanalyses en team API bestuur. Omdat agentsystemen MCP toolaanroepen toevoegen naast gewone modelaanroepen, zullen de gateway- en observatielagen rekening moeten houden met beide kanten van de workflow: welk model is gebruikt, welke tools zijn aangeroepen, wat ze kosten, wie ze heeft geautoriseerd en waar fouten zijn opgetreden.
Migratieprioriteiten en open vragen
De eerste migratieprioriteit is compatibiliteitstests. Teams moeten MCP clients en servers inventariseren, afhankelijkheden van sessies identificeren of gedrag initialiseren, en testen met de SDK's van 2026-07-28 of conformiteitsmateriaal, indien beschikbaar. Productiesystemen moeten de upgrade in fases uitvoeren, vooral als agenten acties uitvoeren met bijwerkingen zoals het maken van pull-verzoeken, het aanpassen van problemen, het opvragen van klantgegevens of het uitvoeren van implementatieworkflows.
De tweede prioriteit is observatie. Stateless infrastructuur kan gemakkelijker worden geschaald, maar gedistribueerde agentsystemen hebben nog steeds correlatie-ID's, traceringsregistratie, verzoeklogboeken en beleidsgebeurtenissen nodig. Zonder deze kunnen teams de complexiteit van sessies inruilen voor het debuggen van complexiteit. Gebruiksanalyses moeten onderscheid maken tussen modelaanroepen en toolaanroepen, vooral wanneer de werkstromen van agenten worden gefactureerd, aan een tariefbeperking worden onderworpen of door een team worden gecontroleerd.
De derde prioriteit is autorisatiebeoordeling. Als de nieuwe specificatie de autorisatiesemantiek verscherpt, moeten implementeerders niet simpelweg oude toegangsaannames overzetten naar de nieuwe versie. Ze moeten de tokenbereiken, gebruikersdelegatie, serviceaccounts, auditlogboeken en weigeringsgedrag opnieuw controleren.Toegang tot tools zou standaard de minste rechten moeten hebben, vooral voor implementaties op afstand MCP.
Sommige details blijven de moeite waard om te controleren voordat organisaties onomkeerbare ontwerpbeslissingen nemen. Het beschikbare onderzoek voor dit artikel omvatte de release candidate, de specificatiepagina, SDK migratiemateriaal en GitHub's implementatienotitie. De uiteindelijke normatieve bewoordingen van de specificatie van 28-07-2026 moeten direct worden herzien voordat de exacte protocolvereisten in interne standaarden of klantendocumentatie worden vermeld.
Zelfs met dit voorbehoud is de richting duidelijk. MCP wordt een meer productiegericht protocol voor agentinfrastructuur. De staatloze kern zou implementaties op afstand gemakkelijker schaalbaar moeten maken, maar dwingt het ecosysteem ook om aannames uit eerdere implementaties op te schonen. Voor teams die met agenten bouwen, is dit het soort protocolwijziging dat een sprintticket verdient, en niet alleen een bladwijzer.