MCP vo verzii 2026-07-28 mení jadro protokolu na bezstavový model a upravuje škálovanie serverov

Model Context Protocol 28. júla 2026 vydal novú verziu špecifikácie 2026-07-28. Hlavná zmena nie je kozmetická: jadro protokolu sa podľa udržiavateľov presúva z obojsmerného stavového modelu na bezstavový request/response model. Oficiálny release zároveň menuje ďalšie pridané prvky: Multi Round-Trip Requests, routovanie cez HTTP hlavičky, cacheovateľné výsledky zoznamov, sprísnenie autorizácie, formálny framework rozšírení a aktualizované Tier 1 SDK. Následná roadmapa z augusta 2026 tento posun opisuje ako už dodanú časť širšej práce na škálovaní a zjednocovaní HTTP transportu.

Pre vývojárske tímy je dôležité, že nejde len o nový „feature list“, ale o zmenu základného prevádzkového modelu. V doterajšom smere protokol počítal s handshake a protokolovou session; po novom majú byť tieto prvky odstránené, takže server nemusí držať stav medzi požiadavkami.

Mechanizmus zmeny je v podkladoch popísaný pomerne konkrétne. Každá požiadavka má byť self-describing a klient si môže voliteľne zavolať discovery endpoint, aby si vopred zistil podporované verzie a schopnosti servera. To je podstatné preto, že potom môže ľubovoľná požiadavka dopadnúť na ľubovoľnú inštanciu servera za obyčajným round-robin load balancerom, bez potreby sticky sessions.

Ďalšia praktická zmena sa týka interakcií server–klient. To, čo bolo predtým riešené server-to-client požiadavkami nad trvalo otvoreným obojsmerným spojením, má byť podľa nového návrhu prepracované na Multi Round-Trip Requests. Release aj následná roadmapa túto schému uvádzajú ako náhradu pre elicitation a podobné toky na bezstavových serveroch. Pre architektúru agentických systémov to znamená, že interaktívne kroky sa majú navrhovať ako viac-kolové výmeny správ, nie ako permanentne otvorený stream.

Najviditeľnejší praktický dopad je v škálovaní a v sieťovej vrstve. Júnový text k beta SDK explicitne uvádza, že pri budovaní MCP serverov má byť po novej revízii možné škálovanie cez jednoduchý round-robin load balancer, bez správy sticky sessions a bez zdieľaného session stavu. To nie je nezávisle zmeraný výkonový prínos, ale priamo deklarovaný prevádzkový cieľ autorov zmeny.

Release zároveň zavádza prenášanie názvu metódy a nástroja v hlavičkách Mcp-Method a Mcp-Name. Podľa oficiálneho popisu to má gateway vrstvám umožniť routovanie a autorizáciu priamo podľa hlavičiek. Samostatne sa mení aj správanie zoznamových odpovedí: nesú cache hinty a deterministické poradie, aby klienti vedeli cacheovať katalógy nástrojov a udržať stabilnejšie upstream prompt cache po reconnecte. V praxi teda nejde len o serverový runtime, ale aj o to, ako sa pred server postaví reverse proxy, API gateway a klientská cache.

Dôležitá hranica v interpretácii je medzi vydanou špecifikáciou a migráciou vlastného kódu. Beta SDK boli sprístupnené už 29. júna 2026 pre Python, TypeScript, Go a C#, aby si implementátori vedeli zmeny otestovať ešte pred finálnym dátumom 28. júla. Ten istý zdroj zároveň výslovne uvádza, že existujúce klienty a servery sa týmto dátumom nevypínajú a normatívne vydanie špecifikácie nie je automatický switch-off staršej verzie.

Ekosystémové podklady tiež ukazujú, že deň pred finálnym releasom vyšlo oficiálne Ruby SDK 1.0 so stabilným verejným API, 100 % pass rate v serverových aj klientskych conformance scenároch a podporou starších revízií 2025-06-18 a 2025-11-25; podpora verzie 2026-07-28 bola v tom čase ešte označená ako rozpracovaná. To je pre tímy užitočná pripomienka, že „nová špecifikácia“ neznamená automaticky rovnakú úroveň hotovosti vo všetkých SDK v ten istý deň.

Dodaný balík dobre podkladá dátum vydania, názvy zmien a ich zamýšľaný mechanizmus. Nepodkladá však nezávislé benchmarky, metodiku tvrdení o adopcii ani konkrétne prevádzkové čísla, ktoré by dokazovali o koľko sa zlepšila spoľahlivosť či náklady. Tento text preto treba čítať ako odborný rozbor oficiálne vydanej zmeny a jej pravdepodobného architektonického významu, nie ako nezávislé meranie produkčného dopadu.