MCP 2026–07–28: proč remote MCP server nemá jen upgradovat SDK

Nová revize Model Context Protocol 2026-07-28 je zásadnější, než vypadá z názvu. MCP vzniklo v Anthropic, dnes se vyvíjí jako otevřený projekt. Nejde o „nový konektor do Claude“. Mění se způsob, jakým remote MCP klient a server navazují spojení, nesou metadata a řídí dlouhé interakce.

Pokud jen používáte hotové MCP servery v Claude, Codexu nebo ChatGPT, nemusíte dnes nic dělat: implementace mají vyjednávat nejvyšší společnou verzi a starší protokol zůstává podporovaný. Pokud ale provozujete vlastní remote MCP server nad CRM, ERP, dokumenty nebo interními nástroji, je správný čas zkontrolovat architekturu.

Co se mění

Discovery místo `initialize`

Starší MCP začíná initialize handshakem a server si drží stav relace. Nová revize zavádí server/discover: klient nejdříve zjistí podporované verze a capability. Verze protokolu, informace o klientovi a jeho schopnosti se nesou v _meta u každého requestu.

To je dobré pro horizontální škálování. Server nemusí spoléhat na to, že další request přijde na stejný proces či pod. Zároveň to znamená, že nelze nechat autentizaci, autorizaci a audit „někde v session“.

Stateless HTTP není kosmetika

Streamable HTTP může běžet bez session. Pro produkční endpoint to zjednodušuje load balancing, retry a provoz přes běžnou gateway. Na druhé straně musíte mít v každém requestu dohledatelnou identitu, tenant, scope a korelační ID.

Praktický minimální návrh pro interní MCP server:

gateway ověří OAuth token nebo service identity,
autorizace mapuje identitu na konkrétní tenant a povolené tools,
server dostane request context s correlation ID,
tool call zapíše audit: kdo, jaký tool, nad jakým objektem, s jakým výsledkem,
idempotentní nebo vícekolové operace mají vlastní request state v databázi či frontě, ne jen v paměti procesu.

Vícekolové requesty

Nové multi-round-trip requests nahrazují starší serverem iniciované chování. Dlouhá nebo interaktivní práce se tak má lépe skládat přes explicitní request/response kroky. To je užitečné například pro agenta, který potřebuje doplnit volbu uživatele, potvrdit cílový účet před odesláním faktury nebo pokračovat v exportu po dokončení dávky.

Nevyužívejte to jako záminku pro nekonečnou konverzaci. Každý krok musí mít timeout, limit pokusů a stav, který umíte obnovit.

Rozšíření a deprecated capability

Revize formalizuje extension vrstvu a upozadňuje část starších capability, mimo jiné Roots, Sampling a Logging. To neznamená hromadné vypnutí serverů. Znamená to rozlišit: co je skutečně součást vašeho API kontraktu, co je pouze pohodlí konkrétního klienta a co potřebujete nahradit vlastním auditním či konfiguračním mechanismem.

Migrace bez přerušení provozu

Sepište klienty a SDK. Zjistěte, kdo váš server volá, jakou verzi vyjedná a zda SDK už umí 2026-07-28.
Nechte běžet kompatibilitu. Nová implementace má umět sestoupit na 2025-11-25 a starší klienti mají dál použít legacy handshake.
Odstraňte session závislosti. Stav importu, potvrzení i rate limitů přeneste do odolného uložiště. Neodvozujte oprávnění z náhodného session ID.
Otestujte přes gateway. Zkuste retry na jiném podu, expirovaný token, změnu tenantů, paralelní requesty a odpojení klienta uprostřed vícekolové operace.
Měřte migration, ne jen HTTP 200. Sledujte podíl klientů na nové verzi, failed discovery, fallbacky na starou verzi, authorization denials a neúplné requesty.

Co s tím udělat tento týden

Vytáhněte seznam vlastních remote MCP endpointů a odpovězte si na tři otázky: drží server něco důležitého jen v RAM relace? Je každé volání auditovatelné od identity až po konkrétní firemní objekt? A funguje korektně, když retry skončí na jiném serveru?

Jestli je odpověď na některou z nich ne, nezačínejte přepisem všech toolů. Udělejte jeden reprezentativní tool — třeba vyhledání faktury nebo read-only CRM lookup — stateless, s gateway autorizací a důkazním logem. Teprve pak migrujte akční tools, kde přidáte lidské schválení a idempotency klíč.