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.

Kandidat za izdanje MCP-a opisao je specifikaciju od 28. srpnja kao dodavanje jezgre protokola bez statusa, okvira proširenja, zadataka, MCP aplikacija, pojač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 implementacija MCP 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 s velikim brojem sesija, 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-u

Glavna promjena je prelazak na jezgru protokola bez stanja. GitHubov zapisnik promjena 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, izvođenje bez poslužitelja, nadilaženje u slučaju kvara, postavljanje ruba i balansiranje 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 aplikacije i jačanje autorizacije idu 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. MCP blog je okarakterizirao izdanje kao jedno s velikim promjenama, a TypeScript i C# SDK materijali objavljeni oko revizije usredotočuju se na podršku za migraciju i koncepte bez statusa. Bilo koji tim koji upravlja MCP poslužiteljem, ugrađuje MCP u IDE ekstenziju ili usmjerava pozive agenata kroz internu infrastrukturu trebao bi tretirati reviziju kao inženjerski događaj, a ne pozadinsko ažuriranje standarda.

Zašto je MCP bez stanja bitan 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, proizvodni operateri 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 burna, 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. Ojačavanje ovlaštenja u novoj reviziji stoga nije slučajno.Odražava stvarnost da je pristup alatima sada sigurnosna granica, a ne samo pogodnost za razvojne programere.

Tko je pogođen

Grupe koje su najizravnije pogođene su održavatelji MCP poslužitelja, korisnici SDK-a, timovi agentske platforme 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 verzija MCP-a, 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 specifikacijom.

Poduzeća koja koriste automatizaciju agenta trebaju obratiti pozornost čak i ako nikada ne pročitaju MCP specifikaciju. Promjena može utjecati na pouzdanost agenata koji se povezuju sa spremištima, sustavima za izdavanje ulaznica, bazama podataka, internim bazama znanja ili alatima za implementaciju. Tijekom prozora migracije vjerojatni načini kvara nisu samo očiti prekidi. Oni mogu uključivati ​​nedostajuće mogućnosti alata, promijenjeno ponašanje autentifikacije ili agenti koji idu različitim putovima 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. Unificirani AI API sve se više nalazi blizu usmjeravanja modela, upravljanja ključevima API-ja, analitike upotrebe i timskog upravljanja API-jem. Kako agentski sustavi dodaju pozive MCP alata uz uobičajene pozive modela, slojevi 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 stvaranje 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 modela od poziva alata, posebno kada se tijekovi rada agenta naplaćuju, ograničavaju po tarifi 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, materijale za migraciju SDK-a i bilješku o implementaciji GitHuba. 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.