Modelkontekstprotokollen har nådd en stor infrastrukturmilepæl: revisjonen fra 2026-07-28 flytter protokollen mot en statsløs kjerne. For team som bygger agentsystemer, verktøyservere, IDE-integrasjoner eller orkestreringslag med flere modeller, er dette ikke en kosmetisk spesifikasjonsoppdatering. Den endrer antakelser om økter, initialisering, skalering, kompatibilitet og styring.
MCP-utgivelseskandidaten beskrev spesifikasjonen for 28. juli som å legge til en statsløs protokollkjerne, et utvidelsesrammeverk, oppgaver, MCP-apper, autorisasjonsforsterking og en formell avskrivningspolicy. Den offisielle MCP-bloggen advarte også om at utgivelsen inneholder brytende endringer. GitHub, som driver en av de mest synlige MCP-serverimplementeringene, sa i forkant av den endelige utgivelsen at MCP-serveren allerede støttet den nye spesifikasjonen og beskrev protokollen som «å gå statsløs» 28. juli.
Den praktiske betydningen er enkel: MCP blir mindre formet som et økttungt lokalt integreringslag og mer som en protokoll for ekstern verktøyskala. Det betyr noe fordi agentsystemer ikke lenger er begrenset til skrivebordsutviklerverktøy. De kjører i økende grad innenfor skytjenester, CI-systemer, arbeidsflyter for kundestøtte, problemsporere og bedriftsautomatiseringsplattformer.
Hva endret seg i MCP
Overskriftsendringen er overgangen til en statsløs protokollkjerne. GitHubs endringslogg sier at den nye kjernen fjerner økter og initialiserer, med målet om å gjøre eksterne MCP-distribusjoner enklere å skalere. Det er et betydelig arkitektonisk skifte. Stateful protokoller kan fungere godt for lokale verktøy og kontrollerte miljøer, men de kompliserer horisontal skalering, serverløs kjøring, failover, edge-distribusjon og lastbalansering.
En statsløs kjerne gir implementere større frihet til å kjøre MCP-servere bak vanlig nettinfrastruktur. Forespørsler kan distribueres på tvers av forekomster uten å bevare en langvarig økt på en bestemt backend. For store organisasjoner kan det redusere operasjonell kompleksitet. For mindre team kan det gjøre vertsbaserte MCP-servere enklere å distribuere ved å bruke administrert databehandling i stedet for tilpasset langvarig infrastruktur.
Den bredere 2026-07-28-utgivelsen introduserer også et utvidelsesrammeverk og oppgaver, i henhold til utgivelseskandidatmaterialet. Disse tilleggene antyder at MCP blir mer modulært og mer eksplisitt om langvarig arbeid. MCP-apper og autorisasjonsherding peker i samme retning: protokollen modnes fra tidlig økosystemlim til et mer formelt lag for interaksjon mellom agent og verktøy.
Kostnadene ved denne modningen er kompatibilitetsarbeid. MCP-bloggen karakteriserte utgivelsen som en med brytende endringer, og TypeScript- og C# SDK-materialene publisert rundt revisjonen fokuserer på migrasjonsstøtte og statsløse konsepter. Ethvert team som driver en MCP-server, bygger inn MCP i en IDE-utvidelse eller ruter agentanrop gjennom intern infrastruktur bør behandle revisjonen som en ingeniørhendelse i stedet for en bakgrunnsstandardoppdatering.
Hvorfor statsløs MCP er viktig for utviklere og operatører
Agentverktøy har et skaleringsproblem som ser annerledes ut enn vanlig API-skalering. En enkelt brukerforespørsel kan utløse mange verktøykall, modellvendinger, gjenforsøk, fillesing, søk og godkjenningstrinn. Når verktøyprotokollen forutsetter varige økter, må produksjonsoperatører bevare tilstanden på tvers av disse interaksjonene eller bygge løsninger rundt protokollen.
Ved å fjerne økter fra kjernen, passer MCP bedre til miljøer der agentarbeidsbelastninger er sprukket, distribuert og asynkrone. Serverløse funksjoner, kantarbeidere, Kubernetes-distribusjoner og multi-region-systemer har alle fordeler når forespørsler kan håndteres uavhengig. Det eliminerer ikke staten fra agentapplikasjoner; den flytter tilstand til applikasjonsdatabaser, oppgavekøer, identitetssystemer eller eksplisitte arbeidsflytlag i stedet for å bygge den inn i protokollkjernen.
For utviklere bør endringen til slutt gjøre eksterne verktøyservere enklere å konsumere. For plattformteam kan det forenkle observerbarhet og kapasitetsplanlegging. I stedet for å feilsøke ugjennomsiktig sesjonstilhørighet, kan operatører fokusere på sporing på forespørselsnivå, ventetid for verktøyanrop, autorisasjonsbeslutninger og feilmønstre.
Det er også en styringsvinkel. Etter hvert som MCP blir mer vanlig i kodeassistenter og bedriftsagenter, vil bedrifter trenge retningslinjer rundt hvilke verktøy agenter kan ringe, hvilke data de har tilgang til og hvilke brukere eller tjenester som har lov til å påkalle dem. Autorisasjonsherding i den nye revisjonen er derfor ikke tilfeldig.Det gjenspeiler realiteten at verktøytilgang nå er en sikkerhetsgrense, ikke bare en bekvemmelighet for utviklere.
Hvem er berørt
De mest direkte berørte gruppene er MCP-servervedlikeholdere, SDK-brukere, agentplattformteam og organisasjoner som eksponerer interne verktøy for AI-agenter. Hvis en server er avhengig av sesjonsatferd eller eldre initialiseringsflyter, må den testes mot den nye spesifikasjonen. Hvis en applikasjon støtter flere MCP-versjoner, kan den trenge versjonsforhandling, kompatibilitetslag eller en faset migreringsplan.
IDE- og utviklerverktøy-leverandører er også i omfang. MCP vises i økende grad sammen med kodeagenter, tilpassede agenter og modelladministrasjonsfunksjoner. En statsløs protokollkjerne gjør det enklere for disse produktene å kalle eksterne verktøy pålitelig, men bare hvis integrasjonene deres holder tritt med spesifikasjonene.
Bedrifter som bruker agentautomatisering bør være oppmerksom selv om de aldri leser MCP-spesifikasjonen. Endringen kan påvirke påliteligheten til agenter som kobler til repositories, billettsystemer, databaser, interne kunnskapsbaser eller distribusjonsverktøy. Under migreringsvinduer er de sannsynlige feilmodusene ikke bare åpenbare strømbrudd. De kan omfatte manglende verktøyfunksjoner, endret autentiseringsatferd eller agenter som tar forskjellige veier fordi en verktøyserver ikke lenger oppfører seg som forventet.
For en AI API-gateway som Model Gate er tilkoblingen praktisk. En enhetlig AI API ligger i økende grad nær modellruting, API-nøkkeladministrasjon, bruksanalyse og team-API-styring. Ettersom agentsystemer legger til MCP-verktøykall ved siden av vanlige modellkall, må gateway- og observerbarhetslag ta hensyn til begge sider av arbeidsflyten: hvilken modell som ble brukt, hvilke verktøy som ble påkalt, hva de kostet, hvem som autoriserte dem, og hvor feil oppsto.
Migrasjonsprioriteter og åpne spørsmål
Den første prioritet for kompatibilitetsmigreringstest er kompatibilitetsmigreringstest. Teamene bør inventere MCP-klienter og -servere, identifisere avhengigheter av økter eller initialisere atferd, og teste mot 2026-07-28 SDK-er eller samsvarsmateriale der dette er tilgjengelig. Produksjonssystemer bør iscenesette oppgraderingen, spesielt hvis agenter utfører handlinger med bivirkninger som å lage pull-forespørsler, endre problemer, spørre etter kundedata eller utføre distribusjonsarbeidsflyter.
Den andre prioritet er observerbarhet. Statsløs infrastruktur kan være enklere å skalere, men distribuerte agentsystemer trenger fortsatt korrelasjons-IDer, sporing, forespørselslogger og policyhendelser. Uten disse kan team bytte øktkompleksitet mot feilsøkingskompleksitet. Bruksanalyse bør skille mellom modellanrop og verktøykall, spesielt når arbeidsflyter for agenter faktureres, satsbegrenses eller revideres av teamet.
Den tredje prioritet er gjennomgang av autorisasjon. Hvis den nye spesifikasjonen forsterker autorisasjonssemantikken, bør ikke implementere bare overføre gamle tilgangsforutsetninger til den nye versjonen. De bør på nytt sjekke tokenomfang, brukerdelegering, tjenestekontoer, revisjonslogger og avslagsatferd. Verktøytilgang bør være minst privilegert som standard, spesielt for eksterne MCP-distribusjoner.
Noen detaljer er fortsatt verdt å sjekke før organisasjoner tar irreversible designbeslutninger. Forskningen som er tilgjengelig for denne artikkelen inkluderte utgivelseskandidaten, spesifikasjonssiden, SDK-migreringsmateriell og GitHubs implementeringsnotat. Den endelige normative ordlyden i 2026-07-28-spesifikasjonen bør gjennomgås direkte før de siterer eksakte protokollkrav i interne standarder eller kundedokumentasjon.
Selv med det forbeholdet er retningen klar. MCP er i ferd med å bli en mer produksjonsorientert protokoll for agentinfrastruktur. Den statsløse kjernen skal gjøre fjerndistribusjoner lettere å skalere, men den tvinger også økosystemet til å rydde opp i antakelser fra tidligere implementeringer. For lag som bygger med agenter, er dette den typen protokollendringer som fortjener en sprintbillett, ikke bare et bokmerke.