RadioGeek
Протоколы, которые придумывали для «локального сервера на одной машине», на производстве ведут себя иначе. Как только MCP-серверов становится много и они уходят за балансировщик, невидимое протокольное состояние начинает кусаться: сессии требуют sticky-маршрутизации или общего хранилища, долгоживущие стримы рвутся на таймаутах шлюзов, а запрос на согласование (handshake) превращается в точку отказа. 28.07.2026 мейнтейнеры Model Context Protocol выпустили ревизию спецификации 2026-07-28, и её главным событием они называют переход к ядру без сессий: из двунаправленного stateful-протокола MCP превращается в обычный request/response.
Главный вопрос : «Что именно меняется в архитектуре сервера и сколько стоит переезд?» Разбор — по официальному announcement и тексту спецификации.
Что произошло и где читать
- 28.07.2026 — официальный announcement ревизии 2026-07-28 в блоге проекта (авторы — лид-мейнтейнеры David Soria Parra и Den Delimarsky).
- Спецификация и changelog опубликованы на modelcontextprotocol.io: версия с датой 2026-07-28 доступна как отдельный документ с историей изменений.
- SDK первого эшелона (TypeScript, Python, Go, C#) поддержали ревизию в день релиза, Rust — в бете; к announcement приложены заметные миграционные заметки для ломающихся мест.
- Контекст по масштабам проекта (заявление мейнтейнеров, нашими замерами не подтверждено): около полумиллиарда загрузок Tier 1 SDK в месяц, TypeScript и Python пересекли по миллиарду суммарно.
Что изменилось в протоколе
| Аспект | Было | Стало | Что это даёт инженеру |
|---|---|---|---|
| Сессия | handshake initialize/initialized и заголовок Mcp-Session-Id | официально убраны (SEP-2575, SEP-2567); каждый запрос несёт версию протокола, идентичность и возможности клиента в _meta | любой запрос может приземлиться на любой инстанс за обычным round-robin балансировщиком, общее хранилище состояний не нужно |
| Обнаружение | обязателен handshake | необязательный вызов server/discover | клиент, которому нужно заранее узнать возможности сервера, делает один явный RPC |
| Состояние приложения | пряталось в транспорт сессии | рекомендация: выдавать явный handle из инструмента и передавать его аргументом в следующих вызовах | модель «видит» состояние и переносит его между инструментами; отладка становится проще |
| Маршрутизация | шлюз разбирал JSON-тело | обязательные заголовки Mcp-Method и Mcp-Name для Streamable HTTP (SEP-2243) | гейтвей, rate limiter и WAF маршрутизируют и учитывают вызовы по заголовкам |
| Запросы сервера клиенту | elicitation/create, sampling/createMessage, roots/list держали открытый стрим | Multi Round-Trip Requests (SEP-2322): сервер возвращает resultType: "input_required" с вопросами, клиент повторяет вызов с inputResponses | сценарий «уточни у пользователя посреди вызова» работает поверх stateless-транспорта, без висящих соединений |
| Списки | tools/list и родственники перечитывались заново | ответы содержат ttlMs и cacheScope (SEP-2549), порядок детерминированный | каталоги инструментов кэшируются; стабильный порядок не ломает кэш промптов при переподключении |
| Авторизация | обычные источники ошибок OAuth-обмена | сервер обязан вернуть iss по RFC 9207 и клиент обязан проверить его до обмена кода (SEP-2468); application_type перестаёт ломать localhost-редиректы десктопных и CLI-клиентов (SEP-837); Dynamic Client Registration официально депрекирован в пользу Client ID Metadata Documents (CIMD); клиентские credentials привязаны к выдавшему их issuer (SEP-2352) | закрывается путаница между авторизационными серверами; меньше сюрпризов у CLI-интеграций |
| Расширения | неформально | формальный фреймворк: Tasks переехали в расширение io.modelcontextprotocol/tasks (SEP-2663) с опросом tasks/get и tasks/update, к расширению относятся также MCP Apps и Enterprise Managed Authorization; нотификации — единый стрим subscriptions/listen с подпиской по типам | опциональные механизмы развиваются отдельно от ядра |
| Устаревание | ad hoc | политика с окном минимум 12 месяцев; уходят Roots, Sampling и Logging (SEP-2577, работают ещё минимум год) и legacy HTTP+SSE транспорт | апгрейд можно планировать, а не переживать его |
Почему отказ от сессий — это про надёжность, а не про моду
Для любого, кто эксплуатировал JSON-RPC-сервисы за балансировщиком, список выше читается как сборник снятых граблей: sticky-сессии, orphaned-стримы, «рукопожатие» как точка отказа, перезагрузка инстанса, теряющая все соединения. Перенос состояния из транспорта в явные ручки и заголовки Mcp-Method/Mcp-Name делает MCP-сервер обычным HTTP-сервисом, который можно балансировать, учитывать, логировать и обновлять штатными средствами. Обратная сторона, которую мейнтейнеры и называют честно: миграция для тех, кто завязан на Mcp-Session-Id, — ломающая; а MRTR добавляет лишних кругов там, где раньше хватало одного удерживаемого потока.
Применение к нашему направлению
Ревизия полезна не только тем, кто строит агентов:
- Проектирование API вообще. Приёмы — «состояние в явном handle, а не в сессии транспорта», «маршрутизация по заголовкам вместо разбора тела», «кэшируемые каталоги с TTL и scope» — переносимы на любые JSON-RPC-over-HTTP сервисы, включая обычные бэкенды приложений.
- Интеграции и шлюзы. Если вы пропускаете агентный трафик через свой gateway, новые обязательные заголовки — подарок: метсить и ограничивать конкретные инструменты можно без парсинга тела запроса.
- Безопасность OAuth. Проверка
issдо обмена authorization code — банальная, но массово пропускаемая гигиена; полезно сверить с ней не только MCP-клиенты.
Границы и риски
- Миграция — реальная стоимость: Официальное предупреждение: дороже всего тем, кто зависел от идентификаторов сессий. Оценка переезда чужого сервера «на глаз» — обещание, которого давать не стоит.
- Экосистема неодновременна. В проде живут серверы и клиенты ревизий 2025-06-18 и 2025-11-25; версии протокола сосуществуют через
MCP-Protocol-Version, но проверять совместимость конкретной пары «клиент-сервер» всё равно вам. - Без сессий ≠ без состояния приложения. Рекомендация с явными handle перекладывает заботу о согласованности состояния на вас: ручка, срок жизни, отзыв — это своя проектировочная работа.
- MRTR — не бесплатно. Сценарии «уточнить у пользователя посреди вызова» теперь стоят дополнительных кругов запрос-ответ.
Как использовать информацию
- Прочитать changelog ревизии (modelcontextprotocol.io/specification/2026-07-28/changelog) и найти в нём свои зависимости от сессий и стримов.
- Провести аудит своих MCP-серверов и клиентов: где используется `Mcp-Session-Id), handshake, удерживаемые SSE-потоки.
- Настроить проброс и проверку
Mcp-Method/Mcp-Nameна своём шлюзе — это можно сделать и до переезда. - Проверить авторизацию: валидация
issпо RFC 9207, поведение localhost-редиректов для CLI/десктоп-клиентов, план перехода DCR → CIMD. - Заложить в roadmap переезд до истечения 12-месячных окон устаревания Roots, Sampling, Logging и HTTP+SSE.
Полезные ссылки
- Текст спецификации.
- Блог Model Context Protocol.
