MCP стал stateless: что ломается и как проверить свой сервер

Что случилось 28 июля?#

Касается ли это вас прямо сейчас: если у вас работают MCP-серверы или клиент, то да - но не так, как кажется. Ломается не всё сразу, и проверка своей стороны занимает пятнадцать минут. Команды для неё - в третьем разделе.

Предыдущая стабильная ревизия датирована 2025-11-25. Восемь месяцев без изменений для протокола, вокруг которого выросла целая индустрия интеграций, - это долго, и накопленное вышло одним куском.

Что убрали:

• рукопожатие initialize и уведомление notifications/initialized;
• заголовок Mcp-Session-Id и вместе с ним протокольные сессии;
• методы ping и logging/setLevel, уведомление notifications/roots/list_changed;
• возобновляемость потока: заголовок Last-Event-ID и идентификаторы событий.

Что добавили:

• server/discover - метод обнаружения, который сервер обязан реализовать;
• subscriptions/listen - один долгоживущий поток вместо подписок на ресурсы;
• шаблон многораундовых запросов MRTR: сервер возвращает input_required, клиент повторяет запрос с данными;
• обязательное поле resultType в каждом результате;
• поля кэширования ttlMs и cacheScope в списочных методах.

Каждое изменение в спецификации снабжено номером предложения и ссылкой на обсуждение: SEP-2567, SEP-2575, SEP-2322, SEP-2663, SEP-2596, SEP-2549. Проверяйте формулировки по ним, а не по пересказам.

Почему «я обновил SDK» ещё не значит «я мигрировал»?#

Источник первый - дефолт SDK. Документ миграции TypeScript SDK говорит прямо:

Режим legacy стоит по умолчанию. Чтобы клиент попробовал новую ревизию, ему нужен явный versionNegotiation: { mode: 'auto' }. Локальная проверка на паре свежих пакетов дала такой вывод:

DEFAULT (no versionNegotiation) => era: legacy | tools: ping_tool
mode:'auto'                     => era: modern | tools: ping_tool
mode:{pin:'2026-07-28'}         => era: modern | tools: ping_tool

Инструменты работают во всех трёх случаях. Разница видна только через getProtocolEra().

Источник второй - имя пакета в npm. Мажорную двойку получило новое семейство, а привычное имя осталось на единице:

Рядом лежат ещё два пакета: codemod для автоматической миграции кода и server-legacy - замороженная копия старого транспорта. При установке последнего npm печатает предупреждение: пакет существует только ради миграции и новых возможностей не получит.

Источник третий - константа внутри самих пакетов v2. Она осталась легаси-словарём:

LATEST_PROTOCOL_VERSION      = 2025-11-25
SUPPORTED_PROTOCOL_VERSIONS  = ["2025-11-25","2025-06-18","2025-03-26","2024-11-05","2024-10-07"]

Строки 2026-07-28 в списке поддерживаемых нет вообще, хотя тот же пакет экспортирует функции новой ревизии. Смысл у константы узкий: она обозначает последнюю рукопожатную ревизию, а рукопожатия в новой эре больше нет. Определять по ней версию протокола нельзя.

Как узнать, на какой ревизии ваш сервер?#

Способ первый, для современного сервера. Три заголовка обязательны, без них придёт ошибка:

curl -s -X POST https://ваш-сервер/mcp \
 -H 'Content-Type: application/json' \
 -H 'Accept: application/json, text/event-stream' \
 -H 'MCP-Protocol-Version: 2026-07-28' \
 -H 'Mcp-Method: server/discover' \
 -d '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}'

В ответе придёт supportedVersions со списком ревизий.

Способ второй, для сервера с обычным stdio. Он же самый показательный. Спросите сервер новой ревизией и посмотрите, что он ответит:

printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-07-28","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}' \
  | npx -y ваш-mcp-сервер 2>/dev/null | head -1

На живом сервере это дало вот что:

{"result":{"protocolVersion":"2025-11-25","serverInfo":{"name":"Playwright","version":"1.62.0-alpha"}}}

