Протокол контекста модели достиг важной инфраструктурной вехи: его версия от 28 июля 2026 г. приближает протокол к ядру без сохранения состояния. Для команд, создающих системы агентов, серверы инструментов, интеграцию IDE или уровни оркестровки нескольких моделей, это не косметическое обновление спецификации. Это меняет представления о сеансах, инициализации, масштабировании, совместимости и управлении.

Кандидат на выпуск MCP описал спецификацию от 28 июля как добавление ядра протокола без сохранения состояния, платформы расширений, задач, приложений MCP, усиления авторизации и формальной политики прекращения поддержки. Официальный блог MCP также предупредил, что релиз содержит критические изменения. GitHub, который управляет одной из наиболее заметных реализаций сервера MCP, перед финальным выпуском заявил, что его сервер MCP уже поддерживает новую спецификацию, и 28 июля описал протокол как «переходя в состояние без сохранения состояния».

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

Что изменилось в MCP

Главное изменение — это переход на ядро ​​протокола без отслеживания состояния. В журнале изменений GitHub говорится, что новое ядро ​​удаляет сеансы и инициализируется с целью упростить масштабирование удаленных развертываний MCP. Это значительный архитектурный сдвиг. Протоколы с отслеживанием состояния могут хорошо работать для локальных инструментов и контролируемых сред, но они усложняют горизонтальное масштабирование, бессерверное выполнение, аварийное переключение, развертывание на периферии и балансировку нагрузки.

Ядро без сохранения состояния дает разработчикам больше свободы для запуска серверов MCP за обычной веб-инфраструктурой. Запросы можно распределять между экземплярами без сохранения долгоживущего сеанса на конкретном сервере. Для крупных организаций это может снизить сложность эксплуатации. Для небольших команд это может упростить развертывание размещенных серверов MCP с использованием управляемых вычислений вместо специальной долгоработающей инфраструктуры.

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

Ценой этого развития является работа по обеспечению совместимости. Блог MCP охарактеризовал этот выпуск как выпуск с критическими изменениями, а материалы TypeScript и C# SDK, опубликованные вокруг этой версии, сосредоточены на поддержке миграции и концепциях без сохранения состояния. Любая команда, эксплуатирующая сервер MCP, встраивающая MCP в расширение IDE или маршрутизирующая вызовы агента через внутреннюю инфраструктуру, должна рассматривать версию как инженерное событие, а не как фоновое обновление стандартов.

Почему MCP без сохранения состояния имеет значение для разработчиков и операторов

Инструменты агентов имеют проблему масштабирования, которая отличается от обычного масштабирования API. Один запрос пользователя может инициировать множество вызовов инструментов, поворотов модели, повторных попыток, чтения файлов, поисковых запросов и этапов утверждения. Когда протокол инструмента предполагает устойчивые сеансы, операторы производства должны сохранять состояние во время этих взаимодействий или создавать обходные пути вокруг протокола.

Удалив сеансы из ядра, MCP лучше подходит для сред, где рабочие нагрузки агентов являются пульсирующими, распределенными и асинхронными. Бессерверные функции, пограничные рабочие процессы, развертывания Kubernetes и многорегиональные системы — все это выигрывает, когда запросы можно обрабатывать независимо. Это не исключает состояние из приложений-агентов; оно перемещает состояние в базы данных приложений, очереди задач, системы идентификации или явные уровни рабочих процессов, а не встраивает его в ядро ​​протокола.

Для разработчиков это изменение должно в конечном итоге облегчить использование удаленных серверов инструментов. Для команд платформы это может упростить наблюдение и планирование мощности. Вместо отладки непрозрачного поведения привязки сеансов операторы могут сосредоточиться на отслеживании уровня запроса, задержке вызова инструментов, решениях по авторизации и шаблонах ошибок.

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

Кого это затронет

Наиболее непосредственно затронутые группы — это специалисты по обслуживанию серверов MCP, пользователи SDK, команды агентской платформы и организации, предоставляющие внутренние инструменты агентам ИИ. Если сервер зависит от поведения сеанса или старых потоков инициализации, ему потребуется тестирование на соответствие новой спецификации. Если приложение поддерживает несколько версий MCP, ему может потребоваться согласование версий, уровни совместимости или план поэтапной миграции.

В область действия также входят IDE и поставщики инструментов разработчика. MCP все чаще появляется вместе с агентами кодирования, пользовательскими агентами и функциями управления моделями. Ядро протокола без сохранения состояния позволяет этим продуктам надежно вызывать удаленные инструменты, но только в том случае, если их интеграция соответствует спецификации.

Компаниям, использующим автоматизацию агентов, следует обратить на это внимание, даже если они никогда не читали спецификацию MCP. Это изменение может повлиять на надежность агентов, подключающихся к репозиториям, системам обработки заявок, базам данных, внутренним базам знаний или инструментам развертывания. Во время периодов миграции вероятными видами сбоев являются не только очевидные сбои. Они могут включать в себя отсутствующие возможности инструмента, измененное поведение аутентификации или агенты, выбирающие разные пути, поскольку сервер инструментов больше не ведет себя должным образом.

Для шлюза AI API, такого как Model Gate, соединение практично. Унифицированный AI API все чаще сочетается с маршрутизацией моделей, управлением ключами API, аналитикой использования и командным управлением API. Поскольку агентские системы добавляют вызовы инструментов MCP помимо обычных вызовов моделей, уровни шлюза и наблюдения должны будут учитывать обе стороны рабочего процесса: какая модель использовалась, какие инструменты были вызваны, сколько они стоят, кто их авторизовал и где произошли сбои.

Приоритеты миграции и открытые вопросы

Первым приоритетом миграции является тестирование совместимости. Команды должны провести инвентаризацию клиентов и серверов MCP, определить зависимости от сеансов или инициализировать поведение, а также провести тестирование на соответствие SDK 2026-07-28 или материалам о соответствии, если таковые имеются. Производственные системы должны проводить обновление поэтапно, особенно если агенты выполняют действия с побочными эффектами, такие как создание запросов на включение, изменение проблем, запрос данных клиентов или выполнение рабочих процессов развертывания.

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

Третий приоритет – проверка авторизации. Если новая спецификация ужесточит семантику авторизации, разработчикам не следует просто переносить старые предположения о доступе в новую версию. Им следует перепроверить области действия токенов, делегирование пользователей, учетные записи служб, журналы аудита и поведение при отказе. По умолчанию доступ к инструментам должен быть с минимальными привилегиями, особенно для удаленных развертываний MCP.

Некоторые детали стоит проверить, прежде чем организации примут необратимые проектные решения. Исследование, доступное для этой статьи, включало кандидата на выпуск, страницу спецификации, материалы по миграции SDK и примечания по реализации GitHub. Окончательную нормативную формулировку спецификации 2026-07-28 следует просмотреть непосредственно перед тем, как указывать точные требования протокола во внутренних стандартах или документации для клиентов.

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