Что произошло

28 июля 2026 года проект Model Context Protocol выпустил новую версию спецификации — `2026-07-28`. Главное изменение: ядро протокола стало stateless, то есть серверу больше не требуется поддерживать протокольную сессию между отдельными запросами клиента.

Из транспортного уровня убраны обмен `initialize` / `initialized` и заголовок `Mcp-Session-Id`. Каждый запрос теперь сам сообщает версию протокола, сведения о клиенте и его возможностях в `_meta`. Если клиенту нужно заранее узнать возможности сервера, он может вызвать `server/discover`, но обязательного рукопожатия перед первым рабочим запросом больше нет.

Для владельца бизнеса это звучит как низкоуровневая деталь, однако следствие вполне прикладное: MCP-серверы проще размещать за обычным балансировщиком, масштабировать горизонтально и восстанавливать после сбоя. Запрос не привязан к конкретному экземпляру сервера только потому, что на нём когда-то началась сессия.

Важно не перепутать два понятия. Stateless стал транспорт MCP, а не бизнес-процесс. История сделки, черновик платежа, пауза на согласование и права конкретного сотрудника никуда не исчезают. Их нужно хранить явно — в CRM, ERP, базе оркестратора и системе управления доступом.

Что именно изменилось в протоколе

В Streamable HTTP каждый JSON-RPC запрос отправляется отдельным `POST`. Версия указывается в заголовке `MCP-Protocol-Version` и должна совпадать с версией в `_meta`; при несовпадении сервер обязан отклонить запрос. Для маршрутизации добавлены стандартные заголовки `Mcp-Method` и, для вызова инструмента или чтения ресурса, `Mcp-Name`.

Это позволяет API-шлюзу принимать решения без разбора всего JSON-тела:

  • направлять чтение и запись в разные пулы;
  • ограничивать частоту вызовов конкретного инструмента;
  • запрещать опасные методы для отдельных ролей;
  • строить метрики по инструментам и арендаторам;
  • быстрее локализовать ошибку по трассировке запроса.

Каталоги инструментов, ресурсов и промптов получили подсказки для кэширования. Долгие операции могут использовать расширение Tasks, а взаимодействия, где серверу нужен дополнительный ввод или подтверждение, переводятся на модель нескольких раундов запрос–ответ. При этом открытый бесконечный канал больше не является основой протокола.

Новая версия содержит несовместимые изменения. Официальный Go SDK 1.7.0 поддерживает новый протокол и сохраняет совместимость с версиями до `2025-11-25`, но конкретные клиенты и серверы обновляются в своём темпе. Поэтому миграция должна проходить через одновременную поддержку двух версий, а не через замену всего контура за одну ночь.

Почему это актуально российскому бизнесу

MCP уже перестал быть только экспериментом разработчиков. Российские поставщики подключают через него корпоративные системы, аналитику, встречи и бизнес-процессы. Например, Brand Analytics в июле объявила MCP-доступ к данным мониторинга для внешних ИИ-сервисов. Это заявление поставщика, а не независимая оценка качества, но оно показывает направление рынка: стандартный интерфейс к инструментам становится частью коммерческих продуктов.

Для малого и среднего бизнеса ценность MCP не в модном названии. Она появляется, когда один контролируемый интерфейс заменяет набор специальных интеграций между агентом и CRM, базой знаний, сервис-деском или системой документооборота. Новая stateless-модель делает такой интерфейс ближе к обычной HTTP-инфраструктуре, которую уже умеют сопровождать ИТ-команды.

Но простота транспорта может создать ложное чувство безопасности. Независимое исследование 1 723 MCP-приложений на GitHub обнаружило блокирующее одобрение вызовов инструментов только у 37,2% выборки. Журналирование встречалось у 90,8%, а возможность включать и отключать инструменты — у 77,2%. Иными словами, увидеть действие после выполнения гораздо популярнее, чем остановить его до выполнения.

Практическая архитектура: пять отдельных слоёв

Рабочий контур стоит разделить так, чтобы каждый слой отвечал за одну задачу.

1. **Локальная или облачная модель.** Модель понимает запрос и предлагает инструмент, но не хранит источник истины о сделке и не выдаёт себе права.
2. **Оркестратор агента.** Он ведёт идентификатор операции, состояние шага, повторные попытки и паузы на согласование. Для записи обязательны стабильные ключи идемпотентности.
3. **MCP-шлюз.** Он проверяет пользователя, организацию, версию протокола, имя метода и инструмента, лимиты и политику доступа. Серверы не следует публиковать в интернет напрямую только ради удобства агента.
4. **Stateless MCP-серверы.** Они валидируют аргументы и выполняют узкую функцию. Их экземпляры можно масштабировать независимо, потому что протокольная сессия не привязывает клиента к одному процессу.
5. **Системы учёта и аудита.** CRM, ERP, документооборот или транзакционная база хранят бизнес-состояние. Отдельный журнал связывает пользователя, модель, версию промпта, инструмент, параметры, решение согласующего и результат.

Такой разрез позволяет развернуть модель локально и оставить MCP-серверы внутри защищённой сети. Наружу выпускаются только разрешённые зависимости, а секреты передаются через хранилище учётных данных, а не через промпт или произвольные заголовки.

Где нужны подтверждения человека

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

  • Чтение справочника, поиск документа и получение статуса обычно выполняются автоматически в пределах прав пользователя.
  • Создание черновика заявки или письма допускается автоматически, если результат остаётся черновиком.
  • Отправка сообщения клиенту, изменение карточки, создание заказа и запуск задания требуют проверки при выходе за заданные суммы, адресаты или типы данных.
  • Платёж, удаление, массовая рассылка, выдача прав и необратимая операция всегда ставятся на блокирующее согласование.

Экран согласования должен показывать не только название инструмента, но и нормализованные аргументы, инициатора, бизнес-объект и прогнозируемое последствие. После одобрения оркестратор продолжает сохранённую операцию, а не просит модель заново придумать вызов.

Миграция без остановки процессов

Для перехода на MCP `2026-07-28` разумен поэтапный план.

  • Инвентаризировать клиентов, серверы, SDK и используемые возможности старого протокола.
  • Проверить, не хранится ли бизнес-состояние случайно в протокольной сессии или памяти процесса.
  • Поднять совместимый шлюз с поддержкой старой и новой версии.
  • Перевести один read-only инструмент и прогнать тесты на несовпадение версий, повтор запроса, тайм-аут и отмену.
  • Добавить политику по `Mcp-Method` и `Mcp-Name`, но проверять авторизацию также по пользователю, арендатору и самому ресурсу.
  • Проверить кэш: каталог инструментов можно кэшировать, а персональные данные и результаты действий — только по явно заданным правилам.
  • Затем подключать запись, идемпотентность и блокирующие подтверждения.

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

Экономика и ограничения

Stateless-транспорт способен уменьшить инфраструктурную сложность: меньше причин держать sticky sessions и общий сеансовый кэш, проще использовать стандартный балансировщик и заменять экземпляры сервера. Но это не обещание автоматической экономии.

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

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

Следующий шаг на десять рабочих дней

Возьмите один процесс с понятным владельцем, например поиск статуса заказа и подготовку черновика ответа клиенту. Оставьте первую версию read-only, подключите не более пяти инструментов и соберите 30–50 реальных сценариев без персональных данных.

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

Если команда не может однозначно ответить, где хранится состояние операции, кто подтверждает запись и как отменить повтор, к автономному запуску переходить рано. Новый MCP снимает часть транспортной сложности — и тем самым делает архитектурные пробелы заметнее. Это полезное взросление стандарта, а не разрешение убрать контроль.