MCP отказался от обязательных сессий

Протокол больше не привязывает запрос к серверу

AWS разобрала крупнейшее с момента запуска обновление Model Context Protocol — спецификацию 2026-07-28. Главное изменение находится не в новом инструменте, а в устройстве самого обмена: ядро MCP стало stateless. Обязательный initialize handshake удалён, заголовок Mcp-Session-Id больше не нужно возвращать в каждом следующем запросе, а версия протокола и контекст клиента передаются с самим запросом. Первый вызов клиента теперь может сразу быть вызовом инструмента, и ответить на него способен любой экземпляр сервера.

Для инфраструктуры это существенный сдвиг. В session-based реализации состояние было связано с экземпляром, который создал сессию. Масштабирование требовало sticky routing либо внешнего хранилища сессий — например, DynamoDB или ElastiCache. Новая схема убирает такую обязанность на уровне протокола: запрос можно направить на свободный экземпляр, а AWS Lambda начинает соответствовать естественной модели request in, response out без обходных механизмов ради handshake.

Stateless не означает отказ от состояния приложения

AWS отдельно предупреждает о важном различии: stateless описывает транспортный протокол, а не бизнес-логику. Длинная операция, корзина, workflow или многошаговая задача по-прежнему могут хранить состояние. Но сервер должен положить его в обычное datastore и вернуть модели явный идентификатор как результат инструмента. Следующие вызовы передают этот ключ аргументом. Состояние остаётся в системе, а маршрутизация перестаёт зависеть от невидимой серверной сессии.

Для сценариев, где серверу во время вызова нужна дополнительная информация от клиента, спецификация предлагает Multi Round-Trip Requests. Сервер возвращает input_required, набор inputRequests и непрозрачный requestState. Клиент выполняет запросы и повторяет исходный вызов с inputResponses и тем же requestState. Продолжить работу снова может любой экземпляр: ему не требуется удерживать соединение или искать прежнюю сессию.

Что меняется кроме маршрутизации

Ревизия стандартизирует несколько деталей эксплуатации. server/discover сообщает поддерживаемые версии, возможности и identity сервера; клиент может вызывать его перед инструментом, хотя это необязательно. Mcp-Method и Mcp-Name позволяют gateway видеть тип операции без разбора body. Для tracing используется W3C Trace Context в _meta, а собственный канал MCP Logging объявлен устаревшим в пользу stderr и OpenTelemetry. Списки инструментов возвращаются в детерминированном порядке, что помогает prompt caching.

Устойчивость теперь сильнее зависит от идемпотентности инструментов. Вместо восстановления оборванного ответа через Last-Event-ID клиент повторяет вызов, поэтому операции с побочными эффектами должны распознавать дубликаты. Длинные потоки при этом не исчезли: subscriptions/listen оставляет opt-in stream, а значит, idle timeout у load balancer, proxy и compute tier всё равно нужно проверять.

Почему это важно

У MCP-сервера становится меньше инфраструктуры, существующей только ради протокольной сессии. Это снижает стоимость простоя для нерегулярных agent workloads, упрощает балансировку и улучшает изоляцию отказов. Но экономия появится лишь после миграции: преждевременное удаление session store сломает клиентов, которые продолжают говорить на версии 2025-11-25.

Практический вывод: новым серверам разумно сразу выбирать MCP 2026-07-28, явные идентификаторы и идемпотентные tools. В существующей системе сначала надо обновить SDK с явным opt-in, вести метрику версии каждого запроса и поддерживать отдельный legacy lane. Sticky routing и session infrastructure можно отключать только после того, как трафик старого протокола действительно достигнет нуля. Roots, Sampling, Logging и HTTP+SSE получили как минимум двенадцатимесячное окно до удаления, поэтому миграция должна быть управляемой, а не аварийной.

Команде также придётся пересмотреть observability и контракт каждого tool. Это должно быть частью release checklist, а не последующей оптимизацией. Версия протокола должна попадать в логи на каждом запросе, resultType — использоваться для метрик успешности, а trace context — проходить через gateway и downstream services. Для операций оплаты, отправки сообщения или изменения записи нужен idempotency key, иначе обычный retry после сетевого обрыва повторит побочный эффект. Отдельный conformance test полезно прогонять против новой и legacy веток до переключения production traffic. Наконец, server/discover не следует превращать в обязательный новый handshake: спецификация делает его доступным для discovery, но оставляет клиенту право сразу вызвать tool. Польза stateless-ядра исчезнет, если реализация снова введёт скрытую привязку к экземпляру или обязательный предварительный обмен. Поэтому миграция — это не только удаление header, а аудит state ownership, retry semantics, caching, tracing и обратной совместимости всей цепочки.