Op 28 juli 2026 is een nieuwe revisie van de Model Context Protocol-specificatie gepubliceerd, aangekondigd door lead maintainers David Soria Parra en Den Delimarsky. Het is de opvolger van de revisie 2025-11-25 en de ingrijpendste wijziging sinds het protocol bestaat: MCP wordt in de kern stateless. De handshake verdwijnt, sessie-ID's verdwijnen, en elk verzoek draagt zelf alle informatie die een server nodig heeft om het af te handelen.
Dit artikel behandelt eerst kort wat MCP is, en daarna wat er in deze revisie verandert. Het gaat uitsluitend over de specificatie; wat individuele SDK's, clients of leveranciers ermee doen komt aan het eind apart aan bod.
Wat MCP is (kort)
Het Model Context Protocol is een open protocol waarmee een AI-toepassing (de client, bijvoorbeeld een chatinterface of codeer-assistent) gestandaardiseerd praat met externe systemen (de servers) die tools, bronnen en prompts aanbieden. Een MCP-server kan een databasekoppeling zijn, een ticketsysteem, een bestandssysteem of een zoekdienst. De client vraagt de server welke tools er zijn (tools/list), roept ze aan (tools/call) en krijgt gestructureerde resultaten terug. Berichten volgen JSON-RPC; als transport worden stdio (lokaal) en Streamable HTTP (op afstand) gebruikt.
Tot en met de revisie 2025-11-25 begon elke verbinding met een initialize/initialized-uitwisseling, waarin client en server versie en mogelijkheden afstemden. Bij HTTP kreeg die verbinding een Mcp-Session-Id, en de server hield per sessie bij wat er was afgesproken. Die opzet werkt goed voor één client en één server, maar wordt lastig zodra een server op meerdere instanties achter een load balancer draait: elke instantie moet dan dezelfde sessiestaat kennen.
De kern: geen sessies, geen handshake
De revisie 2026-07-28 verwijdert beide. Concreet:
- De
initialize/notifications/initialized-handshake bestaat niet meer. - De
Mcp-Session-Id-header is uit het Streamable HTTP-transport gehaald. - Elk verzoek draagt zelf de protocolversie en de client-capabilities mee in
_meta(io.modelcontextprotocol/protocolVersion,io.modelcontextprotocol/clientCapabilities). Clients horen zich per verzoek te identificeren viaio.modelcontextprotocol/clientInfo; servers identificeren zich in elk resultaat viaio.modelcontextprotocol/serverInfo. - Een nieuwe RPC
server/discoverlaat een client vooraf opvragen welke protocolversies, capabilities en identiteit een server heeft. Servers moeten dit implementeren; clients mogen het aanroepen, bijvoorbeeld als compatibiliteitsprobe op stdio. - Lijst-eindpunten (
tools/list,resources/list,prompts/list) variëren niet meer per verbinding.
Het gevolg is dat, in de woorden van de aankondiging, elk verzoek bij elke instantie terecht kan komen "achter een gewone round-robin load balancer zonder gedeelde opslag". Servers die toch staat over meerdere aanroepen nodig hebben, geven een expliciete, door de server uitgegeven handle terug uit een tool en laten het model die als gewoon argument terugsturen.
Migratiekosten zijn er wél
De aankondiging erkent "enige migratiekosten, vooral voor ontwikkelaars die afhankelijk waren van sessie-identifiers". Wie sessiestaat gebruikte om bijvoorbeeld een ingelogde gebruiker of een geopend document te onthouden, moet dat verplaatsen naar expliciete handles in toolargumenten.
Multi Round-Trip Requests (MRTR)
Een server had tot nu toe drie manieren om iets aan de client te vragen tijdens een toolaanroep: roots/list, sampling/createMessage en elicitation/create. Dat waren server-geïnitieerde verzoeken en die vereisten een open stream terug naar de client, wat weer staat is.
MRTR vervangt dat patroon. Heeft een tool halverwege extra informatie nodig (een bevestiging, een ontbrekende parameter), dan geeft de server een tussenresultaat terug met resultType: "input_required" en in inputRequests de vragen. De client herhaalt daarna het oorspronkelijke verzoek met de antwoorden in inputResponses. Elk resultaat krijgt hierdoor een verplicht veld resultType: "complete" voor gewone resultaten, "input_required" voor tussenresultaten. Resultaten van oudere servers zonder dat veld moeten als "complete" worden behandeld.
In lijn hiermee zijn notifications/elicitation/complete en het elicitationId-veld uit 2025-11-25 weer verwijderd: de client leert de uitkomst van een interactie door het verzoek opnieuw te sturen.
Routing op HTTP-headers
Streamable HTTP-POST-verzoeken moeten nu twee headers meesturen: Mcp-Method met de JSON-RPC-methode en Mcp-Name met de naam van de tool, prompt of resource. Gateways, rate limiters en WAF's kunnen daardoor routeren en beleid toepassen zonder de JSON-body te parsen. Het voorbeeld uit de aankondiging:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}
Daarnaast kunnen toolparameters via x-mcp-header als aangepaste headers worden meegestuurd, en is er een HeaderMismatchError gedefinieerd voor het geval header en body niet overeenkomen.
Cachebare lijstresultaten
Resultaten van tools/list, prompts/list, resources/list, resources/read en resources/templates/list dragen nu verplicht twee velden via de nieuwe CacheableResult-interface:
ttlMs: een versheidshint in milliseconden, zodat clients minder hoeven te pollen;cacheScope:"public"of"private", dat bepaalt of gedeelde tussenliggende caches het antwoord mogen bewaren.
Servers worden bovendien aangeraden tools in een deterministische volgorde terug te geven, wat zowel client-caching als de prompt-cache van LLM-providers ten goede komt.
Autorisatie aangescherpt
Vier wijzigingen in het OAuth-gedeelte:
- Issuer-validatie (RFC 9207). Autorisatieservers horen de
iss-parameter mee te geven; clients moeten die vergelijken met de vastgelegde issuer voordat ze de autorisatiecode inwisselen. application_typebij Dynamic Client Registration, om conflicten met OpenID Connect-redirect-URI's te voorkomen.- Credentials gebonden aan de uitgevende server. Clients moeten opgeslagen credentials op issuer indexeren, mogen ze niet bij een andere autorisatieserver hergebruiken en moeten zich opnieuw registreren als de autorisatieserver wijzigt.
- DCR verouderd. Dynamic Client Registration (RFC 7591) is als registratiemechanisme verouderd ten gunste van Client ID Metadata Documents (CIMD). DCR blijft beschikbaar voor autorisatieservers die CIMD niet ondersteunen.
Extensieraamwerk en verplaatste functies
ClientCapabilities en ServerCapabilities krijgen een extensions-veld. De eerste functie die naar dat raamwerk verhuist zijn de experimentele tasks: die zitten nu in de officiële extensie io.modelcontextprotocol/tasks. Het blokkerende tasks/result is vervangen door pollen via tasks/get, er is een nieuw tasks/update voor invoer van client naar server, tasks/list is verwijderd, en servers mogen ongevraagd een task-handle teruggeven.
Wijzigingsmeldingen lopen niet meer via het HTTP-GET-eindpunt en resources/subscribe/unsubscribe, maar via één langlevende stream: subscriptions/listen. Clients kiezen daarbij welke meldingstypen ze willen (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions). Verzoekgebonden meldingen zoals notifications/progress blijven op de responsestream van het bijbehorende verzoek. Ook verwijderd: ping, logging/setLevel en notifications/roots/list_changed; het logniveau gaat per verzoek mee in _meta. SSE-hervatting (Last-Event-ID) is uit het transport gehaald: een afgebroken stream betekent dat de client het verzoek opnieuw stuurt met een nieuw ID.
Verouderd verklaard
Met deze revisie is voor het eerst een formeel feature-lifecycle- en deprecatiebeleid vastgesteld (Active, Deprecated, Removed) met een minimale deprecatieperiode van twaalf maanden en een register van verouderde functies. Onder dat beleid zijn verouderd verklaard:
- Roots, Sampling en Logging. Ze blijven werken tijdens de deprecatieperiode, maar nieuwe implementaties horen ze niet meer toe te voegen. Aanbevolen alternatieven: mappen en bestanden via toolparameters of configuratie in plaats van Roots; rechtstreeks de LLM-provider-API in plaats van Sampling;
stderrof OpenTelemetry in plaats van Logging. - Het oude HTTP+SSE-transport (al afgeraden sinds 2025-03-26), met volgens de aankondiging "een jaar aan afbouwtijd". Migratie naar Streamable HTTP.
- De
includeContext-waarden"thisServer"en"allServers". - Dynamic Client Registration, zoals hierboven beschreven.
Kleinere wijzigingen: OpenTelemetry-tracecontext (traceparent, tracestate, baggage) in _meta is gedocumenteerd, inputSchema/outputSchema accepteren alle JSON Schema 2020-12-sleutelwoorden, de foutcode voor een niet-gevonden resource is -32602 geworden, en de MCP-specifieke foutcodes zijn hernummerd naar het bereik -32020 tot -32099.
Specificatie versus implementaties
Alles hierboven beschrijft het protocol. Of een bepaalde client of server het op 30 juli 2026 daadwerkelijk ondersteunt, is een andere vraag. De aankondiging noemt de stand voor de officiële SDK's: de Tier 1-SDK's voor TypeScript, Python, Go en C# ondersteunen 2026-07-28 op de releasedag; de Rust-SDK heeft bètaondersteuning. Over de status van specifieke producten of hosts van derden zegt de specificatie niets; die informatie moet per leverancier worden nagegaan.
Samengevat
De revisie 2026-07-28 verschuift MCP van een verbindingsgericht naar een verzoekgericht protocol. De handshake en sessie-ID's maken plaats voor metadata per verzoek en server/discover; server-geïnitieerde vragen worden MRTR; headers maken routering mogelijk zonder JSON te lezen; lijsten zijn cachebaar; de autorisatielaag sluit aan op RFC 9207 en CIMD; en tasks en notificaties verhuizen naar een extensiemodel. Roots, Sampling, Logging en het oude SSE-transport gaan een deprecatieperiode van minimaal twaalf maanden in.
