Op 28 juli 2026 is revisie 2026-07-28 van de Model Context Protocol-specificatie gepubliceerd, samen met bijgewerkte SDK's. Het is de opvolger van revisie 2025-11-25. De kern van de release is een stateless protocol: MCP verandert volgens de aankondiging van een bidirectioneel, stateful protocol in een request/response-protocol zonder sessies. Co-uitvinder David Soria Parra noemt het in de aankondiging "MCP's belangrijkste release sinds remote MCP ruim een jaar geleden werd gelanceerd".
Ter schaal: de aankondiging meldt bijna een half miljard downloads per maand over de Tier 1-SDK's, waarbij zowel de TypeScript- als de Python-SDK de grens van 1 miljard downloads in totaal heeft gepasseerd.
Wat MCP is (kort)
Het Model Context Protocol is een open protocol waarmee een AI-toepassing (de client) gestandaardiseerd praat met externe systemen (de servers) die tools, resources en prompts aanbieden. De client vraagt welke tools er zijn (tools/list), roept ze aan (tools/call) en krijgt gestructureerde resultaten terug. Berichten volgen JSON-RPC; als transport worden stdio en Streamable HTTP gebruikt.
Tot en met revisie 2025-11-25 begon elke verbinding met een initialize/notifications/initialized-uitwisseling waarin client en server versie en capabilities afstemden, en kreeg een HTTP-verbinding een Mcp-Session-Id. Die sessiestaat moest bij een server op meerdere instanties gedeeld worden.
De kern: geen sessies, geen handshake
Revisie 2026-07-28 verwijdert beide (SEP-2567, SEP-2575):
- De
initialize/notifications/initialized-handshake bestaat niet meer. - De
Mcp-Session-Id-header is uit het Streamable HTTP-transport gehaald. - Elk verzoek draagt protocolversie en client-capabilities mee in
_meta(io.modelcontextprotocol/protocolVersion,io.modelcontextprotocol/clientCapabilities). Clients horen zich per verzoek te identificeren viaio.modelcontextprotocol/clientInfo, servers in elk resultaat viaio.modelcontextprotocol/serverInfo. Een versieconflict levertUnsupportedProtocolVersionErrorop. - De 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. Verplicht is het niet. - Lijst-eindpunten (
tools/list,resources/list,prompts/list) variëren niet meer per verbinding.
Het gevolg is dat 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; volgens de maintainers werkt dat beter dan sessiestaat die in het transport verborgen zit.
Migratiekosten zijn er wél
De aankondiging erkent "enige migratiekosten, vooral voor ontwikkelaars die afhankelijk waren van sessie-identifiers", en verwijst naar de migratienotities bij de SDK's. 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 drie manieren om iets aan de client te vragen tijdens een aanroep: roots/list, sampling/createMessage en elicitation/create. Die server-geïnitieerde verzoeken vereisten een openstaande stream terug naar de client.
MRTR (SEP-2322) vervangt dat patroon. Heeft een tool halverwege extra informatie nodig (een bevestiging, een ontbrekende parameter), dan geeft de server een InputRequiredResult terug met resultType: "input_required" en in inputRequests de vragen. De client herhaalt 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; een server die een elicitation over retries heen wil correleren, codeert zijn eigen identifier in requestState.
Routing op HTTP-headers
Streamable HTTP-POST-verzoeken moeten nu twee headers meesturen (SEP-2243): 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 HeaderMismatchError in het schema opgenomen 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 verplicht twee velden via de nieuwe CacheableResult-interface (SEP-2549):
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.
Beide velden zijn een aanvulling op de bestaande listChanged-meldingen. Servers horen tools bovendien in een deterministische volgorde terug te geven, wat client-caching en de prompt-cache-hitrate van LLM-providers ten goede komt.
Autorisatie aangescherpt
- Issuer-validatie (RFC 9207, SEP-2468). Autorisatieservers horen de
iss-parameter mee te geven; clients moeten die vergelijken met de vastgelegde issuer voordat ze de autorisatiecode inwisselen. Dit sluit een authorization-server-mix-up-lek. application_typebij Dynamic Client Registration (SEP-837), om conflicten met OpenID Connect-redirect-URI's te voorkomen; volgens de aankondiging de oorzaak vanredirect_uri-fouten bijlocalhost-redirects van desktop- en CLI-clients.- Credentials gebonden aan de uitgevende server (SEP-2352). 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, maar wordt in een toekomstige versie verwijderd.
Extensieraamwerk, tasks en notificaties
ClientCapabilities en ServerCapabilities krijgen een extensions-veld. Tasks verhuizen uit de experimentele kern naar de officiële extensie io.modelcontextprotocol/tasks (SEP-2663) en voegen zich bij bestaande extensies zoals MCP Apps en Enterprise Managed Authorization (EMA). 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/resources/unsubscribe, maar via één langlevende POST-responsestream: subscriptions/listen. Clients kiezen welke meldingstypen ze willen (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions); de server tagt meldingen met io.modelcontextprotocol/subscriptionId. Verzoekgebonden meldingen zoals notifications/progress en notifications/message blijven op de responsestream van het bijbehorende verzoek. Verwijderd zijn ping, logging/setLevel en notifications/roots/list_changed; het logniveau gaat per verzoek mee als io.modelcontextprotocol/logLevel in _meta, en zonder dat veld mag een server geen notifications/message sturen. 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 een formeel feature-lifecycle- en deprecatiebeleid vastgesteld (SEP-2596): de statussen Active, Deprecated en Removed, een minimale deprecatieperiode van twaalf maanden en een register van verouderde functies. Onder dat beleid zijn verouderd verklaard:
- Roots, Sampling en Logging (SEP-2577). Ze blijven minstens twaalf maanden werken, maar nieuwe implementaties horen ze niet meer toe te voegen. Aanbevolen alternatieven: mappen en bestanden via toolparameters, resource-URI's of serverconfiguratie in plaats van Roots; rechtstreeks de LLM-provider-API in plaats van Sampling;
stderr(stdio) of OpenTelemetry in plaats van Logging. - Het oude HTTP+SSE-transport (afgeraden sinds 2025-03-26), met "een jaar aan afbouwtijd". Migratie naar Streamable HTTP.
- De
includeContext-waarden"thisServer"en"allServers": veld weglaten of"none"gebruiken. - Dynamic Client Registration, zoals hierboven beschreven.
Kleinere wijzigingen: OpenTelemetry-tracecontext (traceparent, tracestate, baggage) in _meta is gedocumenteerd (SEP-414); inputSchema/outputSchema accepteren alle JSON Schema 2020-12-sleutelwoorden en structuredContent elke JSON-waarde (SEP-2106); de foutcode voor een niet-gevonden resource is van -32002 naar -32602 gegaan; en het bereik -32020 tot -32099 is gereserveerd voor de MCP-specificatie (-32000 tot -32019 blijft implementatie-specifiek), waarbij HeaderMismatch -32020, MissingRequiredClientCapability -32021 en UnsupportedProtocolVersion -32022 werd.
Specificatie versus implementaties
Alles hierboven beschrijft het protocol. 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 vanaf de releasedag, met migratienotities voor de brekende onderdelen; de Rust-SDK ondersteunt de nieuwe specificatie in bèta. Daarnaast bevat de aankondiging verklaringen van partners over hun eigen ondersteuning, onder meer Amazon Bedrock AgentCore, de Agents SDK van Cloudflare, Microsoft Foundry en FastMCP 4.0. Dat zijn uitspraken van de leveranciers zelf; of een specifieke client, server of host de revisie op 30 juli 2026 daadwerkelijk ondersteunt, moet per product worden nagegaan.
Samengevat
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; Mcp-Method en Mcp-Name maken routering mogelijk zonder JSON te lezen; lijsten zijn cachebaar met ttlMs en cacheScope; de autorisatielaag sluit aan op RFC 9207 en CIMD; en tasks en notificaties verhuizen naar een extensiemodel met tasks/get, tasks/update en subscriptions/listen. Roots, Sampling, Logging en het oude SSE-transport gaan een deprecatieperiode van minimaal twaalf maanden in.
