Команда MCP опубликовала обновлённую дорожную карту Model Context Protocol. В ней обозначены ближайший выпуск спецификации и более дальние ориентиры развития протокола.

Документ задаёт рабочий курс на предстоящие месяцы. Его подготовили Core Maintainers вместе с мейнтейнерами сообщества и участниками Working Groups — не кабинетный план, а результат довольно живого обсуждения.

Открыть дорожную карту →

Оглядываясь назад

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

Большая часть изменений вошла в спецификацию от 28 июля 2026 года. Какие-то нововведения уже могли попасться вам в SDK или документации; другие меняют устройство протокола куда основательнее.

Одно из ключевых решений — отказ от сессий на уровне протокола и от инициализационного рукопожатия. Благодаря этому серверы можно горизонтально масштабировать без сохранения состояния (SEP-2575, SEP-2567). Теперь клиент способен вызвать server/discover и ещё до начала работы узнать версии и возможности сервера. Для операций получения списков также разрешено кэширование результатов (SEP-2549).

В части коммуникации агентов Tasks переработали с учётом ранней обратной связи и вынесли в официальное расширение (SEP-2663). Паттерн Multi Round-Trip Requests (SEP-2322) пришёл на смену запросам, инициируемым сервером. Поэтому elicitation и похожие сценарии могут работать с серверами без состояния — без лишней магии и привязки к сессии.

Working Group Server Card продолжает готовить соглашения о метаданных .well-known для MCP-серверов. Идея проста: сервер можно обнаружить и оценить ещё до подключения к нему. На стороне компании это всё равно чья-то работа: кто-то должен подключить внутренние источники через MCP-серверы и поддерживать их в рабочем состоянии.

Менялась и модель управления. Формально принят Contributor Ladder; Working Groups получили роль первичного рецензента SEP в своей предметной области. У спецификации появились полноценные правила жизненного цикла и устаревания функций, которые впервые применили в версии 2026-07-28.

В прошлом релизном цикле корпоративная готовность в основном означала безопасность. Отсюда и фокус на авторизации: проверка issuer, client credentials, привязанные к issuer, Client ID Metadata Documents (CIMD) как предпочтительный механизм регистрации клиентов, а также развитие Enterprise-Managed Authorization. Это расширение уже получило стабильный статус.

Темп, прямо скажем, немалый. Обновлённая дорожная карта не начинает всё заново — она развивает уже собранный фундамент.

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

Новая версия дорожной карты строится вокруг пяти направлений. Часть из них раньше считалась перспективной: серверные события, улучшение типов результатов, идентификация агентов. Теперь эти темы созрели для отдельного фокуса. За каждой закреплены Core Maintainers и одна или несколько Working Groups.

Примитивы агентного обмена сообщениями

Нынешние агентные сценарии давно не сводятся к привычному «запрос — ответ». Цикл может идти долго, серверу бывает нужно передавать потоковый результат, а пользователю или другому агенту — скорректировать выполнение на ходу. MCP отвечает на это развитием Tasks, subscriptions/listen и уведомлений о прогрессе.

Важно не просто добавить новые механизмы, а сделать так, чтобы они не спорили друг с другом. Работа включает серверные события — вебхуки и каналы, избавляющие клиента от постоянного опроса сервера, — проверку совместимости решений в группах Agents, Transports и Triggers & Events. Параллельно будет развиваться Tasks (SEP-2663), чтобы расширение со временем вошло в основную спецификацию.

Для компаний это уже вполне прикладная история: надёжная разработка AI-агентов и автоматизация процессов требуют предсказуемого обмена статусами, событиями и результатами между системами.

Унификация и усиление HTTP-нативного транспорта

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

Этот подход показал, что умеет масштабироваться. Следующий шаг — распространить его на другие варианты развёртывания, включая локальные серверы, где Streamable HTTP будет использоваться вместо stdio. Единый транспорт упростит создание MCP-клиентов и серверов, а также сделает архитектуру AI-агентов понятнее для эксплуатации, интеграции и масштабирования.

Идентификация агентов и безопасность корпоративного уровня

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

MCP-серверам нужен стандартный способ распознавать такие учётные данные и доверять им. Не набор API-ключей, вставленных куда придётся, и не вечные токены, которые потом никто не помнит, где лежат. Основа должна опираться на существующие стандарты.

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

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

Улучшенные примитивы

Вызов инструментов — обычно первое, с чем разработчик сталкивается в MCP, и этот механизм уже доказал свою полезность. Однако результаты вызова пока устроены не идеально. Ответ tools/call способен передавать один и тот же вывод сразу в нескольких представлениях, а сервер не знает, какое из них конкретный клиент отдаст модели. План — заменить эту неоднозначность единым и ясным контрактом.

Есть и вопрос масштаба. Если сервер предлагает сотню инструментов, модель вынуждена учитывать весь этот каталог ещё до первого вопроса пользователя. А качество выбора, как нетрудно догадаться, обычно падает по мере разрастания списка. MCP начинает работу над прогрессивным обнаружением: сервер сможет показать небольшой стартовый набор, а затем раскрывать дополнительные возможности, когда контекст диалога сузится.

Улучшенный опыт разработчика при работе с SDK

SDK — главный рабочий слой между разработчиком и MCP. Команда вкладывается в удобство библиотек, их соответствие спецификации, понятность API и качество документации на поддерживаемых языках и платформах.

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

Приоритизация предложений

Specification Enhancement Proposals (SEP), связанные с обозначенными приоритетами, будут рассматриваться быстрее и имеют лучшие шансы на принятие. Это не означает автоматический отказ от остальных идей. Просто ресурс мейнтейнеров на ревью ограничен, и сначала он будет направляться туда, где польза для дорожной карты наиболее очевидна.

Авторам будущих SEP стоит определить подходящее приоритетное направление, обсудить инициативу с соответствующей Working Group и вместе с её участниками доработать текст. В разделах дорожной карты указаны ответственные Core Maintainers; связаться с ними можно через Discord. Сообщество готово обсуждать и развивать предложения, которые двигают MCP вперёд.

Присоединяйтесь

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

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

MCP будет развиваться быстрее и разумнее, если делать это вместе. Команда именно на это и рассчитывает.

А если MCP нужен не как эксперимент, а как рабочий контур внутри компании, мы берём на себя внедрение ИИ и агентных интеграций в существующие системы — от подключения источников до эксплуатации.