MCP is gebouwd voor een mens achter een laptop. De roadmap van 2026 haalt die mens eruit

De vier aannames waarop MCP is gebouwd — iemand die op Toestaan klikt, iemand die een paar seconden wacht, een toolcatalogus die kort genoeg is om te lezen, een subproces op de laptop van die persoon — naast de roadmapitems van 2026 die elk daarvan vervangen: agent-identiteit en DPoP, tasks en server-events, progressive discovery en HTTP over stdio — Geen van deze punten is een nieuwe feature. Elk punt markeert een plek waar het protocol uitging van een mens, en waar productie ontdekte dat die er niet was.

De roadmap van het Model Context Protocol is bijgewerkt op 22 augustus 2026, en in het derde prioriteitsgebied staat de meest verhelderende zin die dit jaar over agent-infrastructuur is geschreven:

MCP-autorisatie gaat ervan uit dat er een mens met een browser klaarzit op het moment van toestemming.

Lees de andere vier prioriteitsgebieden na die zin en ze zien er niet langer uit als een featurelijst. Het is één project met vijf fronten: het protocol is ontworpen voor iemand achter een laptop, en productie ontdekt keer op keer dat daar niemand zit.

Die herkadering is een middag aandacht waard, want elk punt op de roadmap is iets wat je nu met de hand oplost — meestal slecht, en meestal zonder te merken dat je een beslissing nam.

1. De vijf prioriteitsgebieden, en wat ze werkelijk zijn

De roadmap is er duidelijk over dat dit een prioriteringsdocument is en geen releaseplanning: SEP's — Specification Enhancement Proposals — die binnen deze gebieden vallen "krijgen versnelde review en maken de meeste kans te worden geaccepteerd". De rest wacht.

De vijf gebieden, en de menselijke aanname die elk gebied schrapt

Prioriteitsgebieden op de roadmap van 2026

Agentic messaging primitives — gingen ervan uit dat iemand een paar seconden op antwoord wachtte. Tasks, subscriptions en voortgangsmeldingen moeten nu samenkomen in één levenscyclus.
HTTP-native transport unification — ging uit van een subproces op de machine van die persoon. Het doel is één transportmodel, waarbij stdio HTTP wordt dat over stdin/stdout wordt gesproken.
Agent-identiteit en enterprise-security — ging uit van het toestemmingsscherm in de browser. De aanroeper is nu een cloudworkload met een eigen identiteit, handelend namens een afwezige gebruiker.
Verbeterde primitives — gingen uit van een catalogus die kort genoeg was om in één keer te lezen, en van een tools/call-resultaatvorm die iedereen hetzelfde zou uitleggen. Geen van beide hield stand.
Betere SDK-ervaring — ging ervan uit dat handmatig onderhouden SDK's het tempo van de specificatie konden bijhouden. Het experiment is ze uit de specificatie genereren.

De eerste vier zijn architectuur. De vijfde gaat over hoe de andere vier bij jou terechtkomen, en dat telt zwaarder dan het klinkt: het is het verschil tussen een specificatiewijziging die in weken in je SDK landt en een die er maanden over doet.

2. Wat al is uitgebracht, en je misschien nu al raakt

Vóór de roadmap was er een release. De specificatie van 2026-07-28 maakte de kern van het protocol stateless, en dat is de wijziging die het meest waarschijnlijk een systeem raakt dat je vandaag draait.

Concreet verdwenen de initialize/initialized-handshake en de Mcp-Session-Id-header. Elk request draagt nu zijn eigen protocolversie, clientidentiteit en capabilities in _meta. Het gevolg, in de bewoording van de specificatie zelf: elk request kan op elke serverinstantie landen achter een gewone round-robin loadbalancer, zonder gedeelde opslag.

Waarom een founder om een geschrapte handshake zou moeten geven

Stateful sessies vechten met loadbalancers. Draaide je een remote MCP-server op meer dan één instantie, dan pinde je sessies vast, deelde je state via Redis, of draaide je stilletjes op één machine en hoopte je er het beste van. Alle drie zijn workarounds voor een aanname die nu uit het protocol is gehaald. Heb je zo'n workaround gebouwd, dan is dat nu ballast in plaats van noodzakelijke complexiteit — en die kun je beter bewust weggooien dan meeslepen naar je volgende project.

Drie andere dingen uit dezelfde release worden makkelijk over het hoofd gezien en zijn meteen bruikbaar:

Bevestigingen midden in een call, zonder open verbinding

SEP-2322

Multi round-trip requests vervangen server-initiated requests die een openstaande stream nodig hadden. De server geeft resultType: "input_required" terug, de client herhaalt de oorspronkelijke call met antwoorden in inputResponses. Menselijke goedkeuring, zonder dat de verbinding de state draagt.

Routeren zonder de body te lezen

SEP-2243

Requests dragen nu de HTTP-headers Mcp-Method en Mcp-Name, zodat gateways, ratelimiters en WAF's kunnen routeren en meten op headers in plaats van JSON uit te pakken. Wilde je ooit ratelimits per tool aan de rand, dan is dit het haakje dat ontbrak.

