28 июля 2026 года вышла спецификация Model Context Protocol 2026-07-28. Главное изменение — stateless protocol core: обязательные протокольные сессии и прежний handshake убраны, а каждый запрос может быть самодостаточным.
Для разработчиков remote MCP servers это не косметическое обновление. Новая модель напрямую влияет на балансировку, маршрутизацию, кеширование каталогов инструментов и организацию server-to-client взаимодействия.
Ниже — что именно изменилось и на что стоит обратить внимание, если MCP уже используется в AI-интеграции или только рассматривается для нового проекта.
Что такое MCP в двух словах
Model Context Protocol задаёт единый способ, которым AI-клиенты могут узнавать о доступных инструментах и ресурсах и обращаться к ним через стандартный протокол. Практический смысл — не писать отдельную несовместимую схему интеграции для каждого агента и каждого сервиса.
MCP не отменяет обычные API. Он находится над ними: сервер может оборачивать CRM, базу данных, внутренний сервис или другой API в набор инструментов с описанными входами и результатами.
Главное изменение: stateless core
В версии 2026-07-28 протокол отказался от обязательных сессий на уровне ядра. Официальный блог MCP подчёркивает, что каждый запрос теперь сам себя описывает, а отдельный discovery-вызов остаётся опциональным для клиента, которому заранее нужны возможности сервера.
Это упрощает горизонтальное масштабирование remote MCP server: запросы могут попадать на разные экземпляры за обычным round-robin load balancer без обязательной sticky session только ради протокола.
| Раньше | 2026-07-28 | Практический эффект |
|---|---|---|
| Протокольная сессия и handshake | Stateless request/response core | Проще распределять запросы между экземплярами |
| Маршрутизация требовала анализа сообщения | Метод и имя доступны в HTTP-заголовках | Gateway может принимать часть решений по заголовкам |
| Server-to-client зависел от двунаправленного канала | MRTR | Меньше зависимости от постоянно открытого потока |
| Каталоги могли меняться по порядку | Детерминированный порядок и cache hints | Удобнее кешировать list responses |
Новые заголовки Mcp-Method и Mcp-Name
Метод и имя инструмента могут передаваться в HTTP-заголовках Mcp-Method и Mcp-Name. Это полезно на уровне gateway: маршрутизатор может принять решение до глубокого разбора тела сообщения.
Но заголовок сам по себе не заменяет авторизацию. Сервер всё равно должен проверять, имеет ли конкретный клиент право вызвать инструмент и разрешены ли переданные параметры.
Multi Round-Trip Requests вместо постоянного bidirectional stream
Server-to-client сценарии — например sampling и elicitation — переработаны вокруг Multi Round-Trip Requests, или MRTR. Идея в том, чтобы не требовать постоянно открытого двунаправленного соединения только потому, что один запрос может потребовать нескольких раундов взаимодействия.
Для инфраструктуры это важнее, чем кажется: обычные HTTP-прокси, балансировщики и serverless-платформы проще сочетать с request/response моделью, чем с долгоживущими состояниями соединения.
List responses можно кешировать
В новой спецификации списки получают cache hints и детерминированный порядок. Для клиента это означает возможность не запрашивать каталог инструментов без необходимости на каждом переподключении.
Кеширование особенно полезно, когда набор инструментов большой, но меняется редко. При этом TTL и инвалидирование должны оставаться частью архитектуры: клиент не должен бесконечно работать со старым каталогом.
Расширения становятся формальной частью экосистемы
Спецификация закрепляет extensions framework. Такие возможности, как Tasks, могут развиваться как расширения, не заставляя каждое новое поведение немедленно становиться частью core protocol.
В обновлённой дорожной карте MCP от 22 августа 2026 года поддерживается тот же курс: базовый протокол остаётся проще, а дополнительные возможности развиваются через расширения и рабочие группы.
Изменения в авторизации
Релиз включает усиление авторизации, в том числе issuer validation по RFC 9207 и движение от Dynamic Client Registration к client metadata documents. Для разработчика вывод простой: при миграции нельзя ограничиваться транспортом и проигнорировать auth-часть.
Что проверить в существующем MCP server
- Какая версия спецификации поддерживается сервером и клиентом
- Есть ли логика, жёстко завязанная на старый handshake
- Используются ли sticky sessions только из-за протокола
- Готов ли gateway к новым заголовкам маршрутизации
- Корректно ли обрабатываются MRTR-сценарии
- Есть ли стратегия кеширования list responses
- Проверена ли обновлённая схема авторизации
- Покрыты ли миграционные изменения тестами
Мигрировать автоматически не стоит
Официальные материалы прямо называют релиз крупным и содержащим breaking changes. Поэтому стратегия «просто поменять номер версии» рискованна.
- Зафиксировать текущие клиенты и SDK.
- Проверить migration notes для используемого языка.
- Поднять тестовый сервер на новой спецификации.
- Прогнать discovery, tools/list, tool calls и авторизацию.
- Отдельно проверить ошибки, таймауты и повторные запросы.
- Только после этого переключать production-клиентов.
Что это меняет для serverless и edge
Stateless core лучше сочетается с архитектурой, где один запрос не гарантированно попадает в тот же процесс, что предыдущий. Это делает MCP удобнее для обычной горизонтальной инфраструктуры и edge/serverless-подходов.
При этом состояние приложения никуда не исчезает. Если бизнес-сценарию нужен долгоживущий job, история операции или блокировка повтора, это состояние по-прежнему нужно хранить в базе, очереди или другом устойчивом хранилище. Stateless относится к ядру протокола, а не ко всей прикладной системе.
MCP и обычные API: что выбрать
Если приложение вызывает один известный REST endpoint, добавлять MCP только ради модного названия не обязательно. Протокол становится полезнее, когда AI-клиенту нужно стандартно обнаруживать набор инструментов, их схемы и вызывать разные действия.
В реальном проекте MCP server часто остаётся адаптером к существующим API, а не заменой всех backend-интерфейсов.
Где A.S Groups может помочь
Для AI-проекта важна не только поддержка протокола, но и весь интеграционный слой: права, API, вебхуки, база, журналирование, защита от дублей и обработка отказов. Это относится к AI-автоматизации бизнеса и автоматизации бизнес-процессов.
Если MCP нужен рядом с WordPress или WooCommerce, бизнес-логику лучше держать в отдельном интеграционном слое или кастомном плагине, а не в случайном фрагменте темы.
Частые вопросы
Версия 2026-07-28 обратно совместима со старой без изменений?
Нет, релиз содержит breaking changes. Нужна проверка migration notes для конкретного клиента и SDK.
Stateless означает, что приложению больше не нужна база?
Нет. Протокол может быть stateless, а бизнес-процесс — хранить задания, историю, locks и другие данные во внешнем устойчивом хранилище.
Нужно ли теперь использовать Mcp-Method для авторизации?
Заголовок полезен для маршрутизации и policy checks, но серверная авторизация и валидация параметров всё равно обязательны.
Стоит ли переводить любой REST API на MCP?
Нет. Для фиксированного программного вызова REST может оставаться проще. MCP полезен прежде всего как стандартный интерфейс для AI-клиентов и набора инструментов.
Вывод
MCP 2026-07-28 делает remote-интеграции менее зависимыми от протокольного состояния и лучше приспособленными к обычной масштабируемой HTTP-инфраструктуре. Но релиз крупный: транспорт, MRTR, кеширование и авторизацию нужно проверять вместе.
Если вы строите AI-интеграцию с внешними сервисами и хотите оценить, нужен ли MCP в конкретной архитектуре, можно описать задачу A.S Groups без привязки к модному стеку — сначала определим требования к данным и действиям.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.