MCP, протокол для подключения AI-моделей и агентов к внешним инструментам, пережил крупнейшую ревизию с момента запуска в ноябре 2024 года. Для русскоязычной IT-аудитории смысл приземленный: протокол перестал требовать привязки клиента к конкретному серверу, а значит MCP-сервисы стало проще масштабировать в Kubernetes, облаке и любой другой стандартной инфраструктуре.
В блоге проекта ревизию 2026-07-28 прямо называют «крупнейшей с момента запуска». VentureBeat пишет о том же с корпоративного угла: MCP стал ближе к обычному HTTP-миру, где не нужно держать хрупкие сессии и городить sticky routing только ради того, чтобы агент не потерял контекст на очередном рестарте пода.
Протокол стал работать без серверных сессий
Главное изменение простое: из MCP убрали протокольную сессию и обязательный handshake через initialize/initialized. Раньше клиенту приходилось держаться за тот же инстанс сервера, который выдал ему Mcp-Session-Id. Для распределенной инфраструктуры это неудобно: нагрузка идет через балансировщик, инстансы регулярно пересоздаются, а любая зависимость от «того самого» узла превращается в лишнюю точку отказа.
Теперь запросы стали самодостаточными. Это не значит, что состояние приложения исчезло как класс. Просто MCP больше не навязывает его на уровне транспорта. Если сервису нужен контекст, разработчик может хранить его так же, как в обычном API: через явные идентификаторы, токены или внешнее хранилище. Для платформенных команд это означает более предсказуемую эксплуатацию и меньше самодельной обвязки вокруг протокола.
Именно здесь новость выходит за рамки обсуждения «внутренностей стандарта». Пока агент живет в демо, сессии терпимы. Когда речь идет о сотнях или тысячах параллельных вызовов, любой stateful-транспорт быстро начинает есть время DevOps-команды, бюджет на поддержку и нервы дежурных инженеров.
Авторизация стала ближе к OAuth и требованиям корпораций
Вторая важная часть обновления касается безопасности. Спецификация ужесточает правила авторизации и требует проверять параметр iss в ответах авторизации по RFC 9207. Это защита от класса mix-up-атак, когда клиент можно запутать и связать ответ не с тем сервером идентификации.
Параллельно в экосистеме закрепляют Enterprise-Managed Authorization — расширение для централизованного управления доступом через корпоративного провайдера идентификации, например Okta. Логика вполне взрослая: сотрудник не должен вручную раздавать согласия каждому MCP-серверу, а служба ИБ должна видеть, кто и к чему получил доступ. Для крупных компаний это не второстепенная деталь, а базовое условие внедрения.
Сюда же относится и новая политика устаревания функций. Между объявлением deprecated-статуса и возможным удалением возможности должно пройти не меньше 12 месяцев. Звучит скучно, но именно такие правила отличают протокол для реальной эксплуатации от быстро меняющегося лабораторного проекта.
Интерфейсы и длинные задачи вынесли в расширения
Еще одно заметное изменение: MCP окончательно делает ставку на расширения. В официальный контур вошли MCP Apps для server-rendered интерфейсов и Tasks для долгих асинхронных операций. Если агент запускает тяжелую обработку аудио, видео или пакетную задачу, соединение больше не нужно держать открытым до финала. Сервер может вернуть дескриптор задачи, а клиент — позже проверить статус, обновить его или отменить.
Практическая польза здесь в том, что разработчикам меньше приходится собирать собственные очереди и промежуточные механизмы поверх протокола. Продуктовые команды, в свою очередь, получают более понятный сценарий: агент не «завис», а честно работает как асинхронная система.
Обратная сторона тоже есть. Часть данных теперь придется чаще передавать в самих запросах, а некоторые старые возможности, вроде встроенного logging-механизма на уровне протокола, уходят в deprecated. Но это выглядит как нормальный обмен: меньше магии, больше совместимости с тем, как уже устроены зрелые HTTP-сервисы и наблюдаемость в продакшене.
Значение для рынка
Для российского и СНГ-рынка это важная новость прежде всего для команд, которые строят внутренние AI-платформы, корпоративных помощников и интеграции поверх Kubernetes, API-шлюзов и SSO. MCP становится менее «протоколом для энтузиастов» и больше похож на инфраструктурный стандарт, который можно согласовать с архитекторами, безопасниками и эксплуатацией без отдельной религии вокруг сессий. Проще говоря: меньше экзотики в транспорте, меньше причин отказаться от пилота на этапе внедрения.
Следующий практический вопрос теперь не в популярности MCP, а в миграции: насколько быстро клиенты, SDK и серверы экосистемы подтянут поддержку ревизии 2026-07-28 без новых несовместимостей.