Specifikacija MCP-a 2026-07-28: što jezgra protokola bez stanja znači za arhitekturu agenata

Najvažnija promjena u specifikaciji Model Context Protocola (MCP) 2026-07-28 nije nova vrsta alata ni pogodnost u SDK-u. Riječ je o promjeni toga gdje protokol čuva značenje. MCP se pomiče od dvosmjernog protokola sa stanjem prema jezgri zahtjev/odgovor u kojoj svaki zahtjev nosi dovoljno konteksta da se obradi neovisno.

To zvuči kao detalj transporta sve dok ne počnete upravljati agentskim sustavom iza balancera opterećenja. U starijem modelu udaljeni MCP poslužitelj mogao je uspostaviti protokolnu sesiju, zadržati identifikator sesije i računati na to da će se sljedeći zahtjev vratiti na istu logičku vezu ili na pozadinski sustav s pristupom zajedničkoj pohrani sesija. Novi model uklanja tu ovisnost na razini protokola. Zahtjev može stići na bilo koju zdravu instancu, baš kao običan HTTP API zahtjev.

Rezultat nije „sve MCP aplikacije sada moraju biti bez stanja”. On je korisniji od toga: stanje protokola i stanje aplikacije razdvojeni su. Protokol više ne skriva kontinuitet razgovora u transportnoj sesiji. Ako agentski radni tok treba kontinuitet, aplikacija ga mora eksplicitno predstaviti i odabrati kako će ga pohraniti i osigurati.

Što jezgra 2026-07-28 uklanja

Objava izdanja umirovljuje razmjenu initialize/initialized i zaglavlje Mcp-Session-Id u novom načinu rada protokola. Umjesto da se podaci o klijentu pregovaraju jednom i da se potom poziva na implicitnu sesiju, svaki zahtjev nosi svoju verziju protokola, identitet klijenta i mogućnosti klijenta u _meta. Klijenti koji žele podatke o mogućnostima prije uobičajenog poziva mogu upotrijebiti novi RPC server/discover, no otkrivanje je neobavezno.

Pojednostavljeni zahtjev iz službene objave izgleda ovako:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Važno svojstvo nije to da se svako polje ponavlja samo radi sebe. Riječ je o tome da instanca poslužitelja ne mora rekonstruirati kontekst protokola iz veze koju nije sama uspostavila. Obični round-robin balancer može raspodijeliti pozive bez ljepljivih sesija, a instanca se može zamijeniti bez prethodne migracije svoje tablice MCP sesija.

Time se razjašnjava i čest nesporazum. „Protokol bez stanja” ne znači „poslužitelj ne može ništa zapamtiti”. Znači da se memorija koju aplikacija zahtijeva više ne prokrijumčari kroz životni ciklus protokola. Košarica za kupnju, ručka preglednika, zapis o odobrenju ili dugotrajan posao i dalje mogu postojati. Treba ih eksplicitno identificirati i prenijeti kao podatke koje aplikacija razumije.

Horizontalno skaliranje postaje običan HTTP problem

Za udaljenu implementaciju MCP-a neposredna arhitekturna korist je jednostavnije horizontalno skaliranje. MCP krajnja točka bez stanja može stajati iza uobičajenog balancera opterećenja, gatewaya, CDN ruba ili serverless HTTP runtimea. Nove se instance mogu pokretati i zaustavljati bez rituala pražnjenja sesija specifičnog za MCP. Kapacitet se može povećati brojem replika, a otkazala instanca ne ostavlja bez pomoći svaku klijentsku sesiju koja je na nju vezana.

To ne uklanja operativni dizajn. Usluga i dalje treba autentifikaciju, autorizaciju, ograničavanje brzine, observability, idempotentnost i trajni sloj podataka tamo gdje proizvod to zahtijeva. Uklanja jedno neugodno ograničenje: balancer više ne mora čuvati nevidljiv razgovor protokola.

Arhitektura se stoga približava uobičajenom API sloju:

