Врата, выдерживающие команду

Ревизия спецификации 2026-07-28 переписала протокол сильнее, чем любая предыдущая. Если вы учились по материалам прошлого года, половина знакомых механизмов либо исчезла, либо переведена в деприкацию. Начинать проектирование продакшн-сервера имеет смысл именно отсюда.

Что исчезло из ядра

• Сессий на уровне протокола больше нет. Заголовок Mcp-Session-Id убран из транспорта Streamable HTTP. Списковые вызовы (tools/list, resources/list, prompts/list) больше не различаются от соединения к соединению. Серверу, которому нужно состояние между вызовами, полагается выдавать явные дескрипторы и принимать их обычными аргументами инструмента.
• Рукопожатия нет. Методы initialize и notifications/initialized удалены; протокол стал stateless. Каждый запрос несёт версию протокола и возможности клиента в поле _meta. Несовпадение версий возвращает UnsupportedProtocolVersionError.
• Появился server/discover. Сервер обязан его реализовать: он объявляет поддерживаемые версии, возможности и идентичность.
• Подписки переехали. GET-эндпоинт и пара resources/subscribe/unsubscribe заменены единым долгоживущим потоком subscriptions/listen, на который клиент подписывается по типам изменений.
• Убраны ping, logging/setLevel и notifications/roots/list_changed. Уровень логирования задаётся теперь на запрос, полем io.modelcontextprotocol/logLevel в _meta.
• Серверных запросов к клиенту больше нет. Вместо них паттерн MRTR: сервер возвращает результат с resultType: "input_required" и списком inputRequests, а клиент повторяет исходный запрос с inputResponses. Все результаты теперь несут обязательное поле resultType.
• Возобновление SSE-потока удалено. Оборванный поток теряет запрос — клиент обязан переотправить его с новым идентификатором.

Что помечено к удалению

Спецификация вводит формальный жизненный цикл: Active → Deprecated → Removed, с окном деприкации минимум двенадцать месяцев. Про помеченные возможности сказано прямо: «new implementations should not add support for them» (MCP Key Changes).

Практический вывод для автора сервера: три механизма, вокруг которых строились «продвинутые» примеры — сервер просит вывод у клиента, сервер объявляет границы файловой системы, сервер шлёт логи, — больше не путь развития. Границы задаются конфигурацией и параметрами, наблюдаемость — телеметрией, а не протоколом.

Что появилось для нагрузки

Кэширование стало частью контракта. Результаты tools/list, prompts/list, resources/list, resources/read и resources/templates/list обязаны нести ttlMs (подсказка о свежести) и cacheScope (public или private — можно ли кэшировать на промежуточных узлах). Дополнительно серверам рекомендовано отдавать инструменты в детерминированном порядке: это повышает попадание в кэш промпта у клиента.

Из мелкого, но заметного: код ошибки «ресурс не найден» изменён с -32002 на -32602, а диапазон -32020…-32099 зарезервирован под саму спецификацию.

Как это ложится на Claude Code

Claude Code начиная с версии 2.1.232 использует рантайм MCP v2 — TypeScript SDK 2.0 и ревизию протокола 2026-07-28. На более ранних версиях, а также на Bedrock, Google Cloud и Foundry работает рантайм v1. Это значит, что сервер, написанный по новой спецификации, у части команды может подключаться по старому пути, и совместимость придётся держать обе стороны.

Границы на стороне клиента задаются не протоколом, а настройками: disabledMcpServers и enabledMcpServers управляют набором, allowedMcpServers и allowManagedMcpServersOnly — политикой организации, а отдельный инструмент можно пометить требующим подтверждения человека. Разрешения работают по обычным правилам вида mcp__<сервер>__<инструмент> — Круг дозволенного.

Наблюдаемость на уровне команды строится снаружи протокола: телеметрия, лимиты расхода и аудит — часть развёртывания, а не сервера (Развёртывание на гильдию).

Базовое устройство протокола, транспорты и подключение — Врата протокола.