MCP переходить до stateless-архітектури: що змінюється для серверів, балансування й авторизації

Google описала масштабну зміну в release candidate специфікації MCP 2026-07-28: ядро протоколу стає stateless. Ініціалізаційний handshake та обов’язковий Mcp-Session-Id прибираються, щоб будь-який екземпляр сервера міг обробити наступний запит клієнта.

Що саме сталося

У старій моделі сервер зберігав стан ініціалізації в пам’яті, тому балансувальнику були потрібні sticky sessions або спільне сховище на кшталт Redis. Перезапуск pod втрачав контекст, а звичайний round-robin міг відправити виклик на екземпляр, який нічого не знав про сесію.

У новій моделі версія протоколу, відомості про клієнта та capabilities передаються в _meta кожного запиту. Заголовки Mcp-Protocol-Version, Mcp-Method і Mcp-Name дозволяють шлюзам маршрутизувати, лімітувати й журналювати трафік без глибокого аналізу JSON-body.

Для уточнень використовується Multi Round-Trip Requests: сервер повертає InputRequiredResult і серіалізований requestState, а клієнт повторює виклик після відповіді користувача. Довгі операції можуть перейти у Tasks Extension, повернути taskId і виконуватися асинхронно.

Чому це важливо для розробників

Stateless core робить Cloud Run, функції та звичайні Kubernetes deployment природнішими для MCP. Роллаути, autoscaling і падіння окремого контейнера менше впливають на розмову, а інфраструктура не мусить зберігати транспортну сесію лише заради протоколу.

Стан бізнес-операції нікуди не зникає — він переходить на рівень застосунку. Тому розробнику потрібні підписані або захищені requestState, ідемпотентність повторних викликів, строки життя задач і чітка прив’язка токена до конкретного ресурсу.

Що варто зробити команді

• Почніть міграцію на staging та перевірте beta SDK для своєї мови.
• Зробіть повторювані tool calls ідемпотентними й додайте ключі дедуплікації.
• Не довіряйте requestState від клієнта без перевірки цілісності та строку дії.
• Налаштуйте OpenTelemetry, rate limits і аудит за новими HTTP-заголовками.
• Підготуйте перехідний період для клієнтів старої версії протоколу.

Обмеження та контекст

Йдеться про release candidate і beta SDK, тому назви полів та деталі міграції ще потрібно звіряти з актуальною специфікацією. Production-перехід без сумісного тестового контуру може порушити роботу старих клієнтів.

Висновок редакції

MCP переходить до stateless-архітектури: що змінюється для серверів, балансування й авторизації — практичний сигнал про те, як швидко змінюються AI, інфраструктура та розробка. Однак цінність анонсу з’являється лише після перевірки на власних даних, з вимірюваними критеріями якості, контрольованими правами доступу та можливістю безпечного відкату. Редакція радить починати з малого пілота, документувати припущення і не підміняти незалежну технічну оцінку заявами постачальника.