Опубликован обновлённый план развития Model Context Protocol (MCP), охватывающий следующий релиз спецификации и работу на более отдалённую перспективу.

Roadmap задаёт направление работы над протоколом на ближайшие месяцы. Документ разработан основными мейнтейнерами совместно с сообществом и рабочими группами проекта.

Ознакомиться с планом развития →

Приоритетные направления#

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

MCP Roadmap: пять приоритетных направлений — агентные примитивы обмена сообщениями, унификация и укрепление HTTP-транспорта, идентификация агентов и корпоративная безопасность, улучшенные примитивы, улучшенный опыт разработки с SDK.

Агентные примитивы обмена сообщениями#

Современные агентные нагрузки больше не укладываются в стандартный шаблон запрос-ответ. Циклы работы могут длиться дольше, серверы — передавать потоковые результаты, а необходимость управлять процессом на лету становится очевидной. MCP развивается, чтобы соответствовать этим требованиям: в протокол уже добавлены Tasks, subscriptions/listen и уведомления о прогрессе. Задача не только в том, чтобы предложить подходящие примитивы, но и в том, чтобы они корректно работали вместе. Работа охватывает события, инициируемые сервером (webhooks и каналы, чтобы клиентам не приходилось опрашивать сервер в ожидании результата), обзор композиции примитивов силами рабочих групп Agents, Transports и Triggers & Events, а также доработку расширения 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), попадающие в перечисленные приоритетные направления, получают ускоренное рассмотрение и имеют наибольшие шансы на принятие. Предложения вне этих направлений автоматически не отклоняются, но время мейнтейнеров ограничено и в первую очередь уходит на задачи из roadmap.

Тем, кто рассматривает подачу SEP, рекомендуется определить, к какому приоритетному направлению относится предложение, обсудить его с соответствующей рабочей группой и доработать вместе с её участниками. Для каждого направления в плане развития указаны ответственные основные мейнтейнеры, связаться с которыми можно через Discord. Команда проекта готова работать с сообществом над рассмотрением и развитием предложений, поддерживающих этот roadmap.

Как принять участие#

За каждым приоритетным направлением стоит рабочая группа — уже существующая или формирующаяся, — и в каждой из них есть место для новых участников. Возможные способы включиться в работу:

  • Присоединиться к рабочей или тематической группе: подробности на странице Working and Interest Groups и в каналах сообщества.
  • Предложить SEP или прокомментировать существующий: сначала стоит изучить рекомендации по SEP, затем открыть предложение или высказаться по уже существующему.
  • Начать экспериментальное расширение: SEP-2133 позволяет любой рабочей или тематической группе экспериментировать в репозитории с префиксом experimental-ext- ещё до подачи формального SEP.
  • Внести прямой вклад: в руководстве для контрибьюторов описана работа со спецификацией, SDK и инструментами.

Развитие MCP продолжается совместно с сообществом.