1. Rubni sloj ili gateway koji razumije MCP prekida TLS i primjenjuje identitet i pravila.
2. Usmjeravanje šalje zahtjeve na bilo koju kompatibilnu MCP instancu.
3. Instance provjeravaju zahtjev, pozivaju alate te čitaju ili pišu u vanjske usluge.
4. Trajno stanje živi u bazi podataka, spremištu objekata, redu čekanja, predmemoriji ili drugom eksplicitnom sustavu evidencije.
5. Zapisnici i tragovi povezuju pojedinačne zahtjeve i ručke aplikacije umjesto da pretpostavljaju da jedan otvoreni stream objašnjava radni tok.

To je osobito korisno za agentske platforme koje ugošćuju mnogo zakupnika ili dinamički biraju alate. Planiranje kapaciteta može se usredotočiti na brzinu zahtjeva, latenciju alata, konkurentnost i ograničenja nizvodnih sustava umjesto na broj protokolskih sesija otvorenih na svakom radniku.

I dalje postoje razlozi za korištenje afiniteta u pojedinoj aplikaciji. Lokalna predmemorija može učiniti ljepljivu rutu bržom, a specijalizirani radnik može posjedovati skup model u memoriji. No afinitet postaje optimizacija ili izbor aplikacije, a ne zahtjev koji nameće jezgra MCP protokola.

Sesije nisu nestale; nestale su implicitne sesije

Pitanje migracije koje bi većina timova trebala postaviti nije „Kako da ponovno stvorimo Mcp-Session-Id?”, nego „Koje smo stanje tamo slučajno pohranili?”

Neke su integracije protokolnu sesiju koristile kao prikladan spremnik za identitet korisnika, odabrani radni prostor, kontekst autorizacije, rezultate alata ili djelomično dovršen radni tok. Te vrijednosti imaju različite životne cikluse i sigurnosna svojstva. Njihovo stavljanje iza jednog neprozirnog identifikatora olakšalo je previd isteka, granica zakupništva, ponašanja ponavljanja i oporavka nakon ponovnog pokretanja radnika.

Model bez stanja potiče eksplicitniji dizajn. Alat može vratiti ručku kao što je basket_id, browser_id, workspace_id ili task_id. Model ili klijent prosljeđuje tu ručku sljedećem pozivu alata. Usluga je razrješava prema trajnom spremištu i provjerava smije li je pozivatelj upotrijebiti.

To što je ručka vidljiva modelu može biti korisno: agent može prenositi identitet preglednika ili košarice između alata umjesto da ovisi o skrivenom stanju transporta. Time se otvara i površina za promptove i za autorizaciju. Vežite ručke na autentificiranog pozivatelja, provedite vlasništvo, definirajte istek i odlučite moraju li ponovni pokušaji biti idempotentni. Za trajne radne tokove upotrijebite bazu podataka ili sustav zadataka; za velike artefakte pohranite artefakt izvan sustava i prenesite referencu s eksplicitnim pravilima pristupa.

Izbor transporta: Streamable HTTP dobiva produkcijski put

Objava mijenja i to što operateri mogu raditi na HTTP rubu. Zahtjevi Streamable HTTP moraju sadržavati zaglavlja Mcp-Method i Mcp-Name. Gateway, WAF, ograničivač brzine ili sloj metrika mogu usmjeravati i mjeriti zahtjeve na temelju zaglavlja bez parsiranja JSON-RPC tijela. Poslužitelji odbijaju zahtjeve u kojima se zaglavlja i tijelo ne slažu, što onemogućuje da rub autorizira jednu operaciju dok tijelo traži drugu.

Za produkcijske MCP usluge to Streamable HTTP čini prikladnijim za uobičajenu infrastrukturu. Ostaje kompatibilan s HTTP alatima, dok protokol više ne ovisi o trajno otvorenom dvosmjernom toku za svaku interakciju. Naslijeđeni transport HTTP+SSE službeno je zastario uz prijelazno razdoblje od godine dana, pa nove implementacije ne bi trebale graditi dugoročnu arhitekturu oko njega.

