MCP se stal bezstavovým: zmizel úvodní handshake i hlavička se session

Když si dnes chatovací aplikace potřebuje sáhnout do kalendáře, do databáze nebo do repozitáře, může k tomu použít MCP, Model Context Protocol. Podporují ho Claude i ChatGPT a z vývojářských nástrojů třeba Visual Studio Code nebo Cursor. Jeho nová specifikace, označená 2026-07-28, vyšla 28. července a mění na něm to nejzákladnější.

Co se změnilo

Autoři to shrnují jednou větou: „MCP se mění z obousměrného stavového protokolu na bezstavový protokol typu požadavek–odpověď“ (přeloženo). Prakticky to znamená, že „jsme oficiálně vyřadili výměnu initialize/initialized spolu s hlavičkou Mcp-Session-Id“ (přeloženo).

Co přesně si obě strany v úvodním pozdravu vyměňovaly, oznámení nerozvádí. Píše ale, co se děje místo toho: „Každý požadavek teď putuje sám za sebe a nese svou verzi protokolu, identitu klienta a jeho schopnosti v poli _meta“ (přeloženo). Kdo potřebuje zjistit schopnosti serveru předem, má na to nové volání server/discover.

Proč to někoho zajímá

Rozdíl je vidět až ve chvíli, kdy takový server někdo provozuje pro víc než jednoho člověka. Se stavovým protokolem musely všechny požadavky jednoho klienta dojít na tutéž instanci serveru – jinde by jeho relace nebyla. Tomu se říká sticky sessions a znamená to buď chytřejší load balancer, nebo sdílené úložiště relací pro všechny instance.

Bez relace tenhle požadavek mizí. Autoři to shrnují tak, že „kterýkoli požadavek může dopadnout na kteroukoli instanci za obyčejným round-robin load balancerem“ (přeloženo) – tedy za rozdělovačem, který posílá požadavky do kola bez ohledu na to, kdo je poslal.

Co se dá poznat z hlavičky

Z bezstavovosti plyne druhá praktická věc. Požadavek nese v hlavičkách Mcp-Method a Mcp-Name, o jakou metodu a o jaký nástroj jde. Brána, omezovač provozu nebo aplikační firewall tak podle autorů může směrovat a měřit podle nich, místo aby rozebírala tělo v JSONu.

Podobně cílí i další novinka: odpovědi na výpisy nástrojů, promptů a zdrojů teď nesou položky ttlMs a cacheScope, aby si klient mohl určit, jak dlouho a v jakém rozsahu si je smí schovat, a nestahoval je pokaždé znovu.

Co to rozbije

Toto je ta část, kterou oznámení o vydáních obvykle nepíšou nahlas. Podle rozboru na Stacktree čeká server postavený na staré specifikaci trojí práce: opustit sdílené úložiště relací, číst verzi protokolu a schopnosti z pole _meta u každého požadavku a doplnit metodu server/discover. Kdo používá dlouhoběžící úlohy, musí přejít na rozšíření Tasks a výsledek si vyzvedávat dotazem, místo aby čekal na odpověď.

Vydání nové verze ale není vypnutí té staré. Servery a klienti na specifikaci z listopadu 2025 podle autorů fungují dál. Vlastnosti označené za zastaralé – Roots, Sampling, Logging a starý přenos přes HTTP a SSE – mají zůstat ve specifikaci nejméně dvanáct měsíců.

Rozšíření místo verzí

Druhá změna je organizační. Novinky, které nepatří do jádra, se dělají jako rozšíření s identifikátorem v obráceném tvaru doménového jména a vlastním číslováním verzí, nezávislým na specifikaci samotné.

Dvě z nich jsou vidět nejvíc. MCP Apps dovolují serveru poslat interaktivní HTML rozhraní, které hostitelská aplikace vykreslí v odděleném rámu. Tasks řeší úlohy, které trvají déle než jedno volání: server na požadavek odpoví úchytem úlohy a klient si pak chodí pro výsledek.

Kdo za tím stojí

Specifikaci vedou dva správci, David Soria Parra a Den Delimarsky. Kdo protokol původně vytvořil, ani jeden z použitých zdrojů neuvádí; dokumentace ho popisuje jako otevřený standard a mezi podporovanými klienty jmenuje Claude, ChatGPT, Visual Studio Code i Cursor. Spolu se specifikací vyšly aktualizované sady SDK první úrovně.

Náš názor: přepsat protokol do bezstavové podoby takhle brzy vypadá spíš na to, že původní návrh mířil na spojení jednoho klienta s jedním serverem, kdežto provoz si vyžádal něco, co unese běžná webová infrastruktura.

Zdroje: oznámení na blogu MCP (28. července 2026) a rozbor změn na Stacktree.