Разработчики Model Context Protocol (MCP) опубликовали обновленную дорожную карту, которая определит следующую версию спецификации протокола, который стал де-факто стандартом для подключения моделей ИИ к внешним инструментам и данным. Сообщение от 22 августа, авторами которого являются ведущие специалисты по сопровождению Дэвид Сориа Парра и Ден Делимарски, излагает пять приоритетных областей — от примитивов агентского обмена сообщениями до стандартизированной идентификации агента — и появилось всего через несколько недель после знакового пересмотра спецификации протокола 28 июля 2026 г.

Обновление сразу привлекло внимание сообщества разработчиков: за несколько дней объявление о дорожной карте собрало более 240 голосов «за» и более 140 комментариев на Hacker News. Для разработчиков, создающих агентные приложения, документ указывает, где основные специалисты по сопровождению протокола и рабочие группы будут проводить время на рассмотрение — и какие предложения будут быстрее всего продвигаться в очереди. Подробнее об этой истории — в нашем последние разработки в ИИ.

Что уже изменилось в июльской спецификации

Прежде чем установить новые приоритеты, специалисты по обслуживанию подвели итоги предыдущей дорожной карты, опубликованной в марте 2026 года, которая фокусировалась на четырех областях: эволюция и масштабируемость транспорта, связь между агентами, совершенствование управления и готовность предприятия. Согласно сообщению в блоге, «значительный прогресс» был достигнут по всем четырем направлениям, при этом основная часть изменений вошла в выпуск спецификации 28 июля 2026 г.

Наиболее значимым изменением стало удаление сеансов на уровне протокола и рукопожатия инициализации, отслеживаемого как SEP-2575 и SEP-2567. Этот сдвиг означает, что сервер MCP теперь может масштабироваться горизонтально без сохранения состояния — фундаментальная переработка, которая заставляет удаленные серверы MCP вести себя как обычные веб-сервисы. Клиенты также могут вызывать новую конечную точку «server/discover», чтобы узнать поддерживаемые версии и возможности сервера, прежде чем делать что-либо еще, а результаты списка стали кэшироваться в соответствии с SEP-2549.

Что касается связи агентов, конструкция Tasks была переработана в официальное расширение (SEP-2663), а новый шаблон Multi Round-Trip Requests (SEP-2322) заменил запросы, инициируемые сервером, так что потоки, подобные выявлению, работают на серверах без отслеживания состояния. Управление также стало более зрелым: в проекте официально принята лестница участников, рабочие группы теперь рассматривают свои собственные предложения по усовершенствованию, а спецификация получила надлежащий жизненный цикл функций и политику устаревания.

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

Пять приоритетов для следующего цикла релизов

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

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

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

2. Унификация HTTP-Native Transport

Разработчики написали, что с июльским выпуском «удаленный сервер MCP теперь ничем не отличается от любой другой рабочей нагрузки HTTP», что позволяет легко размещать серверы MCP в инфраструктуре, которую организации уже используют для своих API. Этот подход «доказал свою масштабируемость», и теперь в дорожной карте предлагается распространить его на локальные серверы, использующие Streamable HTTP вместо стандартного ввода и вывода. В сообщении утверждается, что унификация на едином транспорте еще больше упростит разработку как сервера MCP, так и клиента.

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

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

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

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

4. Улучшенные примитивы и прогрессивное обнаружение инструментов

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

Специалисты по сопровождению также отметили проблему масштаба. «Подключение к серверу с сотней инструментов означает, что модель платит за всю эту поверхность до того, как пользователь задаст хотя бы один вопрос, а выбор инструментов имеет тенденцию ухудшаться по мере роста списка», — пишут они. Ответ — постепенное открытие, позволяющее серверу предлагать небольшую точку входа и раскрывать больше своего каталога по мере сужения разговора.

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

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

Что это значит для экосистемы

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

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

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

---

Будьте в курсе ИИ

Последние новости, аналитика и прорывы в сфере ИИ — всё в одном месте.

Читать больше новостей об ИИ →