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-releasekandidaat 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 zijn MCP-server de nieuwe specificatie al ondersteunde en beschreef het protocol op 28 juli als “staatloos gaan”.

De praktische betekenis is duidelijk: MCP krijgt minder de vorm van een sessie-zware lokale integratielaag en meer als een protocol op internetschaal voor toegang tot tools op afstand. Dat is van belang omdat agentsystemen niet langer beperkt zijn tot desktopontwikkelaarstools. Ze draaien steeds vaker binnen cloudservices, CI-systemen, workflows voor klantondersteuning, issue trackers en bedrijfsautomatiseringsplatforms.

Wat er is veranderd in MCP

De belangrijkste verandering is de overstap naar een staatloze protocolkern. De changelog van GitHub zegt dat de nieuwe kern sessies verwijdert en initialiseert, met als doel om externe MCP-implementaties gemakkelijker schaalbaar te maken. Dat is een belangrijke architecturale verschuiving. Stateful protocollen kunnen goed werken voor lokale tools en gecontroleerde omgevingen, maar ze compliceren horizontale schaalbaarheid, 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 gemakkelijker implementeren met behulp van beheerde rekenkracht in plaats van een aangepaste, langlopende infrastructuur.

De bredere release van 2026-07-28 introduceert ook een Extensions-framework en taken, volgens het materiaal van de release-kandidaat. Deze toevoegingen suggereren dat MCP modulairer wordt en explicieter wordt over langerlopend werk. MCP-apps en autorisatieverharding wijzen in dezelfde richting: het protocol rijpt van vroege ecosysteemlijm naar een meer formele laag voor agent-naar-tool-interactie.

De kosten van die rijping zijn compatibiliteitswerk. Het MCP-blog typeerde de release als één 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 staatloze MCP belangrijk 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 bouwen.

Door sessies uit de kern te verwijderen, past MCP beter bij omgevingen waar de werkbelasting van agenten onrustig, gedistribueerd en asynchroon is. 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 workflowlagen in plaats van deze in de kern van het protocol in te bedden.

Voor ontwikkelaars zou de verandering het uiteindelijk gemakkelijker moeten maken om externe toolservers te gebruiken. Voor platformteams kan het de observatie en capaciteitsplanning vereenvoudigen. In plaats van fouten op te sporen in het affiniteitsgedrag van ondoorzichtige sessies, kunnen operators zich concentreren op traceringen op verzoekniveau, latentie bij het aanroepen van tools, 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 bellen, tot welke gegevens ze toegang hebben en welke gebruikers of services deze mogen aanroepen. De verscherping van de autorisatie in de nieuwe herziening is daarom niet incidenteel.Het weerspiegelt de realiteit dat toegang tot tools nu een beveiligingsgrens is, en niet alleen een gemak voor ontwikkelaars.

Wie wordt getroffen

De meest direct getroffen groepen zijn MCP-serveronderhouders, SDK-gebruikers, agentplatformteams en organisaties die interne tools blootstellen aan AI-agents. 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 ook onder het bereik. MCP verschijnt steeds vaker naast codeeragenten, aangepaste agenten en functies voor modelbeheer. Een stateless protocolkern maakt het voor deze producten gemakkelijker om op betrouwbare wijze tools op afstand 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 modelrouting, API-sleutelbeheer, gebruiksanalyses en team-API-beheer. Omdat agentsystemen MCP-toolaanroepen toevoegen naast gewone modelaanroepen, zullen 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 het testen van compatibiliteit. Teams moeten MCP-clients en -servers inventariseren, afhankelijkheden van sessies identificeren of gedrag initialiseren, en testen aan de hand van de 2026-07-28 SDK's of conformiteitsmaterialen, indien beschikbaar. Productiesystemen moeten de upgrade in fases uitvoeren, vooral als agenten acties uitvoeren met bijwerkingen zoals het creëren 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 modeloproepen en tooloproepen, vooral wanneer de workflows 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 bij MCP-implementaties op afstand.

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 de implementatienota van GitHub. De definitieve normatieve formulering van de specificatie van 2026-07-28 moet 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, niet alleen een bladwijzer.