Model Context Protocol je dosegel pomemben infrastrukturni mejnik: njegova revizija 2026-07-28 premakne protokol k jedru brez stanja. Za ekipe, ki gradijo sisteme agentov, strežnike orodij, integracije IDE ali sloje orkestracije z več modeli, to ni kozmetična posodobitev specifikacij. Spreminja predpostavke o sejah, inicializaciji, skaliranju, združljivosti in upravljanju.
Kandidat za izdajo MCP je specifikacijo z dne 28. julija opisal kot dodajanje jedra protokola brez stanja, ogrodje razširitev, naloge, aplikacije MCP, utrjevanje avtorizacije in formalno politiko opustitve. Uradni blog MCP je tudi opozoril, da izdaja vsebuje prelomne spremembe. GitHub, ki upravlja eno najvidnejših implementacij strežnika MCP, je pred končno izdajo povedal, da njegov strežnik MCP že podpira novo specifikacijo in je 28. julija opisal protokol kot "brez stanja".
Praktični pomen je preprost: MCP se oblikuje manj kot sloj lokalne integracije, ki je obremenjen s sejami, in bolj kot protokol internetne ravni za dostop do orodij na daljavo. To je pomembno, ker sistemi agentov niso več omejeni na orodja za namizne razvijalce. Vse pogosteje se izvajajo znotraj storitev v oblaku, sistemov CI, potekov dela za podporo strankam, sledilcev težav in platform za avtomatizacijo podjetij.
Kaj se je spremenilo v MCP
Glavna sprememba je prehod na jedro protokola brez stanja. GitHubov dnevnik sprememb pravi, da novo jedro odstrani seje in inicializacijo, s ciljem, da se oddaljene uvedbe MCP lažje prilagodijo. To je pomemben arhitekturni premik. Protokoli z zaznavanjem stanja lahko dobro delujejo za lokalna orodja in nadzorovana okolja, vendar zapletajo vodoravno skaliranje, izvajanje brez strežnika, samodejni preklop, uvajanje robov in uravnoteženje obremenitve.
Jedro brez stanja daje izvajalcem več svobode pri izvajanju strežnikov MCP za običajno spletno infrastrukturo. Zahteve je mogoče porazdeliti po instancah, ne da bi ohranili dolgotrajno sejo na določenem ozadju. Za velike organizacije lahko to zmanjša kompleksnost delovanja. Za manjše ekipe lahko olajša uvajanje gostujočih strežnikov MCP z uporabo upravljanega računalništva namesto prilagojene dolgo delujoče infrastrukture.
Širša izdaja 2026-07-28 uvaja tudi ogrodje razširitev in naloge, glede na materiale kandidatov za izdajo. Ti dodatki kažejo, da MCP postaja bolj modularen in bolj nazoren glede dolgotrajnejšega dela. Aplikacije MCP in utrjevanje avtorizacije kažejo v isto smer: protokol zori iz zgodnjega lepila ekosistema v bolj formalno plast za interakcijo med agentom in orodjem.
Cena tega zorenja je združljivost. Spletni dnevnik MCP je izdajo označil kot izdajo s prelomnimi spremembami, gradiva TypeScript in C# SDK, objavljena okoli revizije, pa se osredotočajo na podporo za selitev in koncepte brez stanja. Vsaka ekipa, ki upravlja strežnik MCP, vgrajuje MCP v razširitev IDE ali klice agenta za usmerjanje prek notranje infrastrukture, bi morala revizijo obravnavati kot inženirski dogodek in ne kot posodobitev standardov v ozadju.
Zakaj je MCP brez stanja pomemben za razvijalce in operaterje
Agentska orodja imajo težavo s skaliranjem, ki se razlikuje od običajnega skaliranja API-ja. Ena sama zahteva uporabnika lahko sproži številne klice orodij, obračanja modela, ponovne poskuse, branja datotek, iskalne poizvedbe in korake odobritve. Ko protokol orodja predvideva trajne seje, morajo produkcijski operaterji ohraniti stanje med temi interakcijami ali ustvariti rešitve okoli protokola.
Z odstranitvijo sej iz jedra se MCP bolje prilega okoljem, kjer so delovne obremenitve agentov hitre, porazdeljene in asinhrone. Funkcije brez strežnika, robni delavci, uvedbe Kubernetes in sistemi z več regijami koristijo, če je mogoče zahteve obravnavati neodvisno. To ne odstrani stanja iz agentskih aplikacij; premakne stanje v baze podatkov aplikacij, čakalne vrste opravil, sisteme identitete ali eksplicitne plasti poteka dela, namesto da bi ga vdelali v jedro protokola.
Za razvijalce bi morala sprememba sčasoma olajšati uporabo oddaljenih strežnikov orodij. Za ekipe platforme lahko poenostavi opazovanje in načrtovanje zmogljivosti. Namesto odpravljanja napak v neprozornem vedenju afinitete seje se lahko operaterji osredotočijo na sledenje na ravni zahteve, zakasnitev klica orodja, avtorizacijske odločitve in vzorce napak.
Obstaja tudi vidik upravljanja. Ker postaja MCP pogostejši pri pomočnikih za kodiranje in podjetniških agentih, bodo podjetja potrebovala pravilnike o tem, katera orodja lahko agenti kličejo, do katerih podatkov lahko dostopajo in katerim uporabnikom ali storitvam je dovoljeno, da jih prikličejo. Okrepitev avtorizacije v novi reviziji torej ni naključna.Odraža resničnost, da je dostop do orodij zdaj varnostna meja in ne le udobje za razvijalce.
Koga to zadeva
Najbolj neposredno prizadete skupine so vzdrževalci strežnikov MCP, uporabniki SDK, skupine agentske platforme in organizacije, ki izpostavljajo notranja orodja agentom AI. Če je strežnik odvisen od vedenja seje ali starejših inicializacijskih tokov, ga bo treba preizkusiti glede na novo specifikacijo. Če aplikacija podpira več različic MCP, bo morda potrebovala pogajanja o različici, združljivostne plasti ali načrt postopne selitve.
V obsegu so tudi prodajalci IDE in razvijalskih orodij. MCP se vse pogosteje pojavlja poleg agentov za kodiranje, agentov po meri in funkcij za upravljanje modelov. Jedro protokola brez stanja tem izdelkom olajša zanesljivo klicanje oddaljenih orodij, vendar le, če so njihove integracije v koraku s specifikacijo.
Podjetja, ki uporabljajo avtomatizacijo agentov, morajo biti pozorna, tudi če nikoli ne preberejo specifikacije MCP. Sprememba lahko vpliva na zanesljivost agentov, ki se povezujejo z repozitoriji, sistemi izdajanja vstopnic, bazami podatkov, notranjimi bazami znanja ali orodji za uvajanje. Med selitvenimi okni verjetni načini napak niso le očitni izpadi. Vključujejo lahko manjkajoče zmogljivosti orodij, spremenjeno vedenje pri preverjanju pristnosti ali agente, ki ubirajo drugačne poti, ker se strežnik orodij ne obnaša več po pričakovanjih.
Za prehod AI API, kot je Model Gate, je povezava praktična. Poenoteni API za umetno inteligenco se vedno bolj približuje usmerjanju modela, upravljanju ključev API-ja, analizi uporabe in upravljanju timskega API-ja. Ker agentski sistemi dodajajo klice orodij MCP poleg navadnih klicev modela, bosta morala sloja prehoda in opazovanja upoštevati obe strani delovnega toka: kateri model je bil uporabljen, katera orodja so bila priklicana, koliko stanejo, kdo jih je pooblastil in kje je prišlo do napak.
Migracijske prioritete in odprta vprašanja
Prva selitvena prioriteta je testiranje združljivosti. Ekipe bi morale popisati odjemalce in strežnike MCP, identificirati odvisnosti od sej ali inicializirati vedenje ter testirati glede na SDK-je 2026-07-28 ali materiale za skladnost, kjer so na voljo. Produkcijski sistemi bi morali izvesti nadgradnjo, zlasti če agenti izvajajo dejanja s stranskimi učinki, kot so ustvarjanje zahtev za vlečenje, spreminjanje težav, poizvedovanje po podatkih o strankah ali izvajanje delovnih tokov uvajanja.
Druga prednostna naloga je opazljivost. Infrastrukturo brez stanja je mogoče lažje prilagoditi, vendar sistemi porazdeljenih agentov še vedno potrebujejo ID-je korelacije, zajem sledenja, dnevnike zahtev in dogodke pravilnika. Brez tega lahko ekipe zamenjajo kompleksnost seje za kompleksnost odpravljanja napak. Analitika uporabe bi morala razlikovati med klici modelov in klici orodij, zlasti kadar poteke dela agenta zaračunavajo, omejujejo po stopnjah ali jih revidira skupina.
Tretja prednostna naloga je pregled avtorizacije. Če nova specifikacija okrepi avtorizacijsko semantiko, izvajalci ne bi smeli preprosto prenesti starih predpostavk o dostopu v novo različico. Znova morajo preveriti obsege žetonov, delegiranje uporabnikov, storitvene račune, revizijske dnevnike in obnašanje pri zavrnitvi. Dostop do orodij bi moral biti privzeto najmanj privilegiran, zlasti za oddaljene uvedbe MCP.
Nekatere podrobnosti je še vedno vredno preveriti, preden organizacije sprejmejo nepopravljive načrtovalske odločitve. Raziskava, ki je na voljo za ta članek, je vključevala kandidata za izdajo, stran s specifikacijami, materiale za selitev SDK in opombo o implementaciji GitHub. Končno normativno besedilo specifikacije 2026-07-28 je treba pregledati neposredno pred navedbo natančnih zahtev protokola v internih standardih ali dokumentaciji strank.
Tudi s tem opozorilom je smer jasna. MCP postaja bolj proizvodno usmerjen protokol za agentsko infrastrukturo. Jedro brez stanja bi moralo olajšati prilagajanje oddaljenih uvedb, hkrati pa prisili ekosistem, da očisti predpostavke iz prejšnjih izvedb. Za ustvarjanje ekip z agenti je to vrsta spremembe protokola, ki si zasluži vstopnico za sprint, ne le zaznamek.