Lijstresultaten die je mág cachen

SEP-2549

ttlMs en cacheScope op lijstresultaten en resource-reads. Klein veld, grote rekening: het verschil tussen de toolcatalogus elke sessie opnieuw ophalen en hem ophalen als hij verandert.

Autorisatie die de issuer controleert

RFC 9207

Issuer-validatie vóór het inwisselen van de code, en een verschuiving van Dynamic Client Registration naar Client ID Metadata Documents als voorkeursroute. Weinig spectaculair, en precies het soort wijziging dat stilletjes een hele klasse token-substitutieaanvallen dichtzet.

3. Progressive discovery is eerst een kostenverhaal, pas daarna architectuur

Van alles op de roadmap is dit het punt dat founders als eerste voelen, en het punt dat het vaakst wordt weggezet als luxe.

De roadmap stelt dat servers "meer mogelijkheden nodig hebben om clients door grote verzamelingen tools te leiden", en dat clients "de tools en resources van een server moeten leren kennen wanneer ze die nodig hebben, in plaats van de volledige catalogus vooraf te slikken".

Waarom dat een regel op je factuur is: nu gaat de toolcatalogus aan het begin van de sessie het contextvenster in. Alle tools. Alle beschrijvingen. Alle parameterschema's. Bij elke taak. Koppel vier of vijf serieuze MCP-servers en je geeft duizenden tokens uit voordat het model de eerste zin van de gebruiker heeft gelezen — en je betaalt het opnieuw bij de volgende taak, en de taak daarna.

Dit is dezelfde fout als een te uitgebreide AGENTS.md, via een andere deur: content die onvoorwaardelijk wordt geladen, of de taak hem nodig heeft of niet. De oplossing is in beide gevallen dezelfde — laden voorwaardelijk maken — en bij slechts één van de twee bouwt een werkgroep het mechanisme voor je.

Daaruit volgen twee dingen. Zolang progressive discovery niet bestaat is het aantal MCP-servers dat je koppelt een directe kostenbeslissing, geen capaciteitsbeslissing, en is de juiste default minder servers met smallere toolsets. En zodra het er is, profiteren de servers waarvan de tools zijn geordend tot iets wat een client kan doorlopen — een ontwerpkeuze die je nu al kunt maken, in hoe je tools groepeert en benoemt, voordat er enig mechanisme bestaat.

De roadmap merkt ook op dat progressive discovery een "gedefinieerde interactie met het cachewerk" heeft: discovery en TTL-caching worden ontworpen om samen te werken in plaats van te botsen. Dat soort detail bepaalt of een feature bruikbaar is in jaar één of pas in jaar drie.

4. Agent-identiteit: de geplakte API-sleutel is nu een roadmapitem

Het derde prioriteitsgebied benoemt het probleem hardop. Zo beschrijft de roadmap de huidige stand:

Bestaande MCP-servers leunen op geplakte API-sleutels en langlevende refresh tokens.

Dat is een accurate beschrijving van vrijwel elk agentsysteem dat nu in productie draait, inclusief een hoop systemen die zichzelf veilig zouden noemen. Wat daartegenover wordt geprioriteerd:

Wat er wordt gestandaardiseerd, en wat het vervangt

Werkgroep agent-identiteit, in oprichting deze roadmapperiode

DPoP — Demonstrating Proof of Possession. Bindt een token aan een sleutel die de client bezit, zodat een gestolen token op zichzelf niets waard is. Vervangt: een bearer token dat werkt voor iedereen die het heeft.
Workload Identity Federation (SEP-1933) — een agent die zich authenticeert als zichzelf, als cloudworkload, en niet met de gekopieerde credential van een mens. Vervangt: het serviceaccount waarvan de sleutel in een omgevingsvariabele staat.
ID-JAG en token exchange volgens RFC 8693 — een standaardmanier om te handelen namens een afwezige gebruiker, en om een subagent minder rechten te geven dan zijn parent. Vervangt: subagents die de volledige credential erven omdat niemand een manier bouwde om die te versmallen.
Human-presence attestation — in bespreking, niet toegezegd. Onderscheid maken tussen een interactieve client en een headless agent, precies de vraag waar elke ratelimiter en elk fraudesysteem nu naar raadt.

De delegatiekant verdient nadruk, want die raakt een echte architectuurfout. Als een agent nu een subagent start, draait die vrijwel altijd met de credentials van de parent, omdat versmallen machinerie vereist die niemand heeft gebouwd. Dat betekent dat de blast radius van de minst betrouwbare stap in je keten de blast radius van de hele keten is. Dat is het mechanisme, niet een hypothese — en het is dezelfde conclusie die we vanuit de andere kant trokken in AI-agents hebben permissiesystemen nodig, geen betere prompts.

Eén waarschuwing, dezelfde als bij de protocolconsolidatie die we vorige week behandelden: identiteit beantwoordt wie er belt. Niet of wat er gevraagd wordt een goed idee is. Een perfect geauthenticeerde agent die een kwaadaardige instructie van een webpagina heeft gelezen, doet zijn kwaadaardige call met onberispelijke credentials. Alles in de security-gids voor agents over het behandelen van modelzichtbare content als onbetrouwbaar blijft onverkort gelden.

