Протокол контекста модели достиг важной инфраструктурной вехи: его версия от 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 становится все более распространенным среди помощников по кодированию и корпоративных агентов, компаниям потребуются политики, определяющие, какие инструменты могут вызывать агенты, к каким данным они могут получить доступ и каким пользователям или службам разрешено их вызывать. Таким образом, усиление Authorization в новой версии не случайно. Это отражает реальность того, что доступ к инструментам теперь является границей безопасности, а не просто удобством для разработчиков.

Кто затронут

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

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

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

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

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

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

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

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

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

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