MCP 2026-07-28: protokollen blir stateless og klar for store virksomheter

28. juli fikk Model Context Protocol sin største oppdatering siden lanseringen. Den nye versjonen, som er oppkalt etter datoen, 2026-07-28, endrer hvordan MCP fungerer helt i bunnen. Protokollen er ikke lenger avhengig av sessions, og det gjør det langt enklere å kjøre MCP-servere slik andre webtjenester kjøres.

Hva som endres

MCP blir stateless. Hittil har en klient måttet åpne en session med en server gjennom en handshake, og serveren har måttet huske den. I den nye versjonen har hver forespørsel med seg det serveren trenger, blant annet identiteten og egenskapene til klienten. Alle serverinstanser bak en load balancer kan derfor svare på alle forespørsler, uten sticky sessions eller et felles lager for sessiondata. Informasjon om routing legges også i HTTP-headere, der gatewayer og load balancere kan lese den.

Autorisasjon strammes inn. Spesifikasjonen følger OAuth 2.1 og OpenID Connect tettere, og krever issuer validation for å stoppe såkalte mix-up-angrep, der et token fra én autorisasjonsserver brukes mot en annen. En ny utvidelse, Enterprise-Managed Authorization, lar IT gi tilgang til MCP-servere sentralt gjennom identity provider i virksomheten.

Utvidelser får sitt eget spor. Funksjoner som MCP Apps, som lar servere vise interaktive grensesnitt i chat-klienter, og Tasks, for jobber som tar lang tid, er nå utvidelser som kan utvikles i sitt eget tempo utenfor kjernen.

Funksjoner fases ut med varsel. Sampling, roots, innebygd logging, dynamic client registration og den gamle transporten med HTTP og SSE er merket som deprecated. En ny regel krever minst 12 måneders varsel før en funksjon fjernes, så ingenting forsvinner før juli 2027.

Hvorfor det betyr noe

For integrasjonsplattformer er overgangen til stateless den viktigste endringen. En iPaaS som tilbyr hundrevis av integrasjoner som MCP-verktøy, må kunne skalere dem som alle andre API-er: mange instanser, automatisk omstart og en load balancer foran. Med sessions var det mulig, men tungvint. Den Delimarsky, som leder vedlikeholdet av protokollen, sa til VentureBeat at en pod som feilet før betydde forespørsler som feilet, og at det ikke lenger er et problem.

Regelen om varsel før utfasing betyr like mye for store virksomheter. En protokoll som kan endres uten varsel, er vanskelig å bygge på. Tolv måneders varsel er den typen løfte enterprise-arkitekter trenger før de standardiserer på noe.

Hva det koster

Endringen er ikke gratis. David Soria Parra fra Anthropic, en av dem som laget MCP, sa til The Register at team som har laget sin egen implementasjon, har mye arbeid foran seg for å få den riktig. Klienter og servere må også støtte en felles versjon, ellers må én av sidene oversette. En stund vil mange virksomheter kjøre gammel og ny MCP side om side.

Hva du bør spørre om

1. Når støtter plattformen deres 2026-07-28? Be leverandørene av iPaaS og gatewayer om en dato, både for MCP-serverne og MCP gatewayen deres.
2. Har dere egen MCP-kode? Finn MCP-serverne og klientene teamene deres har laget selv, og planlegg migreringen før de gamle funksjonene fjernes.
3. Kan IT styre tilgangen sentralt? Sjekk om identity provider og MCP-klientene deres støtter Enterprise-Managed Authorization.