Клиент попросил 2026-07-28. Сервер ответил 2025-11-25, и рукопожатие прошло успешно. Ни ошибки, ни предупреждения: сервер молча согласовал ту ревизию, которую знает сам. Клиент, который не читает поле protocolVersion из ответа, узнает об этом по странному поведению через неделю.

Здесь же прячется ирония, ради которой стоит запомнить эту команду. Спросить сервер таким способом можно только методом initialize - тем самым рукопожатием, которое новая ревизия удаляет. Проверка работает ровно до тех пор, пока ваш сервер живёт на старой эре.

Способ третий - два бинарных признака транспорта. Современный сервер отвечает 405 на GET и DELETE к своей точке входа, старый отдал бы на GET поток событий:

curl -s -o /dev/null -w "%{http_code}\n" -X GET    https://сервер/mcp   # 405
curl -s -o /dev/null -w "%{http_code}\n" -X DELETE https://сервер/mcp   # 405

Способ четвёртый - из кода клиента. getProtocolEra() возвращает modern или legacy и остаётся единственным способом узнать правду о собственном подключении.

Способ пятый - инспектор. В версии 2.0.0 эра подключения показана в интерфейсе переключателем Protocol Era. Это самый наглядный путь, если сервер уже подключён к инспектору.

Почему server/discover говорит не всю правду?#

Если вы пишете клиент, который по supportedVersions решает «этот сервер старый, работать не буду», вы отсеете сервер, который вас прекрасно обслужил бы по старым правилам. Проверять надо обе стороны: сначала современный запрос, потом откат на рукопожатие.

Что ломается молча?#

Первое. Спецификация прямо описывает, как ведёт себя старый сервер, получивший современный запрос:

То есть tools/call может просто выполниться, но по старым правилам. Лечится обязательной пробой server/discover первым запросом: она даёт детерминированный отказ вместо неопределённости.

Второе. Отсутствие поля трактуется как успех:

Старый сервер, который на самом деле ждёт от клиента дополнительных данных, для нового клиента выглядит завершившимся штатно.

Третье. Заголовки старого мира выбрасываются без единого слова:

Старый клиент отправляет идентификатор сессии, ошибки не получает - и всё состояние, которое он на эту сессию вешал, тихо перестаёт существовать.

Четвёртое - дефолт legacy в собственном SDK, с которого начинался разбор. Он же самый частый.

Что ломается громко?#

Диапазон -32020..-32099 теперь зарезервирован за самой спецификацией, а -32000..-32019 остаётся за реализациями. Отдельно поменялся код «ресурс не найден»: он переехал с -32002 на -32602, и это единственное изменение кодов, которое ломает работающее ветвление на стороне клиента.

Кто с кем совместим?#

Отличить старый сервер от современного помогает одно поле. Старый на неподдержанную версию отвечает кодом -32000 и человекочитаемой строкой, где список версий перечислен текстом. Современный отвечает -32022 и кладёт список в data.supported. Спецификация прямо запрещает завязывать откат на конкретный код ошибки: смотреть надо на наличие поля data.supported, а не на число.

Куда девать состояние, которое лежало в сессиях?#

Инженер Кевин Ридль из Wavect перечисляет, что искать в своём коде перед миграцией: карты сессий, липкие cookie, объекты транспорта, переиспользуемые между запросами, списки инструментов на соединение и хранилища событий для возобновляемых потоков. Его вывод короче любого чек-листа:

Спецификация про requestState высказывается жёстко: сервер обязан считать его вводом, контролируемым атакующим, и защищать целостность, а клиент не имеет права разбирать и менять его содержимое.

Второй капкан - хэндлы без проверки владельца. Если один инструмент выдал идентификатор корзины, а другой принимает его на веру, вы получили уязвимость по дизайну: любой, кто угадает или перехватит идентификатор, поработает с чужими данными. Хэндл в новой схеме - это допуск, и обращаться с ним надо как с допуском: проверять на каждом вызове, что предъявитель имеет на него право.

