Součást série o stavbě cz-agents → pod kapotou
Co se stalo 28. července
Model Context Protocol — standard, přes který jazykové modely přistupují k nástrojům a datům mimo sebe — dostal 28. července 2026 svou největší revizi specifikace od vzniku. Jádro protokolu přešlo z obousměrného, stavového modelu na bezstavové jádro postavené na požadavku a odpovědi. K tomu revize přidala požadavky s více koly komunikace, směrování podle hlavičky Mcp-Method, cacheovatelné výsledky výpisu nástrojů (tools/list), tvrdší autorizaci, formální rámec pro rozšíření a aktualizovanou první řadu oficiálních SDK.
Přeloženo do lidštiny: dřív si klient a server drželi mezi sebou živé, průběžné spojení, ve kterém záleželo na pořadí a na tom, co se stalo předtím. Nově má být každý požadavek pokud možno soběstačný — přijde, dostane odpověď, a tím to hasne. Zní to jako technický detail pro dva lidi na světě. Podle vývojářské komunity to přitom byla jedna z nejžádanějších změn vůbec, a to ze dvou důvodů, na které slyší každý provozovatel: spolehlivost a škálovatelnost.
Proč zrovna tyhle dvě věci bolely nejvíc, se nejlíp ukáže na tom, co „stavový" protokol znamenal pro toho, kdo server drží v provozu.
Co „stavový" protokol reálně stál provozovatele
Když si server musí mezi jednotlivými požadavky pamatovat, kdo jste a kde jste v konverzaci skončili, přestává být jedno, na kterou instanci vás síť pošle. Druhý požadavek musí dorazit na tentýž stroj jako první — jinak dopadne na server, který o vás nic neví. Tomu se říká sticky sessions, přilepené relace, a je to první z řady komplikací, které stavovost tahá za sebou:
- Přilepené relace na load balanceru. Rozdělovač zátěže nesmí požadavky jednoho klienta rozhodit náhodně mezi instance; musí je držet pohromadě. To zužuje možnosti, jak provoz rozkládat, a komplikuje každou aktualizaci, při které se instance vyměňují.
- Sdílené úložiště relací. Aby přežila relace i pád jedné instance nebo její restart při nasazení, stav se typicky ukládá do sdíleného úložiště. To je další komponenta, kterou je nutné provozovat, zálohovat a hlídat — a další místo, kde se dá pokazit konzistence.
- Chytřejší brána. Aby brána vůbec věděla, jak požadavek správně nasměrovat, musela často nahlížet hlouběji do jeho obsahu, ne jen do hlaviček. Víc logiky na bráně znamená víc věcí, které se tam dají rozbít.
Každý z těch tří bodů je sám o sobě zvládnutelný. Dohromady ale tvoří to, čemu se v provozu říká „pohyblivé části" — a platí jednoduché pravidlo: čím víc pohyblivých částí, tím víc věcí, které se ve tři ráno rozbijí. Škálování stavové služby není nemožné, je jen náročnější na pozornost. A pozornost je u provozu ta nejvzácnější měna.
Co bezstavovost mění
Když každý požadavek stojí sám o sobě, celá ta konstrukce se hroutí — v dobrém. Server The Register, který revizi popsal, to shrnuje přesně: server, který dřív potřeboval přilepené relace, sdílené úložiště stavu a hloubkovou inspekci provozu na bráně, teď může běžet za obyčejným round-robin load balancerem, směrovat podle hlavičky Mcp-Method a nechat klienty, ať si výpis nástrojů cacheují u sebe.
Rozeberme to po kouskách, protože každý z nich ubírá jednu pohyblivou část:
- Obyčejný rozdělovač zátěže. Když je jedno, na kterou instanci požadavek dopadne, stačí je střídat dokola. Přilepené relace mizí, a s nimi i celá třída problémů kolem nasazování a výpadku jednotlivé instance.
- Směrování podle hlavičky. Brána se rozhoduje podle
Mcp-Methodv hlavičce, ne podle rozebrání celého těla požadavku. To je levnější, průhlednější a spolehlivější — hlavičku umí přečíst i hloupá brána. - Cacheovatelný výpis nástrojů. Seznam nástrojů, který server nabízí, se nemění při každém dotazu. Když si ho klient smí uložit, ubyde opakovaných dotazů, na které server pokaždé odpovídá totéž. Míň zbytečné práce na obou koncích.
Souhrn zní stejně nudně jako celá revize: míň pohyblivých částí znamená míň věcí, co se rozbije. Sdílené úložiště stavu, které bylo nutné jen kvůli relacím, může u části nasazení odpadnout úplně. To není nová funkce, kterou by šlo prodat na billboardu. Je to ubraná složitost — a ubraná složitost je přesně to, za co provozovatel platí nejraději.
Checklist pro přechod, obecně
Tady musím být poctivý ohledně toho, o čem píšu a o čem ne. Nepopisuju, jak mám postavené vlastní servery — to si nechám pro sebe. Popisuju, na co by se měl podívat kdokoli, kdo dnes provozuje stávající MCP server a zvažuje přechod na bezstavové jádro. Body níž platí obecně, ať běží kdekoli:
- Najděte, kde se spoléháte na stav. První otázka není technická, ale inventurní: co si dnes server mezi požadavky pamatuje? Průběh konverzace, autentizovaná relace, rozdělaná vícekroková operace? Každé takové místo je kandidát na přepis — buď stav zmizí, nebo se musí přenášet v každém požadavku.
- Počítejte s tím, že sdílené úložiště relací může odejít. Pokud existovalo jen kvůli přilepeným relacím, bezstavovost pro ně odstraní důvod. To je úspora, ale i migrace: než ho vypnete, musíte si být jistí, že na něm nevisí ještě něco jiného.
- Projděte autorizaci, protože se zpřísnila. Revize přitáhla autorizaci, ne uvolnila. To znamená práci navíc, ne míň: ověřit, že se každý požadavek autorizuje sám za sebe, když už se nemůže opřít o kontext dřívější relace. Tady bych spěchal nejmíň a četl specifikaci nejpozorněji — autorizace je místo, kde chyba nestojí latenci, ale bezpečnost.
- Zapněte cacheování výpisu nástrojů uvážlivě. Cacheovatelný
tools/listšetří práci, ale znamená, že klienti mohou nějakou dobu vidět starší seznam nástrojů. Pokud se vaše nabídka nástrojů mění, je potřeba promyslet, jak dlouho smí být výpis starý — jinak si klient zavolá nástroj, který jste už stáhli. - Ověřte requesty s více koly. Bezstavovost neznamená, že každá operace je jeden jediný požadavek. Revize výslovně počítá s vícekolovou komunikací; jen musí být z každého požadavku zřejmé, do jaké operace patří, bez opory ve sdíleném stavu.
Žádný z těch bodů není raketová věda. Dohromady jsou to ale přesně ta místa, kde tichý přechod „ono to nějak pojede" skončí u požadavku, který dopadne na instanci bez kontextu — a selže způsobem, který se v testu s jednou instancí nikdy neukáže.
Širší kontext: MCP dospěl
Tahle revize dává smysl teprve ve světle toho, kam se MCP za rok posunul. Z nástroje, který se hodil hlavně na lokální propojení modelu s pár skripty na jednom stroji, se stal distribuovaný protokol — a distribuovaný protokol má úplně jiné starosti. Sticky sessions nikoho netrápí, dokud běží jedna instance na jednom notebooku. Začnou bolet přesně ve chvíli, kdy služba běží ve více instancích za bránou a musí přežít nasazení bez výpadku. Revize je tedy odpovědí na dospělost, ne na módu.
Tu dospělost potvrzují i čísla, která nejdou přehlédnout. První řada oficiálních SDK stahuje řádově půl miliardy stažení měsíčně; knihovny pro TypeScript i Python překročily každá miliardu stažení celkem. Do poloviny roku 2026 protokol podle dostupných přehledů adoptovali OpenAI, Google DeepMind, Microsoft i AWS a stovky podnikových dodavatelů. To už není hračka nadšenců.
A hlavně: protokol přešel pod neutrální správu. Stará se o něj Agentic AI Foundation, fond při Linux Foundation, mezi jehož platinovými členy jsou vedle Anthropicu i OpenAI, Block, Google a Microsoft. Pro toho, kdo na standardu staví, je tohle důležitější než jakákoli jednotlivá funkce. Znamená to, že protokol není majetkem jedné firmy, kterou může jeden strategický obrat donutit změnit pravidla pod rukama. Stabilita standardu je hodnota sama o sobě — a pro provozovatele možná ta nejcennější.
Co si z toho beru
Tahle změna je nudná, a to je na ní to nejlepší. Nepřidává featuru, kterou bych mohl komukoli ukázat na obrazovce. Ubírá složitost, kterou nikdo nevidí, dokud se nerozbije. Bere protokol, který začal jako chytré lokální propojení, a dělá z něj infrastrukturu, která se chová jako každá jiná dobře navržená síťová služba: požadavek dovnitř, odpověď ven, žádná skrytá paměť mezi tím.
Pro toho, kdo servery provozuje, je to přesně ten druh zprávy, který má rád — protože nezní vzrušeně. Vzrušené zprávy v provozu obvykle znamenají, že se něco pokazilo, nebo že někdo přidal funkci, kterou bude potřeba dva roky hlídat. Tahle zpráva říká opak: bude míň věcí k hlídání. Míň pohyblivých částí, míň nočních vzbuzení, jednodušší cesta od jedné instance ke stovce.
Jestli si z toho má někdo mimo úzký kruh provozovatelů něco odnést, pak tohle: standard, na kterém se dnes staví agentní nástroje, právě udělal krok od „chytré, ale křehké" k „nudné, ale pevné". A když si vybírám, na čem postavím něco, co má běžet roky, beru nudné a pevné pokaždé.
Zdroje: Oznámení revize na blogu Model Context Protocol (28. 7. 2026) a rozbor The Register (29. 7. 2026). Provozní úvahy v tomto textu jsou obecné — popisují, co revize mění pro provozovatele MCP serverů obecně, ne konkrétní nasazení.
Zvažujete, jak agentní nástroje a MCP zapojit do vlastního provozu? → AI konzultace