Modelkontextprotokollet har nått en viktig milstolpe för infrastrukturen: dess 2026-07-28 revidering flyttar protokollet mot en tillståndslös kärna. För team som bygger agentsystem, verktygsservrar, IDE-integrationer eller orkestreringslager med flera modeller är detta inte en kosmetisk specifikationsuppdatering. Det ändrar antaganden om sessioner, initiering, skalning, kompatibilitet och styrning.
MCP-utgivningskandidaten beskrev specifikationen för 28 juli som att lägga till en tillståndslös protokollkärna, ett tilläggsramverk, uppgifter, MCP-appar, auktoriseringshärdning och en formell utfasningspolicy. Den officiella MCP-bloggen varnade också för att releasen innehåller brytande förändringar. GitHub, som driver en av de mest synliga MCP-serverimplementeringarna, sa inför den slutliga utgåvan att dess MCP-server redan stödde den nya specifikationen och beskrev protokollet som "att bli tillståndslöst" den 28 juli.
Den praktiska innebörden är okomplicerad: MCP formas mindre som ett sessionstungt lokalt integrationslager och mer som ett protokoll för åtkomst till fjärrverktyg i internetskala. Det är viktigt eftersom agentsystem inte längre är begränsade till verktyg för skrivbordsutvecklare. De körs allt oftare i molntjänster, CI-system, arbetsflöden för kundsupport, problemspårare och företagsautomationsplattformar.
Vad som förändrades i MCP
Rubrikändringen är övergången till en tillståndslös protokollkärna. GitHubs ändringslogg säger att den nya kärnan tar bort sessioner och initierar, med målet att göra fjärr-MCP-distributioner lättare att skala. Det är ett betydande arkitektoniskt skifte. Stateful protokoll kan fungera bra för lokala verktyg och kontrollerade miljöer, men de komplicerar horisontell skalning, serverlös exekvering, failover, edge-distribution och lastbalansering.
En tillståndslös kärna ger implementerare större frihet att köra MCP-servrar bakom vanlig webbinfrastruktur. Förfrågningar kan distribueras över instanser utan att bevara en långlivad session på en specifik backend. För stora organisationer kan det minska den operativa komplexiteten. För mindre team kan det göra värdbaserade MCP-servrar enklare att distribuera med hjälp av hanterad beräkning istället för anpassad långvarig infrastruktur.
Den bredare versionen 2026-07-28 introducerar också ett tilläggsramverk och uppgifter, enligt materialet för releasekandidat. Dessa tillägg tyder på att MCP blir mer modulärt och mer explicit när det gäller arbete som pågår längre. MCP-appar och auktoriseringshärdning pekar i samma riktning: protokollet mognar från tidig ekosystemlim till ett mer formellt lager för interaktion mellan agenter och verktyg.
Kostnaden för denna mognad är kompatibilitetsarbete. MCP-bloggen karakteriserade releasen som en med brytande förändringar, och TypeScript- och C# SDK-material som publicerades kring revisionen fokuserar på migreringsstöd och tillståndslösa koncept. Alla lag som driver en MCP-server, bäddar in MCP i en IDE-tillägg eller dirigerar agentanrop genom intern infrastruktur bör behandla revisionen som en teknisk händelse snarare än en bakgrundsstandarduppdatering.
Varför tillståndslös MCP är viktigt för utvecklare och operatörer
Agentverktyg har ett skalningsproblem som ser annorlunda ut än vanliga API-skalning. En enda användarförfrågan kan utlösa många verktygsanrop, modellvändningar, återförsök, filläsningar, sökfrågor och godkännandesteg. När verktygsprotokollet förutsätter varaktiga sessioner, måste produktionsoperatörer bevara tillstånd över dessa interaktioner eller bygga lösningar runt protokollet.
Genom att ta bort sessioner från kärnan passar MCP bättre miljöer där agentarbetsbelastningar är sprängfyllda, distribuerade och asynkrona. Serverlösa funktioner, kantarbetare, Kubernetes-distributioner och multiregionsystem gynnas alla när förfrågningar kan hanteras oberoende. Det eliminerar inte tillstånd från agentapplikationer; det flyttar tillstånd till applikationsdatabaser, uppgiftsköer, identitetssystem eller explicita arbetsflödeslager snarare än att bädda in det i protokollkärnan.
För utvecklare bör ändringen så småningom göra fjärrverktygsservrar lättare att konsumera. För plattformsteam kan det förenkla observerbarhet och kapacitetsplanering. Istället för att felsöka ogenomskinliga sessionsaffinitetsbeteende kan operatörer fokusera på spårningar på begäran-nivå, fördröjning av verktygssamtal, auktoriseringsbeslut och felmönster.
Det finns också en styrningsvinkel. När MCP blir vanligare i kodningsassistenter och företagsagenter kommer företag att behöva policyer kring vilka verktyg agenter kan ringa, vilken data de kan komma åt och vilka användare eller tjänster som får anropa dem. Behörighetsförstärkning i den nya revideringen är därför inte tillfällig.Det återspeglar verkligheten att verktygsåtkomst nu är en säkerhetsgräns, inte bara en bekvämlighet för utvecklare.
Vem påverkas
De mest direkt berörda grupperna är MCP-serverunderhållare, SDK-användare, agentplattformsteam och organisationer som exponerar interna verktyg för AI-agenter. Om en server är beroende av sessionsbeteende eller äldre initieringsflöden måste den testas mot den nya specifikationen. Om en applikation stöder flera MCP-versioner kan den behöva versionsförhandling, kompatibilitetsskikt eller en fasad migreringsplan.
Leverantörer av IDE och utvecklarverktyg omfattas också. MCP dyker alltmer upp tillsammans med kodningsagenter, anpassade agenter och modellhanteringsfunktioner. En tillståndslös protokollkärna gör det lättare för dessa produkter att anropa fjärrverktyg på ett tillförlitligt sätt, men bara om deras integrationer håller jämna steg med specifikationen.
Företag som använder agentautomatisering bör vara uppmärksamma även om de aldrig läser MCP-specifikationen. Ändringen kan påverka tillförlitligheten hos agenter som ansluter till arkiv, biljettsystem, databaser, interna kunskapsbaser eller distributionsverktyg. Under migreringsfönster är de troliga fellägena inte bara uppenbara avbrott. De kan innefatta saknade verktygsfunktioner, ändrat autentiseringsbeteende eller att agenter tar olika vägar eftersom en verktygsserver inte längre beter sig som förväntat.
För en AI API-gateway som Model Gate är anslutningen praktisk. En enhetlig AI API ligger allt mer nära modellrouting, API-nyckelhantering, användningsanalys och team-API-styrning. När agentsystem lägger till MCP-verktygsanrop vid sidan av vanliga modellanrop kommer gateway- och observerbarhetsskikt att behöva ta hänsyn till båda sidor av arbetsflödet: vilken modell som användes, vilka verktyg som anropades, vad de kostade, vem auktoriserade dem och var fel inträffade.
Migreringsprioriteringar och öppna frågor
Den första prioritet för kompatibilitetsmigreringstestet är kompatibilitetsmigreringstest. Team bör inventera MCP-klienter och -servrar, identifiera beroenden av sessioner eller initiera beteende och testa mot 2026-07-28 SDK:er eller överensstämmelsematerial där sådana finns. Produktionssystemen bör iscensätta uppgraderingen, särskilt om agenter utför åtgärder med bieffekter som att skapa pull-förfrågningar, ändra problem, fråga efter kunddata eller utföra distributionsarbetsflöden.
Den andra prioritet är observerbarhet. Statslös infrastruktur kan vara lättare att skala, men distribuerade agentsystem behöver fortfarande korrelations-ID:n, spårfångst, förfrågningsloggar och policyhändelser. Utan dessa kan team byta sessionskomplexitet mot felsökningskomplexitet. Användningsanalyser bör skilja mellan modellanrop och verktygsanrop, särskilt när agentarbetsflöden faktureras, begränsas eller granskas av teamet.
Den tredje prioritet är granskning av auktorisering. Om den nya specifikationen förstärker auktoriseringssemantiken bör implementerare inte bara överföra gamla åtkomstantaganden till den nya versionen. De bör kontrollera tokenomfång, användardelegering, tjänstkonton, granskningsloggar och förnekelsebeteende igen. Verktygsåtkomst bör vara minsta privilegium som standard, särskilt för fjärr-MCP-distributioner.
Vissa detaljer är fortfarande värda att kontrollera innan organisationer fattar oåterkalleliga designbeslut. Forskningen som är tillgänglig för den här artikeln inkluderade releasekandidaten, specifikationssidan, SDK-migreringsmaterial och GitHubs implementeringsnotis. Den slutliga normativa formuleringen av specifikationen för 2026-07-28 bör granskas direkt innan exakta protokollkrav citeras i interna standarder eller kunddokumentation.
Även med den varningen är riktningen tydlig. MCP håller på att bli ett mer produktionsorienterat protokoll för agentinfrastruktur. Den tillståndslösa kärnan borde göra fjärrinstallationer lättare att skala, men den tvingar också ekosystemet att rensa upp antaganden från tidigare implementeringar. För lag som bygger med agenter är detta den typ av protokolländring som förtjänar en sprintbiljett, inte bara ett bokmärke.