Když jsme před rokem nasazovali první MCP servery pro našeho AI agenta, běžel každou instanci na jednom stroji a load balancer držel sticky session, aby všechny požadavky z jednoho klienta padaly na stejné instance. Fungovalo to, ale horizontální škálování byla noční můra. Specifikace 2026-07-28, která finalizovala 28. července 2026, ten problém řeší tím nejjednodušším možným způsobem: sessiony z protokolu úplně mizí.
V tomto článku ti ukážu, co se přesně změnilo, jak to ovlivní tvoji produkční infrastrukturu a jak migrovat, aniž bys rozbil stávající agenty.
Co se vlastně změnilo
Největší změna od spuštění MCP vůbec. Do verze 2025-11-25 musel klient před každým voláním nástroje (tool) inicializovat session. Server vrátil hlavičku Mcp-Session-Id, kterou klient musel posílat u každého dalšího requestu. To znamenalo, že jsi nemohl prostě hodit tři instance za round-robin load balancer — každý klient byl "připnut" k jedné instanci přes sticky routing a všechny instance musely sdílet session store (typicky Redis), aby si rozuměly.
Nová verze celou tuhle vrstvu maže. Žádné initialize/initialized handshake. Žádný Mcp-Session-Id. Místo toho jede každý request jako samostatná, soběstačná jednotka. Verze protokolu, info o klientovi a schopnosti cestují v _meta přímo v těle každého volání. Nová metoda server/discover umožňuje klientovi získat schopnosti serveru, když je potřebuje — místo aby si je držel v session.
Praktický dopad je okamžitý: remote MCP server může běžet za obyčejným round-robin load balancerem bez session storage. To je rozdíl, který ti ušetří hodiny konfigurace a hlavně peníze za infrastrukturu.
Před a po — konkrétní rozdíl
Podívejme se na to na requestech. Starý způsob (2025-11-25):
POST /mcp HTTP/1.1
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"initialize",
"params":{"protocolVersion":"2025-11-25","capabilities":{},
"clientInfo":{"name":"my-app","version":"1.0"}}}
Server odpoví session ID, které pak musíš nosit dál:
POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json
{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"}}}
Nový způsob (2026-07-28) — jeden self-contained request, který zpracuje jakákoliv instance:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}
Všimni si tří věcí: žádná session hlavička, nová hlavička MCP-Protocol-Version určuje verzi, a _meta nese kontext klienta. To znamená, že load balancer může routovat každý request na jinou instanci a nikdo si nevšimne.
Co to znamená pro tvoji produkci
Tady jsou konkrétní změny, které pocítíš v infrastruktuře:
1. Můžeš zahodit Redis session store. Pokud jsi provozoval cluster MCP serverů se sdíleným session storagem (Redis, Memcached), už ho pro MCP nepotřebuješ. Session je pryč z protokolu. Snížíš tím provozní složitost i náklady.
2. Load balancing se zjednoduší. Round-robin, least-connections, čistý HTTP load balancing — všechno funguje out of the box. Žádné sticky cookies, žádné IP hash. Cloudflare, nginx, AWS ALB — všude to nasadíš bez speciální konfigurace.
3. Cacheovatelnost. Protože každý request nese všechnu potřebnou metadata v _meta a hlavičkách, můžeš odpovědi na tools/list cacheovat na úrovni CDN nebo reverzní proxy. Server hlásí ttlMs, takže víš, jak dlouho cache platí. Pro často volané servery s mnoha klienty to dramaticky snižuje zátěž.
4. Traceability a routování. Nová hlavička Mcp-Method umožňuje routovat traffic podle typu volání. Pokud chceš například tool cally (tools/call) posílat na výkonnější instance a discovery (server/discover) na lacinější, můžeš to udělat na úrovni gateway.
Jak migrovat bez výpadku
Specifikace 2026-07-28 obsahuje breaking changes. Nemůžeš prostě překlopit přepínač. Tady je postup, který doporučuji pro produkční nasazení:
Krok 1: Audit stávajících klientů a serverů
Nejprve zjisti, co vlastně používáš. Pokud máš klienty na starém SDK, neumí nový protokol. Tier 1 SDK (oficiální od Anthropicu, TypeScript, Python) by měly mít podporu do deseti týdnů od release candidate (RC byl 21. května 2026, final 28. července). Pokud používáš komunitní SDK nebo vlastní implementaci, počítej s vlastní prací.
Krok 2: Verzování na úrovni gateway
Nejjednodušší migrace: spusť nové servery na jiném endpointu nebo portu a nech gateway (nginx, Cloudflare Worker) routovat podle hlavičky MCP-Protocol-Version. Starí klienti (2025-11-25) jdou na legacy instanci se session supportem, noví na stateless infrastrukturu. Postupně klienty migruj.
# Ukázka routování podle verze protokolu
map $http_mcp_protocol_version $mcp_backend {
default legacy_backend;
"2026-07-28" stateless_backend;
}
server {
location /mcp {
proxy_pass http://$mcp_backend;
}
}
Krok 3: Nahraď session state explicitními handly
Tady je kognitivní skok, který většina týmů podcení. To, že protokol nezachovává session, neznamená, že tvoje aplikace nemůže mít stav. Pokud tvůj server potřebuje držet kontext napříč voláními (například rozpracovaný nákupní košík pro agenta), řešení je pattern explicit handle:
- Agent zavolá
create_basket→ server vrátíbasket_id. - Agent předává
basket_idjako argument v dalších voláních (add_item,checkout).
Model (Claude, GPT) si handle nese v kontextu konverzace a předává dál. To je vlastně mocnější než skrytý session state, protože si ho model může composovat napříč nástroji, rozumět mu a předávat ho mezi kroky způsobem, jakým to externí session metadata nikdy neumožňovala.
Prakticky: pokud máš dnes server, který si drží session_id → user_state mapu, refaktoruj ji na tool argumenty. Stav se přesune do viditelné části protokolu místo transportní vrstvy.
Krok 4: Přidej approval step pro write operace
Stateless neznamená bezpečnější samo o sobě. Nová specifikace tvrdí, že server-initiated requesty (jako elicitation prompty) smějí proběhnout jen během aktivního zpracování klientova requestu — nikdy samy od sebe. To je dobré pro UX (uživatel nedostane prompt zničeho), ale nezastaví to agenta, který má write práva na produkční databázi.
Pokud nasazuješ MCP server s write přístupem do produkčních systémů, přidej explicitní approval krok — buď v agent runtime (Claude Code to umí nativně), nebo na úrovni samotného serveru (HTTP middleware, který u write operací vyžaduje druhý faktor nebo human-in-the-loop webhook).
Které servery nasadit jako první
Pokud s MCP teprve začínáš nebo aktualizuješ stack, doporučuji začít minimalisticky. Každý server, který nainstaluješ, přidává do promptu nástroje a rozšiřuje attack surface. Zaměř se na tři kategorie podle toho, co denně řešíš:
- GitHub MCP — pro týmy, co žijí v pull requestech, issue a Actions. Oficiální, udržované, s podporou security findingů a Dependabotu. Jako první ho nasazuje většina týmů.
- Filesystem MCP — referenční server pro lokální soubory. Scoped přístup k adresářům, které explicitně povolíš. Tichý workhorse za většinou lokální agentské práce.
- Jeden databázový server — pro Supabase backend
Supabase MCP(respektuje Row Level Security), pro hlubší Postgres práciPostgres MCP Pro(přidává index tuning, query plan review, health checky).
Po týdnu pilotu s reálnými workflow zjistíš, které nástroje agent opravdu používá. Zbytek odstraň. Tři až pět serverů obvykle porazí dlouhý seznam.
Na co si dát pozor
Migrace není jen technická. Tady jsou reálná úskalí, na která jsme narazili:
Komunitní SDK může zaostávat. Oficiální SDK jsou rychlé, ale pokud spoléháš na menší knihovny, ověř si podporu 2026-07-28 ještě před plánovaným přechodem. Verze protokolu je v hlavičce, takže mismatch uvidíš hned jako 400.
Logging framework se mění. Roots, Sampling a Logging jsou v nové specifikaci deprekovány. Pokud jsi na nich stavěl observabilitu, připrav si náhradu — pravděpodobně přes structured logging na úrovni aplikace a tracing přes standardní HTTP nástroje (OpenTelemetry), které teď fungují lépe díky stateless povaze.
OAuth zarovnání. Autorizace se více přibližuje OAuth a OpenID Connect deploymentům. Pokud máš custom auth middleware, zkontroluj ho proti nové specifikaci — token lifecycle a scope handling se mění.
Conformance suite. Nová specifikace zavádí to, že Standards Track SEP nemůže dosáhnout Final statusu, dokud neexistuje odpovídající scénář v conformance suite. Pro tebe to znamená: SDK, které projde conformance testy, je sázka na jistotu. Hledej ten badge.
Závěr
Specifikace 2026-07-28 je největší revize MCP od spuštění a pro produkční nasazení je to všeobecně dobrá zpráva. Stateless jádro znamená jednodušší škálování, levnější infrastrukturu a standardnější HTTP patterns. Extensions framework (Tasks, MCP Apps) dává prostor pro nové schopnosti bez nutnosti čekat na core release.
Pokud dnes provozuješ MCP servery se session storage a sticky routingem, plánuj migraci. Není to přepínač, ale gatewayový přístup s verzováním podle MCP-Protocol-Version tě provede bez výpadku. A pokud teprve začínáš — máš štěstí. Stavíš na jednodušším fundamentu, než měli jsme loni.
Začni se třemi servery (GitHub, Filesystem, jeden databázový), běž týden v pilotu a rozšiřuj jen to, co se osvědčí. Stateless protokol ten tlak na komplexnost trochu uleví — protože čím méně moving parts, tím méně věcí, co se může v produkci rozbít.