5. Hoe je een roadmap leest als je over acht weken live gaat

Een roadmap is geen opleverdatum. Het document zegt het zelf: "het huidige denken en geen harde toezeggingen", met een horizon van zes tot twaalf maanden. Voor twee van de vijf gebieden worden de werkgroepen nog opgericht.

De nuttige vraag is dus niet waarop je moet wachten. Het is wat dit je vertelt over waar de naden horen te zitten.

Alles wat al uit is

Overnemen

Stateless kern, header-routering, lijstcaching, issuer-validatie. Dat staat in de specificatie van 2026-07-28, niet op een roadmap. Neem het over, en gooi de workarounds weg die het vervangt.

Identiteit, langlopend werk, discovery

Zelf bouwen, wel isoleren

Hier kun je niet op wachten en dat moet je ook niet proberen. Bouw de grove versie — een token per agent, een jobtabel voor alles boven dertig seconden, een handmatig samengestelde toollijst — achter een interface die smal genoeg is om vervanging een dag te laten kosten in plaats van een kwartaal.

Wat de specificatie actief herontwerpt

Niet bouwen

De resultaatvorm van tools/call wordt herzien omdat content en structuredContent uiteenlopende implementaties opleverden. Investeer niet in slimme afhandeling van een vorm die op de wijzigingslijst staat.

De middelste kaart draagt het gewicht. Alles in de eerste vier prioriteitsgebieden is iets wat een team dat nu bouwt informeel oplost. De waarde van de roadmap voor een founder is dat hij vertelt welke van je informele oplossingen tijdelijk zijn by design — en dat zijn precies de oplossingen die een interface verdienen in plaats van uitgesmeerd te worden over de codebase.

Concreet, voor een team dat dit kwartaal een agentproduct bouwt: als je credentialafhandeling, je afhandeling van lange taken en het samenstellen van je toolcatalogus elk op één plek staan met een klein oppervlak, neem je de standaarden over zodra ze in je SDK landen en is dat een non-event. Zitten ze verspreid over de aanroepen, dan neem je ze niet over — en noem je dat een prioriteringskeuze.

6. Wat de roadmap niet oplost

Drie dingen die je expliciet moet benoemen, want een goed geschreven roadmap wekt lichte schijn van volledigheid.

Hij maakt agents niet betrouwbaar. Alles hierin is transport, identiteit en discovery. Niets raakt de vraag of het model de juiste tool koos, het resultaat goed las, of had moeten stoppen. Dat blijft een evaluatieprobleem, en dat blijft van jou.

Hij maakt je afhankelijkheidsketen niet korter. Een stateless kern en één transportmodel maken het makkelijker om meer servers te koppelen. Makkelijk is niet gratis: elke gekoppelde server is contextkosten, een faalmodus en een vertrouwensgrens. Dat het protocol beter wordt in verbindingen is geen argument voor meer verbindingen.

Hij komt niet volgens een planning waarop je kunt sturen. Twee werkgroepen worden nog opgericht. Tasks zijn nog een extensie op weg naar "uiteindelijke opname in het kernprotocol". Verstandig plannen betekent elk roadmapitem behandelen als iets wat volgend jaar in je SDK kán landen, en bouwen alsof het niet gebeurt.

De eerlijke samenvatting

De MCP-roadmap van 22 augustus is een beter strategiedocument dan de meeste bedrijven over zichzelf schrijven, omdat hij zijn eigen foute aanname in gewone taal benoemt in plaats van de oplossing als innovatie te verkopen. Het protocol is gebouwd voor een mens met een browser, op een laptop, die een paar seconden wacht op antwoord van een handvol tools. Alle vier die aannames zijn in productie inmiddels onwaar, en de roadmap is het werk om ze terug te draaien.

Voor een founder zit de praktische inhoud niet in de featurelijst. Het is de bevestiging dat vier dingen waar je nu omheen werkt — credentials voor afwezige gebruikers, werk dat een request overleeft, catalogi die te groot zijn om te laden, en een transport dat zich op een laptop anders gedraagt dan in een cluster — tijdelijk zijn by design, in handen van mensen met naam en toenaam, en het waard zijn om er vandaag een interface omheen te zetten.

Bouw de grove versie. Houd de naad. Gooi de workarounds weg die al een standaard hebben.

Bronnen: Model Context Protocol — roadmap, bijgewerkt op 2026-08-22 · De specificatie van 2026-07-28, MCP-blog · SEP-2575, stateless MCP · SEP-2549, TTL voor lijstresultaten · SEP-2663, tasks-extensie · Werk- en interessegroepen

A2A trok net in bij MCP. Standaardiseren hoe agents praten is niet standaardiseren of ze gelijk hebben20 augustus 2026

Your AI Agent Has a Security Problem: A Founder's Security Guide for 2026July 17, 2026

Context Engineering: The Skill That Makes or Breaks AI MVPs in 2026April 2026

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →