Model Context Protocol dosáhl významného infrastrukturního milníku: jeho revize 2026-07-28 posouvá protokol směrem k bezstavovému jádru. Pro týmy vytvářející systémy agentů, servery nástrojů, integrace IDE nebo vícemodelové orchestrační vrstvy se nejedná o kosmetickou aktualizaci specifikací. Mění předpoklady o relacích, inicializaci, škálování, kompatibilitě a správě.
Kandidát na vydání MCP popsal specifikaci z 28. července jako přidání jádra bezstavového protokolu, rámce rozšíření, úkolů, aplikací MCP, posílení autorizace a formální zásady ukončení podpory. Oficiální blog MCP také varoval, že vydání obsahuje zásadní změny. GitHub, který provozuje jednu z nejviditelnějších implementací MCP serverů, před finálním vydáním uvedl, že jeho MCP Server již podporuje novou specifikaci a popsal protokol jako „bezstavový“ 28. července.
Praktický význam je přímočarý: MCP je formován méně jako lokální integrační vrstva náročná na relace a spíše jako internetový protokol pro vzdálený přístup k nástrojům. To je důležité, protože systémy agentů již nejsou omezeny na nástroje pro vývojáře desktopů. Stále častěji běží v rámci cloudových služeb, systémů CI, pracovních postupů zákaznické podpory, sledovačů problémů a platforem podnikové automatizace.
Co se změnilo v MCP
Hlavní změnou je přechod na jádro bezestavového protokolu. Changelog GitHubu říká, že nové jádro odstraňuje relace a inicializuje s cílem usnadnit škálování vzdálených nasazení MCP. Jde o významný architektonický posun. Stavové protokoly mohou dobře fungovat pro místní nástroje a kontrolovaná prostředí, ale komplikují horizontální škálování, spouštění bez serveru, převzetí služeb při selhání, nasazení okrajů a vyvažování zátěže.
Bezstavové jádro dává implementátorům větší svobodu provozovat servery MCP za běžnou webovou infrastrukturou. Požadavky lze distribuovat mezi instancemi bez zachování dlouhodobé relace na konkrétním backendu. Pro velké organizace to může snížit provozní složitost. Menším týmům to může usnadnit nasazení hostovaných serverů MCP pomocí řízeného výpočtu namísto vlastní dlouhotrvající infrastruktury.
Širší vydání 2026-07-28 také zavádí rámec rozšíření a úkoly, podle materiálů kandidátů na vydání. Tyto doplňky naznačují, že MCP se stává modulárnějším a jasnějším, pokud jde o dlouhodobější práci. MCP Apps a posílení autorizace míří stejným směrem: protokol dozrává z raného ekosystémového lepidla do formálnější vrstvy pro interakci agent-nástroj.
Cena tohoto zrání je práce na kompatibilitě. Blog MCP charakterizoval vydání jako vydání s přelomovými změnami a materiály TypeScript a C# SDK publikované kolem revize se zaměřují na podporu migrace a bezstavové koncepty. Každý tým provozující server MCP, zabudování MCP do rozšíření IDE nebo směrování volání agentů prostřednictvím interní infrastruktury by měl revizi považovat za technickou událost, nikoli za aktualizaci standardů na pozadí.
Proč je bezstavové MCP důležité pro vývojáře a operátory
Nástroje agenta mají problém se škálováním, který vypadá jinak než běžné škálování rozhraní API. Jediný požadavek uživatele může spustit mnoho volání nástrojů, otočení modelu, opakování, čtení souborů, vyhledávací dotazy a schvalovací kroky. Když protokol nástroje předpokládá trvalé relace, operátoři musí zachovat stav napříč těmito interakcemi nebo vytvořit náhradní řešení kolem protokolu.
Odstraněním relací z jádra se MCP lépe hodí do prostředí, kde jsou zátěže agentů hromadné, distribuované a asynchronní. Bezserverové funkce, okrajoví pracovníci, nasazení Kubernetes a multiregionální systémy – to vše těží z toho, když lze požadavky zpracovávat nezávisle. To nevylučuje stav z aplikací agentů; přesouvá stav do aplikačních databází, front úloh, systémů identit nebo explicitních vrstev pracovních toků místo toho, aby jej vkládal do jádra protokolu.
Vývojářům by tato změna nakonec měla usnadnit používání vzdálených serverů nástrojů. Platformovým týmům to může zjednodušit pozorovatelnost a plánování kapacity. Namísto ladění neprůhledného chování souvisejícího s relacemi se operátoři mohou zaměřit na trasování na úrovni požadavků, latenci volání nástroje, rozhodnutí o autorizaci a vzory chyb.
Existuje také úhel řízení. Vzhledem k tomu, že se MCP stává běžnějším u asistentů kódování a podnikových agentů, společnosti budou potřebovat zásady týkající se toho, jaké nástroje mohou agenti volat, k jakým datům mají přístup a kteří uživatelé nebo služby je mohou používat. Zpřísnění autorizace v nové revizi tedy není náhodné.Odráží skutečnost, že přístup k nástrojům je nyní hranicí zabezpečení, nikoli pouze pohodlím pro vývojáře.
Koho se to týká
Nejvíce postiženými skupinami jsou správci serverů MCP, uživatelé SDK, týmy platformy agentů a organizace vystavující interní nástroje agentům AI. Pokud server závisí na chování relace nebo starších inicializačních tocích, bude potřebovat testování podle nové specifikace. Pokud aplikace podporuje více verzí MCP, může vyžadovat vyjednávání o verzi, vrstvy kompatibility nebo plán postupné migrace.
Do rozsahu spadají také dodavatelé IDE a vývojářských nástrojů. MCP se stále více objevuje vedle kódovacích agentů, uživatelských agentů a funkcí pro správu modelů. Bezstavové jádro protokolu těmto produktům usnadňuje spolehlivé volání vzdálených nástrojů, ale pouze v případě, že jejich integrace drží krok se specifikací.
Podniky využívající automatizaci agentů by měly věnovat pozornost, i když nikdy nečtou specifikaci MCP. Změna může ovlivnit spolehlivost agentů, kteří se připojují k úložištím, ticketovacím systémům, databázím, interním znalostním bázím nebo nástrojům pro nasazení. Během období migrace nejsou pravděpodobnými režimy selhání pouze zjevné výpadky. Mohou zahrnovat chybějící funkce nástroje, změněné chování autentizace nebo agenti, kteří se vydávají různými cestami, protože server nástrojů se již nechová podle očekávání.
U brány AI API, jako je Model Gate, je připojení praktické. Jednotné rozhraní AI API se stále více přibližuje směrování modelů, správě klíčů API, analýze využití a správě týmového rozhraní API. Jak systémy agentů přidávají volání nástrojů MCP vedle běžných volání modelu, vrstvy brány a pozorovatelnosti budou muset zohlednit obě strany pracovního postupu: který model byl použit, které nástroje byly vyvolány, kolik stály, kdo je autorizoval a kde došlo k selhání.
Priority migrace a otevřené otázky
První prioritou migrace je testování kompatibility. Týmy by měly inventarizovat klienty a servery MCP, identifikovat závislosti na relacích nebo inicializovat chování a testovat proti sadám SDK 2026-07-28 nebo materiálům o shodě, pokud jsou k dispozici. Produkční systémy by měly provést upgrade, zvláště pokud agenti provádějí akce s vedlejšími účinky, jako je vytváření požadavků na stažení, úpravy problémů, dotazování se na zákaznická data nebo provádění pracovních postupů nasazení.
Druhou prioritou je pozorovatelnost. Bezstavovou infrastrukturu lze snadněji škálovat, ale systémy distribuovaných agentů stále potřebují ID korelace, zachycení trasování, protokoly požadavků a události zásad. Bez nich mohou týmy vyměnit složitost relace za složitost ladění. Analýza využití by měla rozlišovat mezi voláním modelu a voláním nástrojů, zvláště když jsou pracovní postupy agentů fakturovány, omezeny sazbou nebo auditovány týmem.
Třetí prioritou je kontrola autorizace. Pokud nová specifikace zpřísní autorizační sémantiku, implementátoři by neměli jednoduše přenést staré přístupové předpoklady do nové verze. Měli by znovu zkontrolovat rozsahy tokenů, delegování uživatelů, účty služeb, protokoly auditu a chování odmítnutí. Přístup k nástrojům by měl být ve výchozím nastavení nejméně privilegovaný, zejména pro vzdálená nasazení MCP.
Některé podrobnosti stojí za to zkontrolovat, než organizace přijmou nevratná rozhodnutí o návrhu. Výzkum dostupný pro tento článek zahrnoval kandidáta na vydání, stránku specifikací, materiály pro migraci SDK a poznámku k implementaci GitHubu. Konečné normativní znění specifikace 2026-07-28 by mělo být přezkoumáno přímo před uvedením přesných požadavků na protokol v interních normách nebo zákaznické dokumentaci.
I přes toto upozornění je směr jasný. MCP se stává více produkčně orientovaným protokolem pro infrastrukturu agentů. Bezstavové jádro by mělo usnadnit škálování vzdálených nasazení, ale také nutí ekosystém očistit předpoklady z dřívějších implementací. Pro týmy budované s agenty je to druh změny protokolu, který si zaslouží lístek na sprint, nikoli jen záložku.