Model Context Protocol dosegao je veliku infrastrukturnu prekretnicu: njegova revizija 2026-07-28 pomiče protokol prema jezgri bez stanja. Za timove koji grade agentske sustave, poslužitelje alata, IDE integracije ili slojeve orkestracije s više modela, ovo nije kozmetičko ažuriranje specifikacija. Mijenja pretpostavke o sesijama, inicijalizaciji, skaliranju, kompatibilnosti i upravljanju.
MCP kandidat za izdanje opisao je specifikaciju od 28. srpnja kao dodavanje jezgre protokola bez statusa, okvira proširenja, zadataka, MCP aplikacija, ojačanja autorizacije i formalne politike zastarevanja. Službeni MCP blog također je upozorio da izdanje sadrži prijelomne promjene. GitHub, koji upravlja jednom od najvidljivijih MCP implementacija poslužitelja, rekao je prije konačnog izdanja da njegov MCP poslužitelj već podržava novu specifikaciju i opisao protokol kao "bez statusa" 28. srpnja.
Praktično značenje je jednostavno: MCP se oblikuje manje kao lokalni integracijski sloj opterećen sesijom, a više kao internetski protokol za daljinski pristup alatu. To je važno jer agentski sustavi više nisu ograničeni na alate za razvojne programere za stolna računala. Sve se više izvode unutar usluga u oblaku, CI sustava, tijekova rada korisničke podrške, programa za praćenje problema i platformi za automatizaciju poduzeća.
Što se promijenilo u MCP
Glavna promjena je prelazak na jezgru protokola bez statusa. GitHub's changelog kaže da nova jezgra uklanja sesije i inicijalizaciju, s ciljem da se udaljene MCP implementacije lakše skaliraju. To je značajan arhitektonski pomak. Protokoli s praćenjem stanja mogu dobro funkcionirati za lokalne alate i kontrolirana okruženja, ali kompliciraju horizontalno skaliranje, izvršavanje bez poslužitelja, nadilaženje u slučaju pogreške, postavljanje ruba i uravnoteženje opterećenja.
Jezgra bez stanja daje implementatorima više slobode za pokretanje MCP poslužitelja iza obične web infrastrukture. Zahtjevi se mogu distribuirati među instancama bez očuvanja dugotrajne sesije na određenoj pozadini. Za velike organizacije to može smanjiti operativnu složenost. Za manje timove može olakšati implementaciju hostiranih MCP poslužitelja korištenjem upravljanog računanja umjesto prilagođene dugotrajne infrastrukture.
Šire izdanje 2026-07-28 također uvodi okvir proširenja i zadatke, prema materijalima kandidata za izdanje. Ti dodaci sugeriraju da MCP postaje sve modularniji i eksplicitniji u pogledu dugotrajnijeg rada. MCP Ojačavanje aplikacija i autorizacije ide u istom smjeru: protokol sazrijeva iz ranog ljepila ekosustava u formalniji sloj za interakciju između agenta i alata.
Cijena tog sazrijevanja je rad na kompatibilnosti. Blog MCP okarakterizirao je izdanje kao izdanje s velikim promjenama, a TypeScript i C# SDK materijali objavljeni oko revizije usredotočuju se na podršku za migraciju i koncepte bez stanja. Bilo koji tim koji radi na MCP poslužitelju, ugrađuje MCP u IDE ekstenziju ili usmjerava pozive agenta kroz internu infrastrukturu, trebao bi tretirati reviziju kao inženjerski događaj, a ne kao pozadinsko ažuriranje standarda.
Zašto je bez stanja MCP važno za programere i operatere
Alati agenta imaju problem skaliranja koji izgleda drugačije od običnog API skaliranja. Jedan korisnički zahtjev može pokrenuti mnoge pozive alata, okretanja modela, ponovne pokušaje, čitanja datoteka, upite za pretraživanje i korake odobrenja. Kada protokol alata pretpostavlja trajne sesije, operateri proizvodnje moraju sačuvati stanje u tim interakcijama ili izgraditi zaobilazna rješenja oko protokola.
Uklanjanjem sesija iz jezgre, MCP bolje odgovara okruženjima u kojima su radna opterećenja agenata brza, distribuirana i asinkrona. Funkcije bez poslužitelja, rubni radnici, Kubernetes implementacije i sustavi s više regija imaju koristi kada se zahtjevima može upravljati neovisno.To ne eliminira stanje iz aplikacija agenta; premješta stanje u baze podataka aplikacija, redove zadataka, sustave identiteta ili eksplicitne slojeve tijeka rada, umjesto da ga ugrađuje u jezgru protokola.
Za programere, promjena bi na kraju trebala olakšati korištenje udaljenih poslužitelja alata. Za platformske timove može pojednostaviti vidljivost i planiranje kapaciteta. Umjesto otklanjanja pogrešaka neprozirnog ponašanja afiniteta sesije, operateri se mogu usredotočiti na tragove na razini zahtjeva, latenciju poziva alata, odluke o autorizaciji i obrasce grešaka.
Postoji i kut upravljanja. Kako MCP postaje sve češći u pomoćnicima kodiranja i poslovnim agentima, tvrtkama će trebati pravila o tome koje alate agenti mogu pozvati, kojim podacima mogu pristupiti i kojim korisnicima ili uslugama je dopušteno pozivati ih. Authorization otvrdnjavanje u novoj reviziji stoga nije slučajno. Odražava stvarnost da je pristup alatu sada sigurnosna granica, a ne samo pogodnost za razvojne programere.
Tko je pogođen
Najizravnije pogođene skupine su MCP održavatelji poslužitelja, SDK korisnici, timovi agentskih platformi i organizacije koje izlažu interne alate AI agentima. Ako poslužitelj ovisi o ponašanju sesije ili starijim tokovima inicijalizacije, trebat će ga testirati prema novoj specifikaciji. Ako aplikacija podržava više MCP verzija, možda će trebati pregovaranje o verziji, slojeve kompatibilnosti ili fazni plan migracije.
IDE i dobavljači alata za razvojne programere također su uključeni. MCP se sve više pojavljuje uz agente za kodiranje, prilagođene agente i značajke za upravljanje modelima. Jezgra protokola bez statusa olakšava ovim proizvodima pouzdano pozivanje udaljenih alata, ali samo ako njihove integracije idu u korak sa specifikacijama.
Poduzeća koja koriste automatizaciju agenta trebaju obratiti pozornost čak i ako nikad ne pročitaju MCP specifikaciju. Promjena može utjecati na pouzdanost agenata koji se povezuju na repozitorije, sustave izdavanja ulaznica, baze podataka, interne baze znanja ili alate za implementaciju. Tijekom prozora migracije vjerojatni načini kvara nisu samo očiti prekidi. Mogu uključivati nedostajuće mogućnosti alata, promijenjeno ponašanje provjere autentičnosti ili agente koji idu različitim putevima jer se poslužitelj alata više ne ponaša prema očekivanjima.
Za AI API pristupnik kao što je Model Gate, veza je praktična. Objedinjeni AI API sve se više nalazi blizu usmjeravanja modela, API upravljanja ključevima, analitike upotrebe i upravljanja timom API. Kako agentski sustavi dodaju MCP pozive alata uz uobičajene pozive modela, sloj pristupnika i promatranja morat će uzeti u obzir obje strane tijeka rada: koji je model korišten, koji su alati pozvani, koliko su koštali, tko ih je ovlastio i gdje su se dogodili kvarovi.
Prioriteti migracije i otvorena pitanja
Prvi prioritet migracije je testiranje kompatibilnosti. Timovi bi trebali napraviti inventar MCP klijenata i poslužitelja, identificirati ovisnosti o sesijama ili inicijalizirati ponašanje i testirati prema 2026-07-28 SDK-ovima ili materijalima za usklađenost ako su dostupni. Produkcijski sustavi trebali bi pokrenuti nadogradnju, posebno ako agenti izvode radnje s nuspojavama kao što su kreiranje zahtjeva za povlačenjem, modificiranje problema, postavljanje upita o korisničkim podacima ili izvršavanje tijekova rada implementacije.
Drugi prioritet je vidljivost. Infrastrukturu bez stanja može se lakše skalirati, ali distribuirani agentski sustavi i dalje trebaju korelacijske ID-ove, praćenje praćenja, zapisnike zahtjeva i događaje pravila. Bez toga, timovi mogu zamijeniti složenost sesije za složenost otklanjanja pogrešaka. Analitika upotrebe trebala bi razlikovati pozive modelu od poziva alata, posebno kada se tijekovi rada agenta naplaćuju, ograničavaju po cijeni ili ih timski revidira.
Treći prioritet je pregled autorizacije. Ako nova specifikacija ojača semantiku autorizacije, implementatori ne bi trebali jednostavno prenijeti stare pretpostavke pristupa u novu verziju. Trebali bi ponovno provjeriti opseg tokena, delegiranje korisnika, račune usluga, zapisnike revizije i ponašanje odbijanja.Pristup alatu trebao bi prema zadanim postavkama biti najmanje privilegiran, posebno za udaljene MCP implementacije.
Neke detalje vrijedi provjeriti prije nego što organizacije donesu nepovratne odluke o dizajnu. Istraživanje dostupno za ovaj članak uključivalo je kandidata za izdanje, stranicu sa specifikacijama, SDK materijale za migraciju i GitHub bilješku o implementaciji. Konačni normativni tekst specifikacije 2026-07-28 trebao bi se pregledati izravno prije navođenja točnih zahtjeva protokola u internim standardima ili dokumentaciji korisnika.
Čak i uz to upozorenje, smjer je jasan. MCP postaje sve više proizvodno orijentiran protokol za agentsku infrastrukturu. Jezgra bez stanja trebala bi olakšati skaliranje daljinskih implementacija, ali također prisiljava ekosustav da očisti pretpostavke iz ranijih implementacija. Za izgradnju timova s agentima, ovo je vrsta promjene protokola koja zaslužuje kartu za sprint, a ne samo oznaku.