ИИтог

MCP опубликовал новую дорожную карту: агентные сообщения, HTTP и идентификация агентов

инфраструктураРедакция ИИтогHacker News🔥70Рейтинг ИИтог70Влияние62Новизна58Релевантность100Неожиданность42Участники75Достоверность88

Основные разработчики (Core Maintainers) протокола Model Context Protocol (MCP) вместе с сообществом мейнтейнеров и рабочими группами опубликовали обновлённую дорожную карту протокола, которая задаёт направление работы на ближайшие месяцы, на следующий релиз спецификации и далее. Дорожная карта организована вокруг пяти приоритетных направлений; часть из них, это темы, которые предыдущая дорожная карта отмечала как «на горизонте» (события, инициируемые сервером, улучшения типов результатов, идентификация агентов), но которые с тех пор созрели до статуса самостоятельных приоритетов.

Первое направление, примитивы для агентного обмена сообщениями. Современные агентные нагрузки больше не укладываются в схему «запрос-ответ»: циклы работы могут идти дольше, серверы, передавать потоковые результаты, а пользователю нужно управлять работой агента на лету. MCP уже добавил задачи (Tasks), подписки (subscriptions/listen) и уведомления о прогрессе; дальнейшая работа охватывает события, инициируемые сервером (вебхуки и каналы, чтобы клиенты не были вынуждены постоянно опрашивать сервер), сверку компоновки между рабочими группами по агентам, транспортам и триггерам/событиям, а также доработку расширения Tasks (предложение SEP-2663) до включения в спецификацию.

Второе направление, унификация и укрепление HTTP-транспорта. С релизом от 2026-07-28 удалённый MCP-сервер стал ничем не отличим от обычной HTTP-нагрузки, и его можно разворачивать на любой инфраструктуре, уже используемой для API и сервисов. Разработчики хотят распространить этот подход и на другие варианты развёртывания, включая локальные серверы, работающие через Streamable HTTP поверх stdio, унификация на одном транспорте должна упростить разработку MCP-серверов и клиентов.

Третье направление, идентификация агентов и корпоративная безопасность. Сегодня авторизация в MCP построена вокруг того, что человек подтверждает доступ в браузере; это хорошо работает для интерактивных клиентов, но всё больше вызовов приходит от агентов, работающих как облачные нагрузки со своей идентичностью, действующих от имени отсутствующего пользователя или делегирующих более узкие полномочия под-агентам. Команда хочет дать MCP-серверам стандартизированный способ распознавать и доверять таким агентным идентичностям, опираясь на существующие стандарты, а не на вставленные в код API-ключи и долгоживущие токены. Работа включает завершение механизма Demonstrating Proof of Possession (DPoP, доказательство обладания ключом) и продвижение его внедрения, а также определение пути для идентификации и делегирования полномочий агентов через федерацию идентичности рабочих нагрузок (Workload Identity Federation), грант ID-JAG, лежащий в основе Enterprise-Managed Authorization, и стандартный обмен токенами. Разработчики также продолжат взаимодействие с органами стандартизации OAuth, включая рабочие группы IETF OAuth и WIMSE.

Четвёртое направление, улучшенные примитивы. Вызов инструментов (tool calling), часть MCP, с которой разработчики сталкиваются первой, и она неплохо показала себя за время жизни протокола; слабое место, обработка результатов: ответ tools/call может нести один и тот же результат в нескольких формах, и разработчик сервера сегодня не знает заранее, какую форму клиент покажет модели. Дорожная карта предполагает стандартизацию на одном чётком контракте. Вторая проблема примитивов, их постоянно растущий масштаб: подключение к серверу с сотней инструментов означает, что модель «оплачивает» контекстом всю эту поверхность ещё до первого вопроса пользователя, а качество выбора инструмента ухудшается по мере роста списка. Разработчики начинают работу над постепенным раскрытием каталога (progressive discovery), чтобы сервер мог показывать небольшую точку входа и раскрывать больше возможностей по мере того, как разговор сужается до конкретной задачи.

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

Предложения по улучшению спецификации (SEP), которые попадают в эти приоритетные направления, получают ускоренное рассмотрение и имеют больше шансов на принятие; предложения вне этих направлений не отклоняются автоматически, но время мейнтейнеров на рассмотрение ограничено и в первую очередь уходит на приоритетные темы. У каждого направления есть рабочая группа, к которой можно присоединиться, а начать можно и с экспериментального расширения по механизму SEP-2133, он позволяет любой рабочей или интересной группе поэкспериментировать в отдельном репозитории до подачи формального SEP.

Ключевые факты

  • Основные разработчики MCP вместе с сообществом мейнтейнеров и рабочими группами опубликовали обновлённую дорожную карту протокола, организованную вокруг пяти приоритетных направлений.
  • Первое направление, примитивы для агентного обмена сообщениями: события со стороны сервера (вебхуки, каналы) и доработка расширения Tasks (SEP-2663) до включения в спецификацию.
  • Второе направление, унификация HTTP-транспорта: после релиза 2026-07-28, сделавшего удалённый MCP-сервер обычной HTTP-нагрузкой, унификацию хотят распространить и на локальные серверы через Streamable HTTP поверх stdio.
  • Третье направление, идентификация агентов и безопасность для бизнеса: завершение DPoP, делегирование полномочий через Workload Identity Federation и грант ID-JAG вместо API-ключей и долгоживущих токенов.
  • Четвёртое и пятое направления, единый контракт для результатов вызова инструментов вместе с постепенным раскрытием каталога инструментов (пример, сервер с сотней инструментов) и улучшение SDK для разработчиков.

Почему это важно

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

Кому это важно

Разработчикам, которые пишут MCP-серверы и клиенты: им обещают более простой единый HTTP-транспорт, чёткий контракт для результатов вызова инструментов и лучше документированные SDK. Командам, отвечающим за безопасность и инфраструктуру в компаниях, где агенты работают как самостоятельные облачные нагрузки без человека за экраном, им адресовано направление по идентификации агентов и делегированию полномочий. Участникам рабочих групп и авторам предложений по улучшению спецификации (SEP), дорожная карта прямо говорит, какие темы получат приоритетное рассмотрение.

Как это применить

Разработчик, планирующий SEP, должен сверить тему с пятью приоритетными направлениями и обсудить её с соответствующей рабочей группой, так предложение получит ускоренное рассмотрение. Можно начать с experimental-ext-репозитория по механизму SEP-2133, не дожидаясь формального предложения. Для серверов с большим числом инструментов уже сейчас стоит следить за появлением progressive discovery, механизма, который позволит не отдавать модели весь каталог инструментов сразу.

Можно ли доверять

Материал, официальный анонс на блоге Model Context Protocol, подписанный Core Maintainers протокола, а не сторонний пересказ. Конкретика подтверждена номерами предложений (SEP-2663, SEP-2133) и датой прошлого релиза (2026-07-28), что снижает риск маркетингового приукрашивания. В источнике не названы ни конкретные авторы текста, ни компании и продукты, которые уже строят решения на MCP, ни сроки выхода следующего релиза спецификации, то есть материал описывает намерения и приоритеты, а не завершённую работу.

Риски и подводные камни

Дорожная карта, это список приоритетов и намерений, а не готовая спецификация: сроков реализации пяти направлений и даты следующего релиза спецификации в тексте нет. Направление по идентификации агентов опирается на развитие внешних стандартов (OAuth, IETF WIMSE), а значит зависит не только от команды MCP. Предложения вне пяти приоритетных направлений не отклоняются формально, но получат меньше внимания мейнтейнеров, риск того, что часть полезных инициатив сообщества будет откладываться.