Model Context Protocol 2026-07-28: что меняет переход на stateless для команд разработки

Коротко о главном

28 июля 2026 года вышла финальная версия спецификации Model Context Protocol (MCP) 2026-07-28: протокол стал stateless, получил маршрутизацию по HTTP-заголовкам, официальные расширения Tasks и MCP Apps, а три устаревших механизма (Roots, Sampling, Logging) получили 12-месячное уведомление об удалении. Обновлённые SDK для TypeScript, Python, Go и C# уже доступны; Rust-SDK — в бета-версии.

Для команд, которые строят ИИ-продукты и агентные системы или интегрируют агентов в корпоративную инфраструктуру, это самое весомое изменение MCP с момента его появления: stateless-архитектура устраняет главный инфраструктурный барьер для production-деплоев, а формализованный фреймворк расширений даёт предсказуемый путь миграции на новые версии.

Ключевой практический вывод: MCP-сервер, которому раньше требовались sticky sessions и общее хранилище для состояния сессий, теперь деплоится за обычным round-robin балансировщиком без каких-либо изменений инфраструктуры. Это делает интеграцию агентов напрямую совместимой со стандартными паттернами разработки API и облачными управляемыми сервисами.

Что изменилось в спецификации 2026-07-28

Самое значимое изменение — полный переход на stateless-ядро. Предыдущие версии MCP требовали рукопожатия initialize/initialized и отслеживания сессий через заголовок Mcp-Session-Id. Новая спецификация убирает и то, и другое: клиент передаёт свои возможности через поля _meta в каждом запросе, а сервер не хранит состояние между вызовами.

На практике это означает, что MCP-сервер теперь ведёт себя как стандартный REST API. Его можно горизонтально масштабировать, деплоить в Kubernetes без настройки session affinity, прогонять через любой HTTP-прокси или WAF. Это снимает архитектурное ограничение, которое заставляло многие команды использовать сложные обходные решения в production.

Второе крупное нововведение — маршрутизация на уровне заголовков. Запросы теперь несут заголовки Mcp-Method и Mcp-Name, что позволяет шлюзам и файрволам принимать решения о маршрутизации и политиках без разбора тела JSON. Это важно для корпоративных сред, где WAF и API-шлюзы должны видеть семантику запроса на уровне заголовков.

Третье изменение — кэшируемые результаты операций перечисления (list). Ответы на list-запросы теперь несут параметры ttlMs и cacheScope, что позволяет клиентам реализовать интеллектуальное кэширование и снизить количество повторных запросов к серверу. Для агентных рабочих процессов, где одни и те же инструменты используются в сотнях итераций, это ощутимо сокращает задержку.

Multi Round-Trip Requests: конец однонаправленных вызовов

В предыдущих версиях MCP для запросов, инициируемых сервером в середине вызова, требовалось держать открытый поток. Это создавало проблемы с load balancers и отказоустойчивостью. Спецификация 2026-07-28 вводит Multi Round-Trip Requests (MRTR): сервер может запросить у пользователя дополнительный ввод, вернув resultType: "input_required" с описанием нужных данных, а клиент повторит вызов с inputResponses.

На практике это меняет паттерн построения инструментов с подтверждением. Раньше любой инструмент, требующий промежуточного пользовательского ввода (например, «Подтвердите удаление 47 записей»), приходилось либо разбивать на несколько отдельных вызовов, либо держать открытый WebSocket-канал. Теперь это штатный HTTP round-trip, совместимый со всеми стандартными компонентами инфраструктуры.

Официальные расширения: Tasks и MCP Apps

Одновременно со stateless-ядром MCP вводит формальный фреймворк расширений с идентификаторами в формате reverse-DNS, независимым версионированием и делегированными мейнтейнерами. Два официальных расширения дебютируют вместе со спецификацией.

Расширение Tasks (io.modelcontextprotocol/tasks) формализует жизненный цикл длительных операций. Задачи теперь работают через механизм опроса (polling) с подпиской на уведомления, что хорошо совмещается со stateless-архитектурой: клиент может переподключиться к задаче после разрыва соединения, не теряя её результатов.

Расширение MCP Apps позволяет серверам возвращать HTML-интерфейсы, рендеримые в изолированных iframe'ах. Это открывает путь для агентов, которым нужно показать пользователю структурированную форму или результат с интерактивными элементами, не выходя за рамки протокола.

Упрочнение авторизации и устаревшие компоненты

