MCP без сессий: что поменяла версия 2026-07-28
В конце июля вышла спецификация MCP с номером 2026-07-28. Сами авторы называют ее самой большой переделкой протокола с момента запуска, и это не преувеличение: ушли рукопожатие, сессии и три старые возможности, а авторизацию переписали заново. К осени новую версию поддержали основные SDK и первые клиенты, так что самое время разобраться, что именно поменялось.
Главное: протокол больше не помнит состояние
Раньше MCP был двунаправленным протоколом с состоянием. Клиент открывал соединение,
обменивался с сервером initialize / initialized, получал
Mcp-Session-Id и дальше жил внутри этой сессии. Сервер обязан был ее
помнить — а значит, второй экземпляр сервера за балансировщиком ничего о ней не знал.
Теперь каждый запрос описывает себя сам: версия протокола, кто клиент и что он умеет,
передаются в поле _meta прямо в запросе. Рукопожатия и заголовка сессии
больше нет. Практическое следствие простое и приятное: MCP-сервер можно поставить за
обычный round-robin балансировщик, без «липких» сессий и общего хранилища между копиями.
Как спросить пользователя посреди вызова
Без сессии сломался бы привычный сценарий, когда сервер посреди работы инструмента
уточняет что-то у человека. Для этого появились Multi Round-Trip Requests. Сервер не
держит соединение, а отвечает resultType: "input_required" и перечисляет,
чего ему не хватает. Клиент собирает ответы и повторяет исходный вызов, приложив их в
inputResponses.
Выглядит как лишний круг, но именно это делает схему устойчивой: любой экземпляр сервера может принять повторный вызов, потому что все нужное лежит в самом запросе.
Что объявлено устаревшим
- Roots — для новых реализаций больше не рекомендуются;
- Sampling — его место заняли Multi Round-Trip Requests;
- Logging — уходит из стандартной части протокола.
Ломать сразу никто не будет: устаревшее работает минимум двенадцать месяцев, и это окно теперь закреплено как правило для всех будущих депрекаций. Но есть нюанс — серверы на новой ревизии могут не договориться со старыми клиентами и наоборот, так что обновлять стоит обе стороны.
Авторизация стала строже
Проверка издателя по RFC 9207 теперь обязательна, а учетные данные клиента привязаны к тому издателю, который их выдал. Вместо динамической регистрации клиентов (DCR) спецификация переходит на документы с метаданными клиента (CIMD). Для тех, кто писал свой OAuth-слой под MCP, это самая трудоемкая часть миграции.
Клиенты подтягиваются: в сентябрьских выпусках Gemini CLI появилась проверка издателя по RFC 9207 в OAuth-потоке MCP, а Claude Code научился открывать браузерный сценарий по запросу сервера (URL-mode elicitation) на соединениях с версией 2026-07-28.
Маршрутизация и кэш
В запросах появились заголовки Mcp-Method и Mcp-Name. Шлюзу
больше не нужно разбирать JSON, чтобы понять, какой инструмент вызывают, — он может
маршрутизировать и считать вызовы по заголовкам. А ответы на списки (инструменты,
ресурсы) получили ttlMs и cacheScope, так что клиент наконец
знает, сколько можно не переспрашивать.
Расширения вместо экспериментов в ядре
Появился формальный механизм расширений. Первым туда переехали задачи (tasks): они
вышли из экспериментальной части ядра и стали расширением
io.modelcontextprotocol/tasks. Идея понятная — ядро остается маленьким,
а все, что нужно не всем, живет отдельно и развивается своим темпом.
Что делать, если у вас свой MCP-сервер
- обновить SDK: TypeScript, Python, Go и C# уже поддерживают новую версию, Rust — в бете;
- убрать зависимость от сессии: все, что сервер «помнил», должно приходить в запросе или лежать во внешнем хранилище;
- если вы пользовались Sampling — переписать эти места на Multi Round-Trip Requests;
- проверить OAuth: издатель, привязка учетных данных, переход с DCR.