MCP-spesifikasjonen dropper sesjonene: nå skalerer den på vanlig HTTP
Oppgrader MCP-serveren din til 2026-07-28-spesifikasjonen hvis den kjører bak en lastbalanserer, for sesjons-IDen som låste klienten til én pod er fjernet fra protokollen.
Google Cloud skriver på utviklerbloggen sin at selskapet ledet arbeidet med å fjerne sesjonshåndtering fra Model Context Protocol, gjennom MCP Transports Working Group som Google stiftet sammen med Hugging Face og andre bransjepartnere. Resultatet er spesifikasjonsversjon 2026-07-28, der både initialize-håndtrykket (SEP-2575) og Mcp-Session-Id-headeren (SEP-2567) er strøket helt. Endringsloggen til spesifikasjonen bekrefter at også tools/list, resources/list og prompts/list nå gir samme svar uansett tilkobling.
Slik fungerte det før: serveren svarte på initialize med en Mcp-Session-Id, og klienten måtte sende den IDen på hvert eneste påfølgende kall. Det pinnet klienten til akkurat den containeren som holdt sesjonstilstanden i minnet. Rullerte du poden, skalerte ned eller mistet en node, fikk klienten 400 Session Not Found. Google beskriver hva som skjedde da de forsøkte å kjøre dette på egen infrastruktur.
«Den var bygget på tilstandsfulle transporter som brøt med grunnprinsippene for moderne skyskalering» — Google Cloud, utviklerbloggen
I den nye modellen er hvert kall selvbeskrivende. Protokollversjon, klientinfo og klientkapabiliteter reiser med i et _meta-felt på hver forespørsel i stedet for å utveksles én gang ved oppkobling. Samtidig løftes tre verdier opp som vanlige HTTP-headere (Mcp-Protocol-Version, Mcp-Method og Mcp-Name), slik at proxyer, gatewayer og lastbalanserere kan rute, rate-limite og logge trafikken uten å pakke opp JSON-kroppen. Er header og kropp uenige, avviser serveren kallet med feilkode -32020.
To mekanismer erstatter det sesjonene løste. Trenger serveren et svar fra brukeren midt i et verktøykall, returnerer den nå et InputRequiredResult med et serialisert requestState i stedet for å holde en SSE-tilkobling åpen, og klienten sender tilstanden tilbake når svaret foreligger. Da kan hvilken som helst instans bak lastbalansereren plukke opp tråden. For kall som tar 10 til 60 sekunder, som en databasedump eller en betalingsrefusjon, gir Tasks-utvidelsen deg en taskId med en gang og kjører jobben i bakgrunnen. Verktøy- og ressurssvar kan i tillegg merkes med ttlMs og cacheScope, så klienten vet hvor lenge en verktøyliste er fersk uten å abonnere på endringer.
Simon Willison, som bygde tre klienter og servere på protokollen samme uke som den kom, peker på at den lavere implementasjonsterskelen er poenget for de som bygger selv.
«Dette er den mest betydningsfulle endringen i MCP-spesifikasjonen siden den ble lansert, og den har gjenopplivet min egen interesse for protokollen» — Simon Willison
Willison legger til et argument som treffer hjemmelab-bruken: å gi en agent et skall med internettilgang krever en sterk modell og bærer mye risiko, mens MCP-verktøy er lettere å revidere og enkle nok til at små modeller på en laptop klarer å styre dem.
Hva bør du gjøre?
- Sjekk om serveren din fortsatt svarer med
Mcp-Session-Id. Gjør den det, kjører du 2025-11-25-transporten, og klientene dine er pinnet til enkeltinstanser. - Flytt tilstand du faktisk trenger ut av protokollen og inn i eksplisitte handles som serveren utsteder og klienten sender som vanlige verktøyargumenter. Det er mønsteret spesifikasjonen nå peker på.
- Sett
ttlMspå verktøylistene dine før du skrur av SSE-tilkoblingene, ellers spør klientene like ofte som før.
KI-kuratert — innholdet er generert av KI-agenter basert på originalkilden.