Организация Model Context Protocol опубликовала спецификацию от 28 июля 2026 года, которая стала самым масштабным изменением протокола с момента его создания. Ключевым нововведением стал переход к архитектуре без сохранения состояния (stateless), а также внедрение системы управляемых расширений и ужесточение механизмов авторизации.
Для разработчиков, использующих облачную инфраструктуру Amazon, поддержка новой версии уже доступна через шлюз AgentCore Gateway на платформе Bedrock. Активация обновленного стандарта не требует сложной миграции и выполняется путем отправки единственного запроса UpdateGateway.
Эти изменения направлены на повышение безопасности и масштабируемости взаимодействий между моделями искусственного интеллекта и внешними источниками данных. Переход на новый стандарт позволяет устранить риски, связанные с хранением контекста, и обеспечивает более строгий контроль над подключаемыми расширениями.
комментарий редакции
Что это значит
Вероятно, это обновление станет новым отраслевым базисом для безопасного оркестрирования ИИ-агентов. Следующим наблюдаемым сигналом станет появление инструментов от других облачных провайдеров, поддерживающих эту спецификацию. Основной неопределенностью остается скорость отказа сообщества от старых версий протокола, сохраняющих состояние.
Дополнительные оценки
Ollama Cloud
GLM 5.2
Переход MCP к stateless-архитектуре — стратегический сдвиг, устраняющий класс уязвимостей, связанных с сохранением контекста, и облегчающий горизонтальное масштабирование. AWS первой объявила поддержку через единый вызов UpdateGateway, что усиливает позиции Bedrock как платформы быстрой адаптации. Следующим сигналом станут аналогичные объявления от Google Cloud и Azure. Главная неопределённость — обратная совместимость: без независимого подтверждения технических деталей из других источников масштаб миграционных рисков для существующих интеграций остаётся неясным.
В чём оценки сходятся- Переход к stateless-архитектуре действительно указывает на зрелость протокола и подготовку к промышленному масштабированию, где безопасность важнее удобства локального контекста.
- Активация через один вызов UpdateGateway — реалистичный механизм минимизации трения для разработчиков на платформе AWS.
- Появление поддержки спецификации у других облачных провайдеров — логичный следующий наблюдаемый сигнал конкурентного рынка.
- Заявление о том, что обновление «станет новым отраслевым базисом», преждевременно: пакет содержит только первичный источник AWS без независимого подтверждения.
- Отсутствие корроборации (corroborated: false) снижает уверенность: технические детали известны лишь из мета-описания блога, а не из полной спецификации.
- Утверждение о «новом отраслевом базисе» не учитывает риск фрагментации: управляемые расширения могут породить vendor lock-in, замедляя принятие стандарта.
Ollama Cloud
Kimi K2.6
Переход MCP к stateless-архитектуре с управляемыми расширениями и усиленной авторизацией — логичный шаг к промышленной зрелости протокола, но ключевой неопределённостью остаётся скорость миграции экосистемы: AWS упрощает процесс для своих клиентов через UpdateGateway, однако разработчики сторонних инструментов и альтернативных платформ могут столкнуться с фрагментацией совместимости. Следующим значимым сигналом будет анонс поддержки спецификации 2026-07-28 со стороны Google Cloud, Azure или открытых фреймворков вроде LangChain — отсутствие такого сигнала в течение квартала укажет на риск изоляции AWS-центричного стандарта.
В чём оценки сходятся- Переход к stateless-архитектуре действительно отражает зрелость протокола и приоритет безопасности над локальным удобством.
- Единый вызов UpdateGateway для активации — эффективная стратегия снижения трения и ускорения адаптации.
- Обновление закладывает базис для отраслевых стандартов безопасного оркестрирования агентов.
- Конфиденс high завышен: единственный источник — AWS-блог без корроборации, что создаёт риск маркетинговой искажённости.
- Формулировка «крупнейший пересмотр с момента запуска» не верифицируема без данных о предыдущих версиях и их масштабе.
- Утверждение о «устранении уязвимостей состояния» преждевременно: stateless-архитектура смещает, а не устраняет риски — например, в вопросах аутентификации при каждом запросе.