MRTR, odnosno Multi Round-Trip Requests, popunjava važnu prazninu koju je stvorio dizajn bez stanja. Neki alati trebaju potvrdu ili drugu vrijednost dok je poziv u tijeku. Stari je obrazac koristio zahtjeve koje inicira poslužitelj preko otvorenog toka za operacije poput elicitationa i samplinga. Uz MRTR poslužitelj može vratiti resultType: "input_required" sa zahtjevima na koje treba odgovoriti. Klijent zatim ponavlja izvorni poziv s odgovorima u inputResponses.

Za agentsku arhitekturu to je značajna promjena u tijeku upravljanja. „Pitaj korisnika i nastavi” postaje eksplicitna protokolna razmjena koja se može nastaviti, a ne skrivena ovisnost o živoj vezi. Klijenti i orkestratori moraju pohraniti dovoljno podataka da sigurno nastave, prikažu zahtjev, provjere odgovor i izbjegnu dvostruko izvršavanje izvorne radnje.

Eksternalizirajte stanje koje agenti doista trebaju

Jezgra MCP-a bez stanja sama po sebi ne rješava trajnost radnog toka. Ona čini granicu vidljivom. Graditelji agenata trebaju odlučiti koje stanje pripada kojem sloju:

• MCP zahtjev nosi metapodatke protokola i argumente za ovu operaciju.
• Agentski runtime posjeduje povijest razgovora, kontekst planiranja, pozive modela i pravila interakcije s korisnikom.
• MCP poslužitelj posjeduje implementaciju alata i aplikacijske zapise potrebne za njegovo sigurno izvršavanje.
• Sustav zadataka ili poslova posjeduje dugotrajan rad, ponovne pokušaje, napredak i otkazivanje.
• Baze podataka i spremišta objekata posjeduju trajne poslovne podatke i velike izlaze.
• Observability sustavi posjeduju tragove, revizijske zapise i operativne događaje.

Izdanje 2026-07-28 premješta Tasks u ekstenziju io.modelcontextprotocol/tasks. Poslužitelj može vratiti ručku zadatka za rad koji se ne bi trebao dovršiti u jednom zahtjevu, a klijent može upotrijebiti tasks/get, tasks/update i tasks/cancel. To je bolje mjesto za dugotrajno stanje od otvorene protokolske sesije. Operaterima daje i konkretan životni ciklus za praćenje: stvoren, u tijeku, dovršen, neuspješan, istekao ili otkazan.

Isto načelo vrijedi i za predmemoriranje. Odgovori na tools/list, prompts/list, resources/list i resources/read sada nose ttlMs i cacheScope, uz deterministički poredak. Klijenti mogu predmemorirati kataloge i rezultate resursa prema naznakama poslužitelja umjesto da svako ponovno povezivanje tretiraju kao potpuno novo otkrivanje. Stabilan izlaz popisa pomaže i predmemorijama promptova uzvodno: katalog alata koji bez razloga mijenja poredak može izazvati nepotrebne promašaje predmemorije u agentskom sustavu.

Što integratori trebaju promijeniti

Praktičan plan migracije treba biti konkretniji od „nadogradite SDK”. Počnite popisom svih mjesta na kojima integracija ovisi o starom životnom ciklusu.

Prvo, testirajte pregovaranje protokola i kompatibilnost. Novi klijent ili poslužitelj možda mora posluživati 2026-07-28 i istovremeno surađivati sa starijim implementacijama. Provjerite kako SDK koji koristite odabire reviziju, vraća li se na raniji handshake i koji je način transporta eksplicitno omogućen. Napomene uz izdanje ističu da se ponašanje SDK-a razlikuje prema jeziku i verziji; ne zaključujte o ponašanju na žici samo na temelju nadogradnje paketa.

