MCP 2026-07-28: ядро без сохранения состояния и границы совместимости

Что это

Состояние на 25 октября 2026 года. Редакция MCP 2026-07-28, анонсированная 28 июля 2026 года, меняет жизненный цикл протокола. Перед обновлением заново проверьте журнал изменений для этой версии, правила совместимости, спецификации расширений и реестр устаревающих возможностей; анонс выпуска даёт обзор, а не полное описание обмена сообщениями.

Эта редакция убирает initialize, notifications/initialized и HTTP-сеансы на уровне протокола, включая Mcp-Session-Id. Каждый запрос объявляет свою версию и возможности клиента в _meta. Серверы обязаны реализовать server/discover; клиенты могут вызвать его для предварительного обнаружения возможностей или сразу отправить другой запрос. «Необязательное обнаружение» описывает выбор клиента, а не освобождение сервера от обязанности. Эти различия следуют из спецификации версионирования.

Почему это важно

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

В анонсе выпуска описана эксплуатационная причина изменения: запросы могут поступать на разные экземпляры сервера без привязки сеанса к одному из них. Это преимущество не снимает с приложения ответственности за долговременное хранение собственного состояния.

Как применять

• Проверьте предположения о жизненном цикле. Замените неявный контекст соединения метаданными запроса. Для состояния, сохраняемого между вызовами, передавайте явные идентификаторы объектов приложения как аргументы инструментов. При поддержке старых клиентов сохраняйте отдельный механизм работы по прежнему протоколу.
• Обрабатывайте промежуточные результаты. Multi Round-Trip Requests заменяют независимые запросы, инициируемые сервером. Результат input_required запрашивает входные данные; клиент повторяет исходную операцию с inputResponses. Обычные результаты используют resultType: "complete". Ответы прежних версий без этого поля считаются завершёнными.
• Обновите интеграцию HTTP. Реализуйте заголовки метода и, где применимо, имени; используйте subscriptions/listen для уведомлений об изменениях, на которые клиент явно подписался. Сведения о ходе выполнения запроса остаются в исходном потоке ответа на него. Возобновление SSE и повторная доставка убраны: для восстановления нужен новый запрос с новым ID и защита на уровне приложения от повторения побочных эффектов.
• Реализуйте метаданные кэширования. Журнал изменений требует ttlMs и cacheScope в указанных результатах получения списков и ресурсов. Рассматривайте актуальность и разрешение на совместное использование как отдельные вопросы; ни одно из этих свойств не означает, что любой ответ можно кэшировать для общего доступа.
• Объявляйте расширения явно. Поддержка расширений объявляется через карты возможностей; по умолчанию расширения выключены и требуют явного включения разработчиком. Tasks перемещается из экспериментального ядра в официальное расширение. Подтверждайте поддержку с обеих сторон, а не выводите её из версии ядра.
• Отслеживайте жизненный цикл возможностей. Active, Deprecated и Removed — отдельные состояния. Обычный минимальный период между объявлением устаревания и удалением составляет двенадцать месяцев; политика допускает утверждённое исключение по соображениям безопасности с периодом не менее девяноста дней. Прежде чем планировать удаление, проверьте запись о конкретной возможности.

Подводные камни

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