MCP bez sessions: co rozbije revize 2026-07-28 a jak migrovat

Revize Model Context Protocolu z 28. července 2026 je největší zásah od vzniku protokolu. Není to přírůstek featur, je to škrtání — a to škrtání mění, jak se MCP server hostuje.

Sám stavím read-only MCP server nad observability stackem pro banku. Implementace v době, kdy tahle revize přistála, ještě nezačala, což se ukázalo jako štěstí: návrh hostingu, který jsme měli schválený, byl po revizi zbytečně složitý. Tenhle článek je to, co jsem si z revize musel vytáhnout, abych ten návrh opravil.

Co zmizelo

Verze protokolu a schopnosti klienta se místo handshake nesou v _meta u každého requestu. Server tedy nic nepamatuje mezi voláními — každý request nese všechno, co server potřebuje vědět.

Důsledek, kvůli kterému to je dobrá zpráva

Vzdálený MCP server je teď obyčejný HTTP workload.

Do 28. července 2026 to byl speciální případ. Session znamenala stav, stav znamenal sticky sessions, sticky sessions znamenaly session affinity na load balanceru — nebo sdílené úložiště sessions, typicky Redis, se všemi otázkami kolem jeho dostupnosti a latence.

Teď nic z toho. Server může stát za round-robin balancerem, škálovat na nulu, běžet v tolika replikách, kolik chcete, a je jedno, na kterou instanci request dopadne.

V Azure to znamená konkrétní změny v konfiguraci. Pokud jste na Container Apps, session affinity můžete vypnout:

resource mcpServer 'Microsoft.App/containerApps@2024-03-01' = {
  name: 'ca-mcp-observability'
  properties: {
    configuration: {
      ingress: {
        external: false          // za private endpointem
        targetPort: 8080
        transport: 'auto'
        // Před revizí: affinity 'sticky', protože session žila v instanci.
        // Po revizi: není co lepit, každý request stojí sám o sobě.
        stickySessions: {
          affinity: 'none'
        }
      }
    }
    template: {
      scale: {
        minReplicas: 0           // škálování na nulu je teď bezpečné
        maxReplicas: 10
      }
    }
  }
}

Na App Service je ekvivalentem clientAffinityEnabled: false — ARR affinity cookie, kterou jste dřív potřebovali zapnutou, teď jen zbytečně tříští rozložení zátěže.

To minReplicas: 0 je ta část, která má cenu. Se sessions se scale-to-zero prakticky nedal použít — probuzení instance znamenalo ztracenou session. Bez sessions je studený start jen latence, ne chyba.

Volba mezi Container Apps a AKS pro tenhle typ workloadu je teď jednodušší, protože odpadl hlavní argument pro složitější platformu; k té volbě jsem psal samostatně v porovnání Container Apps a AKS.

Blast radius: co ve vašem kódu přestane fungovat

Projděte si tohle po řádcích.

Server:

• Cokoliv, co drží stav mezi requesty v paměti instance a spoléhá, že další request dopadne na stejnou instanci. Bez sessions je to nedefinované chování.
• Zpracování hlavičky Mcp-Session-Id — smazat.
• Handler pro initialize a notifications/initialized — smazat. Verzi protokolu čtěte z _meta.
• Handler pro ping a logging/setLevel — smazat.
• Kontrola verze protokolu se přesouvá z jednoho místa do každého requestu. Tohle je ta jediná věc, kde kódu přibude, ne ubude.

Klient:

• Ukládání a posílání Mcp-Session-Id — smazat.
• Čekání na initialized před prvním voláním — smazat.
• Reconnect logika kolem Last-Event-ID — smazat, ale nahradit něčím. O tom níž.

Tvar _meta je ve specifikaci, ale princip vypadá takhle — každý request si nese svůj kontext:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "query_metrics",
    "arguments": { "realm": "retail", "range": "1h" },
    "_meta": {
      "protocolVersion": "2026-07-28"
    }
  }
}

Přesná jména polí si ověřte v changelogu, odkaz je na konci. Podstatné je, že tenhle request je kompletní — server ho vyřídí bez znalosti čehokoliv předchozího.

Jediná věc, která se opravdu zhoršila

SSE resumability je pryč. Přerušený stream znamená ztracený rozpracovaný request a klient ho musí zopakovat celý.

Pro nástroje, které jen čtou, je to nezajímavé — zopakujete dotaz a je to. Problém nastává u nástrojů, které něco mění a běží dlouho. Tam máte dvě možnosti:

Udělejte nástroj idempotentní. Klient posílá klíč operace, server pozná opakování a vrátí původní výsledek místo toho, aby akci provedl podruhé. Standardní věc, jen ji teď potřebujete i tam, kde jste dřív spoléhali na resumability.

Nebo ho překlopte na job handle. První volání práci nastartuje a hned vrátí ID úlohy. Druhé volání se ptá na stav. Stream se pak může přetrhnout kolikrát chce — stav úlohy je na serveru, ne ve streamu.

Před revizí                    Po revizi
───────────────                ─────────────────────
tools/call run_backup          tools/call start_backup  → { "jobId": "b-8f12" }
  │ (stream, 90 s)               tools/call backup_status  → { "state": "running" }
  │                              tools/call backup_status  → { "state": "done" }
  └─ přerušení = ztráta         přerušení = jen zopakujete dotaz na stav

Pro můj observability server to naštěstí neznamená nic — všechny nástroje jsou read-only, takže zopakování dotazu je bez následků. Pokud ale váš MCP server něco zapisuje, tohle je ta část migrace, kterou musíte navrhnout, ne jen smazat kód.

Co je deprekované, ne zrušené

Deprecation okno je minimálně 12 měsíců od 28. 7. 2026, tedy nejdřív do konce července 2027:

• Roots
• Sampling
• Logging
• OAuth Dynamic Client Registration (RFC 7591) → nahrazují Client ID Metadata Documents

Nic z toho nemusíte řešit tenhle měsíc. Ale je to seznam, na kterém nemá smysl stavět nové věci — a pokud plánujete MCP server na příští rok, počítejte s tím, že registrace klientů půjde přes CIMD, ne přes DCR.

Co udělat

1. Zjistěte, jestli váš server drží stav v paměti instance. Pokud ano, tohle je hlavní práce, ne mazání handshake.
2. Smažte session logiku na obou stranách. Bude to čistý úbytek kódu.
3. Přesuňte kontrolu verze protokolu do zpracování každého requestu.
4. Projděte nástroje, které zapisují, a rozhodněte u každého: idempotence, nebo job handle.
5. Vypněte session affinity v hostingu a zvažte scale-to-zero — to je ta odměna za celou migraci.
6. Nezakládejte nic nového na Roots, Sampling, Logging ani DCR.

Celkově je to revize, která bere jednu věc (resumability) a vrací provozní jednoduchost. Pro každého, kdo MCP server někde hostuje, je to výhodná výměna — jen je potřeba ji projít vědomě, hlavně u nástrojů, které nejsou read-only.

Pokud řešíte návrh MCP serveru do regulovaného prostředí a chcete si projít architekturu, mrkněte na služby cloudové architektury.

Zdroje

• Changelog specifikace 2026-07-28
• Oznámení revize na blogu MCP — 28. 7. 2026