MCP dropper sesjoner: initialize-håndtrykket og Mcp-Session-Id forsvinner i 2026-07-28

Model Context Protocol-bloggen la ut release candidate for revisjonen 2026-07-28 mandag kveld, og den endelige spesifikasjonen låses tirsdag 28. juli. Prosjektet kaller det den største revisjonen siden lanseringen i 2024, og den inneholder brytende endringer. Seks Specification Enhancement Proposals (SEP-er) står bak hovedgrepet: protokollen er nå statsløs på transportnivå. Håndtrykket initialize/initialized er fjernet (SEP-2575), og det samme er Mcp-Session-Id-headeren (SEP-2567). Protokollversjon, klientinfo og capabilities som før ble utvekslet én gang ved oppkobling, følger nå med i _meta på hver eneste forespørsel, mens en ny server/discover-metode henter serverens capabilities når klienten trenger dem på forhånd.

Grepet retter seg mot et driftsproblem som vokste fram da MCP-servere flyttet fra utviklerlaptopen til skyen. En ekstern server som før krevde sticky sessions, delt sesjonslager og pakkeinspeksjon i gatewayen, kan nå kjøre bak en helt vanlig round robin-lastbalanserer, rute trafikk på den nye Mcp-Method-headeren (SEP-2243) og la klientene cache tools/list-svar så lenge serverens ttlMs tillater det (SEP-2549).

«Sesjonsmodellen ga mening da MCP-servere var lokale prosesser på en utviklers laptop. I produksjon ble den en driftsskatt.» — Muskan Bandta, cloud associate i ZopDev, til InfoWorld

Tilstanden forsvinner ikke, den flytter seg. Servere som må huske noe på tvers av kall, skal nå gjøre det HTTP-APIer alltid har gjort: dele ut en eksplisitt nøkkel, en basket_id eller en browser_id, og la modellen sende den tilbake som et helt vanlig argument i neste verktøykall. MCP-teamet argumenterer for at dette er bedre enn den gamle løsningen, fordi modellen kan sette sammen og resonnere om nøkler den faktisk ser, i stedet for tilstand som lå gjemt i transportmetadata.

«Protokollen håndterer ikke lenger den tilstanden for deg, men den hindrer deg ikke i å håndtere den selv.» — Model Context Protocol-bloggen

Serverinitierte forespørsler er bygget om for å overleve uten en åpen forbindelse. En server som trenger et svar fra brukeren midt i et kall, returnerer nå et InputRequiredResult med en requestState-blob i stedet for å holde en SSE-strøm åpen. Klienten samler inn svarene og sender hele det opprinnelige kallet på nytt, og da kan en hvilken som helst instans plukke det opp.

Utvidelser blir samtidig førsteklasses (SEP-2133), med reverse-DNS-navn, egne repoer og egen versjonering uavhengig av spesifikasjonen. To offisielle utvidelser følger med. MCP Apps (SEP-1865) lar servere sende interaktivt HTML som verten rendrer i en sandkasset iframe, der maler deklareres på forhånd så verten rekker å hente, cache og sikkerhetsvurdere dem. Tasks flyttes ut av kjernen etter at produksjonsbruk avdekket behov for redesign, og tasks/list er fjernet fordi den ikke kan avgrenses trygt uten sesjoner. Har du bygget mot den eksperimentelle Tasks-APIen fra 2025-11-25, venter en migrering.

Autorisasjonsdelen strammes til av seks SEP-er. Klienter må nå validere iss-parameteren i autorisasjonssvar etter RFC 9207 (SEP-2468), et billig mottiltak mot mix-up-angrep som treffer MCPs mønster med én klient og mange servere ekstra hardt.

Joab Jackson i The Register oppsummerer prisen: overhalingen kutter lite brukte funksjoner og etterlater hjemmesnekrede implementasjoner med en tung jobb. Bruker du et offisielt SDK, kommer det meste som en oppgradering. Har du skrevet transportlaget selv, er dette den revisjonen som brekker det.

Hva bør du gjøre?

1. Finn ut om serveren din er håndrullet eller SDK-basert. Egne HTTP-transportlag må rydde bort håndtrykket og Mcp-Session-Id, og begynne å lese _meta på hver eneste forespørsel.
2. Flytt sesjonstilstanden over i eksplisitte handles i verktøysignaturene før du migrerer, ikke etter. Da slipper du å holde to tilstandsmodeller i live samtidig.
3. Legg ttlMs og cacheScope på listesvarene med en gang. Det er den billigste gevinsten i hele revisjonen, og den kutter trafikk uten at klientene må gjøre noe.