Спецификация 2026-07-28 вносит шесть изменений (SEP) в схему авторизации, укрепляя соответствие OAuth и OpenID Connect. Ключевые: обязательная валидация параметра iss по RFC 9207, явное объявление application_type при регистрации клиента, переход от Dynamic Client Registration (DCR) к Client ID Metadata Documents (CIMD) и привязка учётных данных к выдавшему их серверу авторизации.

Для команд, которые уже развернули MCP с OAuth, это означает необходимость обновить логику регистрации клиентов. Изменения обратно несовместимы в части DCR, поэтому обновление SDK — обязательный шаг, а не опциональный.

Параллельно три компонента получили уведомление об устаревании с минимальным 12-месячным окном перед удалением: Roots (заменяется параметрами инструментов), Sampling (прямой вызов LLM API) и Logging (stderr или OpenTelemetry). Устаревает и HTTP+SSE транспорт — в пользу чистого HTTP. Если ваш MCP-клиент использует какой-либо из этих механизмов, планируйте миграцию на горизонте 2027 года.

Поддержка в Amazon Bedrock AgentCore и отраслевое принятие

Параллельно с выходом спецификации AWS объявил о поддержке MCP 2026-07-28 в Amazon Bedrock AgentCore. Это означает, что агентные рабочие процессы, деплоируемые в управляемой инфраструктуре AWS, получают встроенную поддержку stateless-ядра и новых расширений без дополнительной настройки. Аналогичные заявления о поддержке сделал ряд других крупных облачных и AI-платформ.

Для enterprise-команд это важный сигнал: стандарт получил подтверждение от крупнейших платформенных игроков, что снижает риск фрагментации реализаций, которая была заметна на ранних этапах развития протокола.

Что делать команде прямо сейчас

Обновите SDK. TypeScript, Python, Go и C# SDK обновлены до версии спецификации 2026-07-28. Начните с тестовой среды и убедитесь, что ваши MCP-серверы корректно обрабатывают запросы без session-заголовков.

Проверьте авторизацию. Если ваши MCP-клиенты используют Dynamic Client Registration, запланируйте переход на Client ID Metadata Documents (CIMD) — старый механизм помечен как устаревший. Вендор вашего IdP может уже поддерживать новую схему; уточните это до начала миграции.

Оцените использование устаревших механизмов. Проверьте, используют ли ваши реализации Roots, Sampling, Logging или HTTP+SSE транспорт. 12-месячное окно достаточно, но лучше начать планирование сейчас, чтобы не оказаться в ситуации срочной миграции под дедлайн середины 2027 года.

Пересмотрите инфраструктурные решения. Если вы откладывали горизонтальное масштабирование MCP-серверов из-за проблем с сессиями, stateless-архитектура снимает это ограничение. Стандартный round-robin балансировщик теперь работает без sticky sessions.

Изучите расширения. Tasks и MCP Apps покрывают два распространённых сценария, которые раньше требовали нестандартных решений: длительные операции и промежуточный ввод пользователя. Если в вашей кодовой базе есть обходные решения для этих случаев, оцените переход на официальные расширения.

Часто задаваемые вопросы

Нужно ли немедленно мигрировать с предыдущих версий MCP? Немедленного прекращения поддержки нет. Устаревшие механизмы (Roots, Sampling, Logging, HTTP+SSE) получили минимальное 12-месячное окно. Рекомендуется начать планирование миграции, но срочности в масштабе недель нет — если речь не идёт об авторизации через DCR, которую стоит обновить при первом удобном цикле обновлений.

Совместима ли новая спецификация с существующими MCP-серверами? На уровне протокола stateless-изменения несовместимы с реализациями, полагающимися на session handshake. Обновлённые SDK абстрагируют это — обновление библиотеки, как правило, достаточно. Проверьте релизные заметки SDK вашего языка для конкретных инструкций.

Что означает расширение Tasks для агентных пайплайнов? Tasks формализует паттерн «запустил и опрашиваю статус» для длительных операций. Если ваш агент уже реализует подобное вручную, расширение предлагает стандартизированный API с нотификациями, совместимый с любым MCP-клиентом.

Требует ли переход на stateless изменений в деплойменте? Если вы деплоите MCP-серверы за балансировщиком с настроенным session affinity — этот режим больше не нужен. Это упрощает конфигурацию, но требует проверки: убедитесь, что ваши серверы действительно перестали хранить состояние между запросами, прежде чем убирать sticky sessions в production.

Источники

Model Context Protocol Blog — The 2026-07-28 Specification, официальный блог MCP, 28 июля 2026 года.

Model Context Protocol Blog — The 2026-07-28 MCP Specification Release Candidate, официальный блог MCP, 21 мая 2026 года.