MCP-veikartet: HTTP over stdio og egen identitet for agenter

Siden spesifikasjonsutgivelsen 28. juli 2026 har en ekstern MCP-server vært en helt vanlig HTTP-arbeidslast som kan driftes på samme infrastruktur som resten av API-ene dine. De lokale serverne ble liggende igjen på stdio, og det gapet er utgangspunktet for veikartet Core Maintainers i Model Context Protocol oppdaterte 22. august. Veikartsiden organiserer arbeidet i fem prioriterte områder og navngir vedlikeholderne som er ansvarlige for hvert av dem.

Det mest konkrete for lokale oppsett heter HTTP over stdio. Transports-arbeidsgruppen, med Kurtis Van Gent og Nick Cooper som ansvarlige Core Maintainers, vil gjøre Streamable HTTP til den eneste bindingen og la den snakkes over stdin og stdout. Vedlikeholderne skriver at de tror HTTP/2 over stdio kan gi multiplekset HTTP-transport uten å miste sikkerhets- og livssyklusgarantiene en underprosess gir. Begrunnelsen i veikartet er at hver HTTP-native funksjon i dag krever en ekstra stdio-spesifikk design eller ikke virker lokalt, at SDK-ene vedlikeholder to transportrørledninger, og at protokollmetadata nå ligger duplisert i både HTTP-headere og meldingsfelt som serveren må krysstjekke.

Område tre handler om hvem som ringer på.

«MCP-autorisasjon forutsetter en person med nettleser i samtykkeøyeblikket» — Veikartet, oppdatert 22. august 2026

Kallene kommer i økende grad fra agenter: skyarbeidslaster med egen identitet, agenter som handler for en bruker som ikke er til stede, eller agenter som spinner opp underagenter med smalere fullmakter enn forelderen. Dagens servere lener seg på innlimte API-nøkler og langlevde refresh-tokens. Paul Carleton og Den Delimarsky er ansvarlige for området, der arbeidsgruppen for agent-identitet skal ferdigstille Demonstrating Proof of Possession og peke ut en tydelig anbefalt vei for agent-identitet gjennom Workload Identity Federation (SEP-1933), ID-JAG-grantet bak Enterprise-Managed Authorization og token exchange etter RFC 8693.

Den fjerde prioriteringen er den mange kjenner på i praksis: verktøykataloger som eser ut. Svaret er gradvis oppdagelse, der klienten lærer serverens verktøy og ressurser etter hvert som den trenger dem i stedet for å svelge hele katalogen på forhånd. Samme område skal også rydde i returverdiene.

«tools/call tillater å returnere både content og structuredContent samtidig, noe som har forvirret både server- og klientforfattere og produsert divergerende implementasjoner» — Veikartet, oppdatert 22. august 2026

Veikartet er eksplisitt på at det beskriver dagens tenkning, ikke faste forpliktelser: prioriteringer kan endre seg, punkter kan bli levert annerledes enn beskrevet eller utsatt, og arbeid som ikke står oppført kan likevel havne i utgivelsen. Det har likevel en konsekvens allerede nå. Forslag som faller innenfor de fem områdene får ekspressbehandling i SEP-prosessen, mens de utenfor må regne med en lengre kø og et høyere krav til begrunnelse.

Hva bør du gjøre?

1. Bygger du en lokal MCP-server: regn med at stdio-spesifikk kode blir midlertidig, og hold transportlaget adskilt fra verktøylogikken.
2. Har serveren din mange verktøy: se på gradvis oppdagelse nå. Caching-arbeidet i transportområdet bygger videre på ttlMs og cacheScope fra SEP-2549, og skal utvides med ETags slik at resultatene av verktøykall kan versjoneres.
3. Skal du sende inn en SEP: plasser den i ett av de fem områdene, ta den opp med den relevante arbeidsgruppen først og ta med gruppas støtte i forslaget.