Безсостоянийный MCP в спецификации от 2026-07-28: Какие изменения коснутся инфраструктуры агентов.
Новая версия MCP устраняет поддержку сессий, добавляет заголовки маршрутизации, функцию input_required для двусторонних запросов и усиленные механизмы OAuth. Что это означает для шлюзов, масштабирования и безопасности.
Источники: MCP Goes Stateless: Why the New Spec Changes Agent Infrastructure
Протокол Model Context быстро развивался. Изначально обсуждения касались связи приложений ИИ с инструментами и данными. С тех пор он прошел через механизмы авторизации OAuth, использование удаленных серверов, крупные обновления протокола, реестры, документы метаданных Client ID и системы корпоративной авторизации. Спецификация от 2026-07-28 вносит изменения в более фундаментальные аспекты: сам протокол становится безсостоянийным.
Этап инициализации и сессии на уровне протокола исчезли. Клиенту больше не нужно оставаться привязанным к той конкретной инстанции сервера, которая приняла его подключение. Каждый запрос содержит достаточно информации, чтобы обрабатываться самостоятельно, и любая совместимая инстанция может на него ответить.
Это может показаться просто корректировкой в области транспортировки данных, но архитектурные последствия гораздо глубже. Временные серверы могут вести себя как любой облачный HTTP-сервис, работая за обычными балансировщиками нагрузки, API-шлюзами, системами защиты от атак, платформами без серверов и масштабируемыми флотами контейнеров, при этом не требуется специального оборудования для управления сессиями, характерного для MCP.
Эта версия вносит ещё множество улучшений: стандартные заголовки маршрутизации, результаты поиска, которые можно кэшировать, многократные запросы, более строгие правила авторизации, стандарты OpenTelemetry и формальная модель расширений. MCP становится менее уникальным с точки зрения инфраструктуры, что, возможно, является одним из явных признаков зрелости. Далее рассматриваются внесённые изменения, почему отсутствие состояния важно в производственной среде и какое это имеет значение для безопасности, шлюзов и общей среды выполнения агентов.
Почему сессии мешают
MCP возник из-за простой проблемы: необходимости предоставить приложениям искусственного интеллекта стандартный способ взаимодействия с инструментами, ресурсами и внешними системами. Для локальных клиентов и серверов это работало естественным образом. Однако удаленная версия MCP изменила ситуацию. Когда серверы начали работать в контейнерах, кластерах Kubernetes, платформах без серверов и облачной инфраструктуре, сессии на уровне протокола вызывали те же проблемы, что и в распределенных системах.
Клиент инициировал процедуру инициализации, сервер мог выдать Mcp-Session-Id, и каждый последующий запрос должен был сохранять эту связь. В масштабах это могло означать:
- функцию привязки к конкретному серверу у балансировщика нагрузки
- общие хранилища сессий
- механизм переключения на резервный сервер, понимающий сессии
- долговременные соединения
- дополнительное управление жизненным циклом
Ничто из этого не является неразрешимым для управления, ведь распределённые системы справляются с этим уже десятилетиями. Важно спросить, действительно ли MCP был обязан создавать эти проблемы, и с датой 2026-07-28 ответ всё чаще — нет.
Новая спецификация полностью устраняет процедуры initialize и notifications/initialized, сессии на уровне протокола и Mcp-Session-Id. Запросы содержат всё необходимое для их обработки. Концептуально архитектура меняется следующим образом:
Любая совместимая инстанция может обработать следующий запрос. Это гораздо лучше сочетается с Kubernetes, контейнерами, безсерверными функциями, автомасштабированием, инфраструктурой на периферии и обычным круговым балансировкой нагрузки.
Это уже происходит на практике. Cloudflare перевел свои серверы MCP на эту модель и создает новый безсостоянийный сервер для каждого запроса. Google называет окончание использования «липких сессий» и совместной инфраструктуры сессий значительным преимуществом для масштабирования. AWS AgentCore Gateway теперь поддерживает новый протокол наряду с более ранними версиями MCP. Следовательно, это является частью современной модели развертывания, а не теоретической архитектурой.
Состояние не исчезает
Здесь важно сделать одно различие. Удаление сессий MCP не мешает приложениям сохранять состояние. Это означает, что состояние приложения не должно храниться внутри механизма передачи данных. Возьмем пример агента, создающего рабочее пространство:
create_workspace()
|
v
workspace_id = ws_123
В более позднем запросе можно явно указать результат:
update_workspace( workspace_id = "ws_123" )
Первый запрос может попасть на сервер A, а второй — на сервер C. У приложения по-прежнему есть состояние, но теперь у него есть явный идентификатор, и оно не зависит от невидимой связи между клиентом и процессом сервера.
Состояние протокола и состояние приложения — это разные вещи. Явное состояние приложения легче сохранять, аудитировать, авторизовать, истекать и анализировать, а системы с агентами получают дополнительное преимущество: агент может напрямую работать с идентификатором и передавать его между инструментами и этапами рабочего процесса.
Заголовки маршрутизации
Отсутствие состояния решает одну проблему инфраструктуры, но другое изменение может быть таким же важным для корпоративных развертываний. MCP теперь стандартизирует HTTP-заголовки, описывающие текущую операцию. Например:
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: delete_workspace
Раньше посреднику, возможно, приходилось распаковывать данные JSON-RPC, чтобы понять, чего хочет агент. Теперь эта информация доступна на уровне HTTP, что открывает ряд интересных возможностей.
У команд по безопасности есть причины для беспокойства. Агенты получают доступ к более мощным инструментам, и шлюз становится естественным местом для реализации правил, регулирующих взаимодействие между намерением агента и его внешними действиями. Однако это не устраняет необходимости в механизмах управления агентами или на уровне приложений. Более того, это помогает четче разграничить протокол, шлюз, механизмы управления и системы, находящиеся за ними.
Запрос информации без сессии
Переход к безсостоянийному режиму создаёт очевидную проблему. Что делать, если серверу нужна дополнительная информация перед завершением операции? Представьте разрушительный запрос:
delete_environment(“production”)
Сервер может сначала потребовать подтверждения. Поддержание открытой двунаправленной сессии только для данного обмена информацией лишило бы нас большинства преимуществ отсутствия состояния.
Ответом в спецификации являются многократные запросы с обратным ходом (MRTR). Сессия больше не поддерживает активность взаимодействия. Вместо этого сервер возвращает результат input_required, указывающий, что ему нужно. Процесс обмена происходит примерно так:
Подтверждение человеком, дополнительная аутентификация, отсутствующие параметры, проверки политик и другие интерактивные этапы могут быть включены в модель запросов без состояния. Это особенно важно для действий агентов с высоким риском. Способность вызывать инструменты не даёт агенту неограниченных полномочий, а чувствительные операции могут включать этап принятия решения перед их выполнением.
Кэширование и наблюдаемость
Некоторые менее заметные изменения могут оказаться важными в масштабе. К ним относятся операции списания:
tools/list
prompts/list
resources/list
resources/read
Теперь можно возвращать детали кэша, такие как ttlMs и cacheScope, причем список инструментов должен возвращаться в определенном порядке. Это кажется обычной оптимизацией HTTP, но от этого выигрывают и системы ИИ: стабильные определения инструментов позволяют улучшить кэширование промптов на уровне больших языковых моделей, тогда как инструменты, поступающие в изменчивом порядке или требующие повторного поиска, превращают незначительную особенность протокола в дополнительную задержку и увеличение затрат на токены.
В спецификации также описано, как передавать контекст OpenTelemetry с использованием знакомых полей:
traceparent
tracestate
baggage
Это ещё один пример того, как MCP смещается в сторону инфраструктуры, уже знакомой командам DevOps и платформ. Целью не должна быть создание отдельной стек-технологий для наблюдаемости, предназначенной исключительно для протоколов ИИ. Необходимо сделать активность агентов видимой внутри систем, которыми уже управляют организации.
Идентификация становится всё важнее
Безсостоянийные запросы не снижают значимости идентификации. Наоборот, они делают критически важным правильную обработку каждого отдельного запроса. Новые спецификации продолжают движение MCP в направлении устоявшихся практик OAuth и OpenID Connect. Это включает проверку эмитента для предотвращения атак, связанных с путаницей с серверами авторизации, а также более строгую привязку учетных данных.
В спецификации также официально закреплен тенденций, существовавший ранее: динамическая регистрация клиентов отменяется в пользу документов метаданных Client ID. CIMD постепенно становится более подходящим вариантом, в то время как DCR сохраняется ради совместимости, и теперь это прямо указано в тексте. Это ещё один признак зрелости решения, поскольку MCP избегает использования приватных систем идентификации и продолжает сближаться со стандартами, уже используемыми в Интернете. Для развертывания корпоративных агентов это имеет особое значение по мере того, как MCP развивается от нескольких интеграций, разрешённых пользователями, до большого количества агентов, клиентов, шлюзов и инструментов.
Регистрация — это лишь часть процесса авторизации. На уровне крупных предприятий более сложным вопросом является определение того, какие агенты могут использовать какие функции: сотни агентов, обращающихся к сотням сервисов, создают серьезные проблемы с управлением в формате N×M. Два механизма — управление авторизацией на уровне предприятия (Enterprise-Managed Authorization, EMA) и разрешения на авторизацию на основе подтверждения идентичности (Identity Assertion Authorization Grants, ID-JAG) — позволяют сосредоточить эти вопросы в централизованных правилах предприятия. Провайдер идентичностей предприятия помогает решить, получит ли агент доступ, поэтому отдельным серверам MCP не нужно запрашивать согласие у пользователей по отдельности.
Безсостоянийный MCP не заменяет эту модель. Он усиливает разделение компонентов: состояние передачи данных, идентичность клиента, политика авторизации и состояние приложения представляют собой отдельные архитектурные аспекты.
Что остается вне ядра
Важной частью обновления является то, что удаляется или перемещается в MCP. Функции Roots, Sampling и Logging покидают основную модель, а старый способ передачи данных HTTP+SSE заменяется на Streamable HTTP. Одновременно появляется формальная рамка для расширений, что позволяет таким функциям, как Tasks, развиваться в виде расширений без увеличения объема основного протокола. Это обеспечивает более четкое разделение обязанностей:
MCP не обязан становиться полностью рабочей средой агента. Сама рабочая среда по-прежнему контролируется внешними компонентами, а MCP предоставляет стандартный способ взаимодействия этой среды с внешними функциями. Зрелый протокол определяется не только тем, что он добавляет, но и тем, что он решает оставить за пределами своей структуры.
Отсутствие состояния не означает доверия
Сервер MCP без состояния масштабируется проще, однако отсутствие состояния не означает доверия: каждый запрос всё равно пересекает границы безопасности. Внедрение вводимых данных или подделка контекста могут по-прежнему влиять на поведение агентов. Инструменты могут иметь чрезмерные привилегии, учетные данные могут быть неправильно настроены, а угрозы в цепочке поставок могут привести к появлению злонамеренных серверов или инструментов.
Изменение заключается в том, что архитектура становится более чистой. Вместо того чтобы рассматривать сессии передачи данных как часть модели безопасности, защита может сосредоточиться на том, кто является вызывающей стороной и может быть подтвержден, какие правила соблюдает шлюз и какие разрешения предоставляет каждый инструмент. Необходимо добавить явное авторизование и явные идентификаторы ресурсов, затем проверять входные данные, требовать одобрения человеком чувствительных действий, записывать телеметрию для аудита и также контролировать работу агента.
Один важный момент: метаданные клиента не являются автоматически его идентификатором. То, что клиент указывает о себе в метаданных запроса, нельзя рассматривать как идентификатор, установленный криптографически с помощью OAuth или другого надежного механизма. Упрощенное маршрутизирование и анализ трафика MCP позволяют командам по безопасности усилить контроль за соблюдением протокола, не путая метаданные с доказательством доверия.
Более широкая картина
Основное изменение, произошедшее в 2026-07-28, заключается в простом факте: MCP является безсостоянийским. Более важным является то, что это позволяет делать. Запросы MCP ведут себя более похоже на обычные HTTP-задачи. Серверы масштабируются горизонтально без необходимости сохранения информации о сессиях. Шлюзы понимают операции MCP благодаря стандартным заголовкам. Процесс обнаружения может быть кэширован. Интерактивные рабочие процессы продолжаются с использованием многократных запросов. Механизмы авторизации постепенно переходят к проверенной практике OAuth, для отслеживания деятельности можно использовать OpenTelemetry, а расширения позволяют развиваться без необходимости преобразования ядра в полноценную среду выполнения агентов.
По отдельности они кажутся улучшениями протокола, но вместе они говорят о чём-то большем. MCP началось с решения проблемы подключения. Распределённый MCP заставил экосистему столкнуться с вопросами идентификации и авторизации. CIMD и корпоративная авторизация сейчас направлены на управление, в то время как безсостоянийный MCP занимается операционной способностью и масштабируемостью. Протокол становится менее экзотичным и подходит для инфраструктуры, строительство, защиту, мониторинг и эксплуатация которой люди уже умеют осуществлять. Для чего-то, развивающегося так быстро, превращение в скучную инфраструктуру может быть именно целью.
Связанные материалы
- Практические заметки: «MCP: протокол, превращающий ИИ из чат-бота в агента ИИ» — Подробное руководство по использованию практических заметок: «MCP: протокол, превращающий ИИ из чат-бота в агента ИИ», включающее информацию о контрактах, проверках и готовых фрагментах кода для команд, разрабатывающих системы на основе MCP.
- Создание локального исследовательского агента в LM Studio с использованием четырех серверов MCP» — Объединение серверов файловой системы, GitHub, SearXNG и Camofox MCP в одном чате LM Studio, оптимизация схемы инструментов, добавление промпта для планирования исследований и проверка корректности работы с помощью демо-версии.