MCP 2026-07-28 переходит на stateless-архитектуру: изменения маршрутизации, которые каждый оператор gateway должен сделать прямо сейчас

Когда изменение протокола устраняет целый класс инфраструктурных требований к gateway, инженерные команды должны проверить стек до того, как финальная спецификация вступит в силу. Release Candidate MCP 2026-07-28 — доступен уже сейчас, финальная спецификация выходит 28 июля — именно такое изменение.

Это крупнейшая ревизия Model Context Protocol с момента его запуска. Для операторов AI-шлюзов, балансировщиков нагрузки и MCP-прокси изменение не косметическое. Stateless-ядро устраняет session pinning, делавший горизонтальное масштабирование MCP-серверов дорогостоящим, а новый заголовок Mcp-Method впервые позволяет маршрутизировать MCP-трафик на уровне HTTP-заголовков.

Что произошло

Команда спецификации MCP опубликовала Release Candidate ревизии 2026-07-28 18 июля. Шесть Specification Enhancement Proposals (SEP) совместно реализуют stateless-архитектуру на транспортном уровне:

• SEP-2575 удаляет рукопожатие initialize/initialized. Версия протокола, информация о клиенте и возможности клиента теперь передаются в поле _meta каждого запроса.
• SEP-2567 полностью удаляет заголовок Mcp-Session-Id и концепцию сессии на уровне протокола.
• SEP-2243 обязывает все Streamable HTTP-запросы включать заголовки Mcp-Method и Mcp-Name.
• SEP-2549 добавляет ttlMs и cacheScope к результатам list и чтения ресурсов по образцу HTTP Cache-Control.
• SEP-2322 заменяет открытый SSE-поток для server-initiated prompt на паттерн опроса InputRequiredResult.
• SEP-414 стандартизирует ключи распространения W3C Trace Context в _meta для распределённой трассировки.

Финальная спецификация выходит 28 июля 2026 года. Релиз содержит breaking changes относительно спецификации 2025-11-25.

Почему это важно для команд AI-инжиниринга

До этой ревизии горизонтальное масштабирование MCP-сервера требовало:

1. Sticky-маршрутизации — каждый запрос с Mcp-Session-Id должен был попадать на экземпляр, который его выдал.
2. Общего хранилища сессий — Redis, DynamoDB или аналог, чтобы состояние сессии сохранялось при перезапуске экземпляра.
3. Инспекции тела запроса на gateway — потому что тип операции находился внутри тела JSON-RPC, а не в HTTP-заголовках.

После 2026-07-28 ничего из этого на уровне протокола не требуется. Любой запрос может попасть на любой экземпляр сервера, поскольку весь необходимый контекст содержится в payload и _meta. Обычный round-robin-балансировщик справляется с тем, для чего раньше требовалась session-aware-маршрутизация.

Для команд, обрабатывающих масштабные agentic-нагрузки — когда agent вызывает десятки MCP-инструментов в рамках одной сессии — это снижает как инфраструктурные затраты, так и площадь возможных сбоев. Поддерживать SLA session affinity больше не нужно.

Взгляд оператора и router

Новые заголовки Mcp-Method и Mcp-Name меняют возможности AI-шлюзов и API-роутеров при работе с MCP-трафиком.

Маршрутизация на уровне заголовков. Ранее, чтобы маршрутизировать MCP-трафик по типу операции (например, отправлять tools/call в низколатентный кластер, а resources/read — в кешируемый ярус), gateway должен был десериализовать тело JSON-RPC каждого запроса. Заголовки Mcp-Method и Mcp-Name выносят тип операции и имя инструмента на HTTP-уровень, позволяя применять rate-limiting, квотирование и политики маршрутизации без инспекции тела. Серверы обязаны отклонять запросы, где заголовки расходятся с телом, поэтому заголовки имеют авторитетный статус.

Политика кеширования через ttlMs. Поля ttlMs и cacheScope в результатах list работают как Cache-Control. Gateway теперь может кешировать ответы tools/list на объявленный TTL и отдавать их нескольким клиентам без обращения к MCP-серверу при каждом подключении. Для крупных agent-парков, инициализирующих множество сессий, это существенно снижает нагрузку на upstream.

Распределённая трассировка по всему пути агента. Имена ключей W3C Trace Context (traceparent, tracestate, baggage) теперь закреплены в спецификации. Трейс, начатый в AI-шлюзе, прошедший через сессию Claude Code и вызвавший MCP-сервер, теперь формирует единое дерево span в любом OpenTelemetry-совместимом бэкенде — без координации между SDK и фреймворками.

Миграция Tasks. Экспериментальный Tasks API из спецификации 2025-11-25 получил новый жизненный цикл в 2026-07-28. Метод tasks/list удалён. Создание задач теперь инициирует сервер: он отвечает на tools/call хендлом задачи, а клиент опрашивает через tasks/get, tasks/update и tasks/cancel. Команды, построившие очереди или логику async-dispatch на старом Tasks API, обязаны завершить миграцию до 28 июля.

Чеклист breaking changes для операторов:

• Убрать правила sticky-маршрутизации, привязанные к Mcp-Session-Id
• Убрать или переработать правила инспекции тела, извлекающие тип операции из JSON-RPC
• Добавить правила маршрутизации по заголовкам Mcp-Method и Mcp-Name
• Настроить кеширование ответов tools/list на стороне gateway с использованием ttlMs
• Мигрировать реализации Tasks на новый жизненный цикл под управлением сервера
• Убедиться, что ключи OTel trace-пропагации совпадают с именами, закреплёнными в спецификации
• Зафиксировать версии SDK на тех, что реализуют 2026-07-28, прежде чем обновлять MCP-серверы

Что стоит отслеживать и попробовать пользователям TheRouter

Если ваш стек сегодня маршрутизирует MCP-трафик — через Claude Code, любую agent-платформу или собственный прокси — приоритетное действие: аудит правил session affinity в конфигурации балансировщика или gateway. Эти правила либо станут ненужными, либо потребуют замены на маршрутизацию по Mcp-Method.

Документация TheRouter охватывает конфигурацию gateway для маршрутизации AI-провайдеров, и те же примитивы request routing, что управляют fallback модели, применимы к уровням MCP-трафика. Следите за финальным релизом 28 июля — RC содержит breaking changes, которые необходимо реализовать в SDK.

Для команд, использующих экспериментальный Tasks API с любым провайдером: считайте 28 июля жёстким дедлайном миграции. Server-directed жизненный цикл задач полностью убирает tasks/list, и любой клиентский код, опрашивающий все активные задачи, сломается.