Model Context Protocol dosáhl významného milníku infrastruktury: jeho revize z 28. 7. 2026 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í bezstavového jádra 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 uvedla, že její MCP server již novou specifikaci podporuje a 28. července popsal protokol jako „bezstavový“.
Praktický význam je přímočarý: MCP je méně formován jako vrstva pro připojení k internetu s velkým množstvím relace a spíše jako protokol pro vzdálený přístup k internetu 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 k jádru bezstavového protokolu. V changelogu GitHub se uvádí, ž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 poskytuje implementátorům větší svobodu provozovat MCP servery 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í spravovaného výpočtu namísto vlastní dlouhodobé 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 explicitnějším, pokud jde o dlouhodobější práci. MCP Aplikace a posílení autorizace míří stejným směrem: protokol dozrává z raného ekosystémového spojení 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řevratnými změnami a materiály TypeScript a C# SDK publikované kolem revize se zaměřují na podporu migrace a bezstavové koncepty. Jakýkoli tým provozující server MCP, vkládá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 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 výroby musí zachovat stav napříč těmito interakcemi nebo vytvořit náhradní řešení kolem protokolu.
Odstraněním relací z jádra MCP lépe vyhovuje prostředím, kde je zátěž agentů nárazová, 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í serverů vzdálených 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žadavku, latenci volání nástroje, rozhodnutí o autorizaci a vzory chyb.
Existuje také úhel řízení. Vzhledem k tomu, že MCP se 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 nástrojů, které mohou agenti volat, k jakým datům mají přístup a kteří uživatelé nebo služby je mohou používat. Zpevnění Authorization v nové revizi proto není náhodné. Odráží skutečnost, že přístup k nástroji 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 MCP správci serverů, SDK uživatelé, týmy platformy agentů a organizace, které agentům AI vystavují interní nástroje. 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 častěji objevuje vedle kódovacích agentů, vlastní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í.
Firmy využívající automatizaci agentů by měly věnovat pozornost, i když si nikdy nepřeč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í ověřování nebo agenti, kteří se vydávají jinou cestou, protože server nástroje se již nechová podle očekávání.
Pro bránu AI API, jako je Model Gate, je připojení praktické. Jednotná umělá inteligence API se stále více přibližuje směrování modelů, API správě klíčů, analýze využití a správě týmu API. Protože systémy agentů přidávají MCP volání nástrojů vedle běžných volání modelů, 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 stojí, 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, zejména pokud agenti provádějí akce s vedlejšími účinky, jako je vytváření požadavků na stažení, úpravy problémů, dotazování 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ástroji by měl být ve výchozím nastavení nejméně privilegovaný, zejména u vzdálených MCP nasazení.
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 se specifikacemi, SDK materiály k migraci a poznámku k implementaci GitHub. 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ů protokolu 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.