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, MCP aplikacije, utrjevanje avtorizacije in formalno politiko opustitve. Uradni blog MCP je tudi opozoril, da izdaja vsebuje kritične spremembe. GitHub, ki upravlja z eno najvidnejših implementacij strežnika MCP, je pred končno izdajo dejal, 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 internetni protokol za dostop do orodij na daljavo. To je pomembno, ker sistemi agentov niso več omejeni na orodja za namizne razvijalce. Vse pogosteje delujejo znotraj storitev v oblaku, sistemov CI, delovnih tokov podpore strankam, sledilnikov težav in platform za avtomatizacijo podjetij.
Kaj se je spremenilo v MCP
Glavna sprememba je prehod na jedro protokola brez stanja. V dnevniku sprememb GitHub piše, da novo jedro odstrani seje in inicializacijo, s ciljem, da se oddaljene uvedbe MCP olajšajo za prilagajanje. To je pomemben arhitekturni premik. Protokoli z zaznavanjem stanja lahko dobro delujejo za lokalna orodja in nadzorovana okolja, vendar zapletajo horizontalno skaliranje, izvajanje brez strežnika, samodejni preklop, uvajanje robov in uravnoteženje obremenitve.
Jedro brez stanja daje izvajalcem več svobode pri izvajanju MCP strežnikov 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 MCP strežnikov 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. MCP Aplikacije in utrjevanje avtorizacije kažejo v isto smer: protokol dozoreva 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 tisto s prelomnimi spremembami, materiali TypeScript in C# SDK, objavljeni 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 brez stanja MCP pomembno za razvijalce in operaterje
Agentska orodja imajo težavo s skaliranjem, ki se razlikuje od običajnega API skaliranja. Ena sama zahteva uporabnika lahko sproži številne klice orodij, obračanje modela, ponovne poskuse, branje 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 MCP bolje ustreza 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 MCP postaja pogostejši pri pomočnikih za kodiranje in podjetniških agentih, bodo podjetja potrebovala pravilnike o tem, katera orodja lahko agenti pokličejo, do katerih podatkov lahko dostopajo in katerim uporabnikom ali storitvam je dovoljeno, da jih prikličejo. Ojačitev Authorization v novi reviziji torej ni naključna. Odraža resničnost, da je dostop do orodij zdaj varnostna meja, ne le udobje za razvijalce.
Kdo je prizadet
Najbolj neposredno prizadete skupine so MCP vzdrževalci strežnikov, SDK uporabniki, 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č MCP različic, morda potrebuje pogajanja o različici, združljivostne plasti ali načrt postopne selitve.
V obsegu so tudi prodajalci IDE in orodij za razvijalce. 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 MCP specifikacije. 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. Enoten AI API se vedno bolj približuje usmerjanju modela, API upravljanju ključev, analitiki uporabe in API upravljanju ekipe. Ker agentski sistemi dodajajo MCP klice orodij poleg običajnih klicev modela, bodo morali sloji 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.
Prioritete selitve in odprta vprašanja
Prva prioriteta selitve je testiranje združljivosti. Ekipe bi morale opraviti inventar MCP odjemalcev in strežnikov, 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 izvajati nadgradnjo, zlasti če agenti izvajajo dejanja s stranskimi učinki, kot so ustvarjanje zahtev za vlečenje, spreminjanje težav, poizvedovanje po podatkih strank 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 korelacijske ID-je, 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 MCP uvedbe.
Nekatere podrobnosti je še vedno vredno preveriti, preden organizacije sprejmejo nepopravljive oblikovalske odločitve. Raziskava, ki je na voljo za ta članek, je vključevala kandidata za izdajo, stran s specifikacijami, gradivo 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 produkcijsko usmerjen protokol za agentsko infrastrukturo. Jedro brez stanja bi moralo olajšati prilagajanje oddaljenih uvedb, vendar tudi 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.