Drugo, uklonite pretpostavke o initialize, initialized i Mcp-Session-Id iz međusloja, testova, metrika i usmjeravanja. Ako obrnuti proxy vodi tablicu sesija prema tom zaglavlju, odlučite treba li to postati obično usmjeravanje zahtjeva ili ga treba zamijeniti eksplicitnom ručkom aplikacije.

Treće, neka pravila na HTTP rubu uzimaju u obzir zaglavlja. Provjeravajte Mcp-Method i Mcp-Name, bilježite ih kao strukturirana polja i osigurajte da gateway ne vjeruje zaglavlju bez provjere tijela zahtjeva. Dodajte ograničenja brzine i pravila autorizacije na razini metode tamo gdje profil rizika to zahtijeva.

Četvrto, modelirajte stanje i ponovne pokušaje. Prepoznajte svaki alat koji pretpostavlja da se prethodni poziv dogodio na istom radniku. Dodijelite mu eksplicitnu ručku ili premjestite stanje u trajnu uslugu. Definirajte ponašanje idempotentnosti za ponovne pokušaje, osobito za pisanja, plaćanja, provisioning i destruktivne operacije. Isprobajte prekid instance između dva poziva; taj je test kvara vrjedniji od testa sretnog puta koji održava jedan proces na životu.

Peto, implementirajte MRTR i Tasks prema njihovoj stvarnoj semantici umjesto da oponašate stare pozive koje inicira poslužitelj. Testirajte upite za odobrenje, nedostajući unos, ponovna povezivanja, dvostruke odgovore, periodičko provjeravanje statusa zadataka, otkazivanje i istek. Agentski runtimeovi trebaju čuvati stanje koje se može nastaviti izvan MCP transporta.

Naposljetku, pregledajte autorizaciju. Revizija dodaje smjernice za provjeru izdavatelja usklađene s RFC 9207, veže vjerodajnice klijenta na izdavatelja koji ih je izdao i formalno stavlja izvan uporabe Dynamic Client Registration u korist Client ID Metadata Documents. To nisu posljedice samo odsutnosti stanja, ali dio su istog izdanja integracije i trebaju ući u plan testiranja migracije.

Bolji temelj za agentsku infrastrukturu

MCP 2026-07-28 ne pretvara svakog agenta u funkciju bez stanja. Agentskim sustavima daje čišću granicu protokola. Zahtjevi se mogu usmjeravati kao HTTP zahtjevi, usluge se mogu skalirati bez zajedničkih protokolskih sesija, a stanje aplikacije može se osmisliti kao vidljivi, testabilni podaci s vlasnikom i životnim ciklusom.

Ta je promjena važna jer agentska radna opterećenja nisu pojedinačni razgovori unutar jednog procesa. To su distribuirani radni tokovi s ponovnim pokušajima, odobrenjima, pozadinskim zadacima, katalozima alata, identitetom i djelomičnim kvarom. Skrivena sesija može učiniti demo jednostavnim, a istovremeno otežati produkcijski oporavak. Jezgra bez stanja traži da integratori plate složenost tamo gdje joj je mjesto: u eksplicitnom stanju aplikacije, trajnim sustavima radnih tokova i rukovanju zahtjevima koje se može promatrati.

Za novu udaljenu MCP uslugu počnite sa Streamable HTTP-om bez stanja, običnim uravnoteživanjem opterećenja, eksplicitnim ručkama i trajnim modelom stanja. Za postojeću uslugu migrirajte postupno: zadržite kompatibilnost gdje je potrebna, uklonite pretpostavke o ljepljivim sesijama, testirajte kvar između poziva i usvojite Tasks ili MRTR za radne tokove koji su prije ovisili o otvorenoj vezi. Korist nije samo u više replika. Riječ je o agentskoj arhitekturi koja se ponaša predvidljivo kad radnik nestane, promet se premjesti, korisnik se vrati kasnije ili poziv alata treba ponoviti.