Отсюда же вытекает главная ошибка переезда - пустить все вызовы через одну широкую сервисную учётную запись. Авторизация в новой ревизии переехала на каждый запрос, и общий кредит поверх неё делает все остальные меры бессмысленными. Если вы уже размечали, что агенту можно трогать, а что нет, эта работа теперь смотрит на каждый вызов - подробнее про допуски мы разбирали в статье про права агента, а про границы периметра - в проверке песочницы.

Почему ретрай теперь может списать деньги дважды?#

Формулировка спецификации не оставляет вариантов: идентификатор JSON-RPC у повтора обязан отличаться от исходного, потому что это независимые запросы. Ридль формулирует последствие одной строкой:

Практический вывод: до включения многораундовых запросов сделайте операции идемпотентными. Ключ идемпотентности в аргументах инструмента, проверка на стороне сервера, срок жизни ключа. Обратный порядок - сначала MRTR, потом идемпотентность - это готовый инцидент.

Что стало с Roots, Sampling и Logging?#

Замены выглядят так: вместо Roots - передавать файлы и каталоги обычными параметрами инструмента или адресами ресурсов; вместо Logging - писать в стандартный поток ошибок либо использовать OpenTelemetry, для которого ревизия отдельно описала соглашения о передаче контекста трассировки.

Здесь и прячется самое недооценённое. Сервер, который раньше переиспользовал модель клиента, после миграции превращается в самостоятельного потребителя платного API. В бюджете появляется новая строка, и посчитайте её до переезда, а не после первого счёта. Сколько именно уходит на токены и почему счёт растёт быстрее ожиданий, мы разбирали в тексте про контекстное окно.

Отдельная деталь: поле, которым заменили logging/setLevel, помечено устаревшим в той же самой ревизии, где его ввели.

Сколько у вас времени на самом деле?#

Работающие интеграции в августе не рассыплются: обе эры живут параллельно, а SDK по умолчанию держат старую. Но и год в запасе - иллюзия. Сократить окно короче года политика разрешает только при активной угрозе безопасности с опубликованным advisory, зато удалить возможность сразу после истечения срока могут без отдельного повода.

Пятнадцать минут на проверку своей стороны сегодня, миграция в план на квартал.

А протокол вообще нужен?#

Эйсо Кант, глава Poolside, в подкасте Latent.Space 23 июля высказался против самой связки MCP и вызова инструментов и уточнил, что держится этой позиции около двух лет. Его прогноз: через год мы не увидим ни одного системного промпта, набитого двумя-тремя десятками инструментов. Возразить на это просто: его же компания продолжает поддерживать и вызов инструментов, и MCP.

Со стороны безопасности в трекере спецификации 31 июля появился разбор с семью претензиями к дизайну - от инъекции через описания инструментов до теневых имён, которые, по мнению автора, молча конфликтуют между серверами. Он подчёркивал, что говорит о дефектах спецификации, а не реализаций. Через два дня обсуждение закрыл сопровождающий проекта, отклонив разбор как сгенерированный ИИ пересказ уже известных векторов атаки. То есть претензии не проигнорировали - их сочли не новыми.

Обе позиции полезно держать в голове, но ни одна из них не отменяет практической задачи: интеграции, которые у вас уже работают, написаны под протокол, и его основа изменилась.

Что сделать сегодня#

1. Спросите каждый сервер запросом initialize с новой ревизией и запишите, какую ревизию он назвал в ответе.
2. Проверьте свой клиент через getProtocolEra(). Если там legacy при свежих пакетах, вы ещё в старой эре.
3. Найдите в коде карты сессий, липкие cookie и переиспользуемые объекты транспорта. Составьте список того, что придётся вынести в явные аргументы.
4. Проверьте, что списания, отправки и удаления защищены ключом идемпотентности.
5. Если пользуетесь Sampling - посчитайте, во сколько обойдётся прямой доступ к API провайдера.