Gepubliceerd:

Nieuwe MCP-specificatie maakt het protocol stateless: dit betekent het voor je organisatie

Kort: de MCP-specificatie van 28 juli 2026 is de grootste herziening sinds het ontstaan van het protocol. MCP is niet langer een stateful sessieprotocol maar een stateless request/response-protocol, de autorisatie is aangescherpt en functies als Tasks en MCP Apps zijn ondergebracht in een formeel extensiemodel. Bestaande koppelingen blijven werken: er geldt een deprecatietermijn van minimaal twaalf maanden.

Het Model Context Protocol draait inmiddels op serieuze schaal: de officiële SDK's worden samen bijna een half miljard keer per maand gedownload, en de TypeScript- en Python-SDK's passeerden elk de grens van één miljard totale downloads. Juist op die schaal begon de oorspronkelijke architectuur te knellen — en daar grijpt deze release op in.

Wat is er precies veranderd?

De kern: MCP was een sessieprotocol, waarbij client en server eerst een handshake deden (initialize) en daarna een sessie bijhielden via een Mcp-Session-Id-header. Dat is verdwenen. Elke request staat nu op zichzelf en kan op elke serverinstance achter een gewone load balancer landen, zonder gedeelde sessieopslag. Voor wie remote MCP-servers draait is dat de belangrijkste winst: goedkoper schalen, minder complexiteit, minder foutscenario's.

De belangrijkste wijzigingen op een rij:

Wat betekent dit voor bedrijven die MCP al gebruiken?

Voor de meeste organisaties is het antwoord geruststellend. Lokale stdio-servers — de meerderheid van wat teams vandaag draaien — merken van de statelessness in de praktijk weinig. Wie via een client als Claude of Copilot kant-en-klare servers gebruikt, hoeft niets te doen: de clientmakers regelen de migratie.

Actie is wél nodig voor teams die zelf remote MCP-servers bouwen of hosten. Code die leunt op sessie-identifiers heeft aanpassing nodig; de officiële migratiegidsen behandelen precies dit scenario. De vier Tier 1 SDK's (TypeScript, Python, Go en C#) ondersteunen de nieuwe specificatie per direct, Rust is in bèta. En er is een formeel vangnet: deprecaties — waaronder roots, sampling, logging en het oude HTTP+SSE-transport — krijgen een venster van minimaal twaalf maanden.

Ons advies

Geen paniekmigratie. Zet drie dingen op de planning: (1) inventariseer welke van je koppelingen remote lopen en op welke protocolversie, (2) plan de migratie van zelfgebouwde remote servers binnen het twaalfmaandsvenster, en (3) neem de autorisatie-aanscherpingen mee als je toch aan het migreren bent — die RFC 9207-validatie is geen formaliteit maar dicht een echt aanvalspad. Zie ook onze gids zelf een MCP-server bouwen en veiligheid & watchouts.

De grotere lijn

Deze release laat zien dat MCP volwassen wordt op de manier die je hoopt bij een open standaard: het protocol wordt kleiner in de kern en strenger aan de randen, terwijl de governance — sinds eind 2025 ondergebracht bij de Agentic AI Foundation onder de Linux Foundation — voorspelbaarheid aanbrengt met een formele deprecatiepolitiek. Voor organisaties die twijfelden of MCP een blijvertje is, is dit het duidelijkste ja tot nu toe.

Bronnen

Veelgestelde vragen

Moet ik mijn bestaande MCP-servers direct migreren?

Nee. Er geldt een formele deprecatietermijn van minimaal twaalf maanden en de vorige protocolversie blijft in die periode ondersteund. Plan de migratie wel in: nieuwe clients gaan de stateless variant als standaard behandelen.

Werken mijn huidige MCP-koppelingen nog na deze release?

Ja. De Tier 1 SDK's (TypeScript, Python, Go, C#) ondersteunen de nieuwe specificatie en er zijn migratiegidsen voor code die op sessie-identifiers leunt. Lokale stdio-servers merken er in de praktijk weinig van.

Wat is het belangrijkste voordeel van een stateless MCP?

Schaalbaarheid en eenvoud aan serverkant: requests kunnen op elke instance achter een gewone load balancer landen, zonder gedeelde sessieopslag. Dat maakt remote MCP-servers goedkoper en robuuster om te draaien.

Laatst bijgewerkt: