MCP Protocol Updates: DCR, OAuth CIMD, Streamable HTTP & MCP Apps

Het Model Context Protocol is in 2026 sneller veranderd dan de meeste teams konden bijhouden. De specificatie van 2026-07-28 — de eerste grote revisie na de release van november 2025 — voegde niet zomaar een functie toe; het veranderde de architectuur van het protocol. Autorisatie, transport, routing en interactie zijn allemaal gewijzigd, en verschillende veelgebruikte bouwstenen zijn afgeraden met een vaste verwijderingsdeadline.

Als u een handvol MCP-servers hebt die rechtstreeks op één agent zijn aangesloten, kunt u de changelog lezen en op uw eigen tempo migreren. Als u MCP gebruikt over vele teams, vele servers en vele agents, zijn deze wijzigingen geen eenvoudige changelog-entry — ze vormen een migratieproject, en de wijzigingen die het transport en de routing raken, zullen elke client bereiken die u beheert. Dit artikel behandelt wat er daadwerkelijk is veranderd, waarom elke wijziging is doorgevoerd en wat het betekent voor iedereen die MCP op schaal draait. Voor de basisconcepten is onze uitleg over wat een MCP-gateway is het juiste startpunt; dit artikel gaat ervan uit dat u de vorm van het protocol al kent en richt zich op wat de nieuwe revisie aanpast en oplost.

Wilt u het nieuwe MCP-transport, de auth en routing geregeld hebben op één controlepunt in plaats van bij elke client afzonderlijk? Boek een demo.

De release van 2026-07-28 in één oogopslag

Vijf wijzigingen dragen vrijwel al het operationele gewicht. Al het andere in de release is een afgeleide hiervan.

Het patroon is consistent: het protocol neemt afscheid van stateful, via streams onderhouden, impliciet gedrag en vervangt dit door expliciet, per-request, via headers zichtbaar gedrag. Die verschuiving maakt de nieuwe revisie geschikter voor gateways, proxies en rate limiters — en uitdagender voor clients die uitgingen van een langdurige sessie.

Autorisatie: DCR verdwijnt, CIMD doet zijn intrede

Met Dynamic Client Registration kon een client zichzelf tijdens de uitvoering registreren bij een autorisatieserver, waarbij runtime een client_id werd aangemaakt. Het was handig, maar veroorzaakte een probleem: elke client die zich meldde kreeg een registratie, wat leidde tot een onbegrensde, moeilijk te beheren populatie van identiteiten en een registratie-endpoint dat een permanent doelwit vormde.

De revisie van 2026-07-28 raadt DCR af ten gunste van Client ID Metadata Documents (CIMD). In plaats van te registreren om een identifier te verkrijgen, wordt een client geïdentificeerd door een URL die verwijst naar een ondertekend metadatadocument dat de client beschrijft. De autorisatieserver haalt dat document op en valideert het, in plaats van een registratie op te slaan. De identiteit van de client is nu iets wat de server op verzoek kan verifiëren vanuit een bron die de client beheert, in plaats van een regel die de server moet aanmaken en onderhouden.

Drie gerelateerde beveiligingsverbeteringen worden tegelijkertijd meegeleverd:

• Issuer-validatie (RFC 9207). Autorisatieservers retourneren de iss parameter en clients moeten deze valideren voordat ze een autorisatiecode inwisselen. Dit dicht een lang bestaand risico op autorisatieserver-persoonsverwisseling.
• Issuer-gebonden credentials. Client-credentials zijn gebonden aan de issuer die ze heeft verstrekt, zodat een token verkregen van de ene autorisatieserver niet kan worden hergebruikt bij een andere.
• Application type. Clients declareren een application_type zodat servers stoppen met het weigeren van localhost redirects voor legitieme desktop- en CLI-tools.

Er is een belangrijk aandachtspunt: het server-side ophalen van een door de client beheerde URL is per definitie een server-side request naar een adres dat door een aanvaller kan worden beïnvloed. CIMD ruilt een registratie-endpoint in voor een SSRF-overweging. Iedereen die dit implementeert, moet dat ophalen van metadata met dezelfde zorg behandelen als elk ander uitgaand request binnen de vertrouwde zone. Onze diepere behandeling van deze risico's vindt u in MCP security risks and best practices, en de mechanica van agent-to-server auth wordt behandeld in MCP authentication explained.

De praktische conclusie: bouw geen nieuwe integraties op DCR. Het is afgeraden, het zal worden verwijderd en het alternatief biedt betere governance. Als u er al afhankelijk van bent, hebt u tot ten minste juli 2027 — maar de migratie is een kwestie van wanneer, niet of.

Transport: Streamable HTTP vervangt HTTP+SSE

Het oude HTTP+SSE transport is officieel afgeraden met een migratieperiode van een jaar. De vervanger, Streamable HTTP, is van nature stateless, en dat enkele woord heeft grote consequenties.

Onder het nieuwe transport is er geen initialize / initialized handshake en geen Mcp-Session-Id. Elk request beschrijft zichzelf: de protocolversie, de identiteit van de client en de capabilities reizen mee in een _meta blok per request, en een optionele server/discover call stelt een server in staat zijn capabilities vooraf bekend te maken. Omdat elk request op zichzelf staat, kan elke serverinstantie elk request verwerken. Hierdoor kunnen servers achter een gewone round-robin loadbalancer staan en horizontaal schalen zonder sticky sessions.

De prijs van statelessness is dat verloren in-flight requests niet worden hervat. Er is geen stream om opnieuw verbinding mee te maken. Een client die een request verliest, moet dit opnieuw indienen met een nieuw ID. Dit betekent dat langlopende tools idempotent moeten zijn of een duurzame handle moeten teruggeven waarop de client kan pollen. State over meerdere calls verdwijnt niet — het moet alleen expliciet worden gemaakt, doorgaans als een door de server uitgegeven handle die als tool-argument wordt doorgegeven en wordt ondersteund door gedeelde opslag met een verlooptijd. Het laten vervallen van sessies op protocolniveau maakt uw applicatie niet stateless; het verplaatst de verantwoordelijkheid voor state van het transport naar u.

Dit is de wijziging die waarschijnlijk elke client raakt die u draait, omdat het de netwerklaag zelf betreft. Als uw agents elk hun eigen MCP-verbindingen openen, heeft ieder van hen het nieuwe transport nodig. Als ze via een gateway gaan, beëindigt de gateway het transport één keer en blijven uw agents communiceren met één stabiel endpoint — wat het hele argument is om agents niet rechtstreeks naar servers te laten communiceren, zoals behandeld in ons artikel over hosting remote MCP servers.

Routing: header-gebaseerde controle is het echte verhaal

De wijziging met de meeste impact voor iedereen die infrastructuur beheert, is de stilste in de changelog. Streamable HTTP vereist nu Mcp-Methodbij elk request en Mcp-Namebijtools/call,resources/readenprompts/get. Een toolparameter kan bovendien worden gemarkeerd met x-mcp-header, en conforme clients spiegelen dat argument naar een Mcp-Param-{Name} header — waarbij een region parameter die wordt gepromoveerd tot een routingheader het canonieke voorbeeld is.

Hiervoor moest een tussenstation dat wilde routen of rate-limiten per tool de JSON-RPC body van elk request openbreken en parse-en. Nu staan de routing-relevante gegevens in headers, waar een gateway, loadbalancer of WAF ze goedkoop kan lezen en erop kan reageren zonder de payload te hoeven begrijpen. U kunt tools/call voor een kostbare tool naar een toegewezen pool sturen, een specifieke tool op naam rate-limiten, of het verkeer van een tenant routen via een region header — allemaal aan de edge.

Er is één regel die niet mag worden overgeslagen: headers en body moeten overeenkomen. Een server die de body verwerkt, moet verifiëren dat de headers hiermee overeenkomen en afwijkingen weigeren met een 400 en foutcode -32020. Elk tussenstation dat een body herschrijft, moet ook de headers herschrijven, of geen van beide — en een gateway mag een header pas vertrouwen nadat deze is gecontroleerd tegen de body. Header-gebaseerde routing is juist krachtig omdat het vroeg in het request-pad wordt vertrouwd, wat precies de reden is waarom het daar gevalideerd moet worden.

Bekijk hoe de TrueFoundry MCP Gateway spec-wijzigingen opvangt zodat uw agents dat nooit hoeven te doen. Boek een demo.

Interactie: elicitatie wordt Multi-Round-Trip

Voorheen voerde een server die halverwege een call invoer nodig had — een elicitatie, een sampling-request, een listing van roots — dit uit over een opengehouden stream. In een stateless wereld is er geen opengehouden stream, dus vervangt de revisie van 2026-07-28 die door de server geïnitieerde calls door Multi-Round-Trip Requests (MRTR). De server retourneert een resultaat van het type input_required dat beschrijft wat er nodig is; de client antwoordt door de oorspronkelijke call opnieuw te proberen met de antwoorden in inputResponses en een requestState blob waarmee de server kan hervatten.

Omdat de retry op een andere serverinstantie kan terechtkomen, moet het hervattingspad op die manier worden getest. Eventuele side-effects die zijn uitgevoerd voordat de invoer werd verzameld, moeten worden gereconcilieerd — MCP biedt geen exactly-once garantie. Daarnaast zijn Roots, Sampling en Logging afgeraden (functioneel voor ten minste twaalf maanden, verwijdering niet eerder dan juli 2027), zijn Tasks verplaatst naar een extensie met een op polling gebaseerd model, en bevatten list/read-responses nuttlMsencacheScopehints zodat tussenstations veilig kunnen cachen. Die caching-hint bevat een valkuil, die hieronder wordt behandeld.

MCP Apps: servers kunnen nu UI meesturen

De release formaliseert ook een extensie-framework, en de extensie die waarschijnlijk het meest relevant is voor productteams is MCP Apps (io.modelcontextprotocol/ui) — interactieve UI-surfaces die worden gerenderd door geschikte hosts. Tot nu toe retourneerde een MCP-server tekst en gestructureerde data; met MCP Apps kan deze een interactieve surface retourneren die een ondersteunende host inline rendert, waardoor een tool-call verandert in iets wat lijkt op een ingebedde mini-applicatie.

Dat is een echt nieuwe functionaliteit en een echt nieuw governance-oppervlak. Een server die UI kan meesturen, kan UI meesturen die vraagt om credentials, die een bevestiging misleidend weergeeft, of die content rendert waarop de host niet had gerekend — dus dezelfde controle die u toepast op de tools van een server moet nu worden uitgebreid naar alles wat deze kan renderen. MCP Apps is een extensie, de volwassenheid ervan wordt afzonderlijk van de kern-spec bijgehouden en de ondersteuning door hosts is wisselend. Behandel het daarom als opkomend in plaats van definitief. Het punt voor een platformteam is eenvoudiger: het aanvals- en beleidsoppervlak van "een MCP-server" is zojuist gegroeid, en de reviews en allowlists die u toepast op tools moeten gereed zijn om op apps te worden toegepast.

Wat dit betekent als u MCP in productie draait

Samen bekeken wijzen de wijzigingen van 2026-07-28 in één richting: het protocol wordt iets wat een tussenstation eenduidig kan beheren. Stateless requests, via headers zichtbare routing-gegevens, expliciete cache-hints en verifieerbare client-identiteit zijn allemaal eenvoudiger af te dwingen op een controlepunt dan een jaar geleden. Dat is het argument om een gateway te plaatsen tussen uw agents en uw MCP-servers, in plaats van ze rechtstreeks aan elkaar te koppelen.

Een gateway is de plek waar het nieuwe transport één keer wordt beëindigd, waar op CIMD gebaseerde auth één keer wordt gevalideerd, waar Mcp-Name routing en rate limits per tool worden afgedwongen, en waar het register van bestaande servers en wie deze mag bereiken daadwerkelijk staat. Wanneer de spec opnieuw wordt gewijzigd — en dat zal gebeuren — veranderen de clients die op de gateway zijn gericht niet; de gateway verandert. De MCP-gateway van TrueFoundry is gebouwd rondom precies dit controlepunt, en het governance-model wordt gedetailleerd beschreven in enterprise MCP governance en in de productdocumentatie.

Als u een centrale MCP-gateway afweegt tegen het laten beheren van eigen servers door elk team afzonderlijk, vindt u de afwegingen in onze best MCP gateways vergelijking. De protocol-versus-protocol vraag waar MCP ophoudt en agent-to-agent messaging begint, wordt behandeld in MCP vs A2A.

Waar teams de mist in gaan

Ze nemen afgeraden primitives over in nieuwe code. DCR, Roots, Sampling en Logging werken nog steeds, dus ze lijken veilig om op te bouwen. Er loopt echter een klok voor hun verwijdering. Nieuwe integraties moeten ze als niet-toegestaan behandelen.

Ze vertrouwen op headers die ze nooit hebben gevalideerd. Header-gebaseerde routing werkt alleen omdat headers worden gelezen vóór de body. Een gateway die routeert op Mcp-Name zonder dit te controleren tegen de body — en afwijkingen te weigeren met 400 / -32020 — heeft een routing-omzeiling gebouwd, geen routing-laag.

Ze markeren tenant-data als cachebaar metpublic. De nieuwe cacheScope hint is nuttig maar gevaarlijk. Een principal- of tenant-specifiek resultaat dat is gemarkeerd als public kan door een tussenstation worden geserveerd aan de verkeerde autorisatiecontext. Responses op tenant-niveau mogen nooit public zijn.

Ze nemen aan dat stateless betekent dat er geen state is. Statelessness is hoger in de stack komen te liggen, het is niet verdwenen. Als een tool state had over meerdere calls, heeft die state nu een expliciete handle en duurzame opslag nodig — anders gaat het stilzwijgend mis wanneer een retry op een andere instantie terechtkomt.

Ze migreren per client in plaats van aan de edge. Het handmatig uitrollen van het nieuwe transport naar elke agent, SDK en script is de trage, foutgevoelige weg. Het eenmalig beëindigen bij een gateway is de snelle weg.

Een checklist voor migratie

De volgorde die uitval minimaliseert is ongeveer: stop de uitbreiding van afgeraden onderdelen, pas de netwerklaag aan en benut vervolgens de nieuwe routing.

Conclusie

De specificatie van 2026-07-28 is geen verzameling losse functies; het is een herziening van de architectuur. DCR maakt plaats voor CIMD, HTTP+SSE maakt plaats voor stateless Streamable HTTP, routing verhuist naar headers, elicitatie wordt multi-round-trip en servers krijgen de mogelijkheid om UI mee te sturen. Elke wijziging is op zichzelf logisch, en samen duwen ze MCP richting iets wat een tussenstation eenduidig kan beheren — mits iemand dat tussenstation beheert.

Dat is de stille conclusie van de gehele release. De spec beweegt naar een wereld waarin een controlepunt voor uw MCP-servers geen optionele luxe is, maar de natuurlijke plek voor transport-, auth-, routing- en caching-beleid. Richt dat controlepunt één keer in, en de volgende revisie is een configuratiewijziging in plaats van een migratie voor al uw systemen.

Plaats een controlepunt voor uw MCP-servers voordat de volgende spec-revisie verschijnt. Boek een demo.