Новая дорожная карта MCP: что она меняет для тех, кто строит на протоколе

22 августа сопровождающие Model Context Protocol опубликовали обновлённую дорожную карту на период от шести до двенадцати месяцев развития протокола. В ней названы пять приоритетных направлений, основные сопровождающие, отвечающие за каждое из них, и одно неброское, но важное правило о том, какие предложения будут рассматриваться первыми. Предыдущая дорожная карта, мартовская, обещала четыре вещи и в основном выполнила их в июльском релизе спецификации. Поэтому эту уже есть основания воспринимать серьёзно. Мой вывод: MCP намеренно превращается в обычную веб-инфраструктуру. Практический вопрос для разработчиков в том, какую часть вашего стека это изменит первой.

Ключевые выводы - Дорожная карта задаёт пять приоритетов: агентные механизмы обмена сообщениями, единый транспорт, ориентированный на HTTP, идентичность агентов и корпоративная безопасность, более чистые примитивы инструментов и SDK, генерируемые из спецификации. - Предложения по улучшению спецификации (SEP), попадающие в эти направления, получают ускоренное рассмотрение. За их пределами стоит ожидать более длинной очереди и более высокого порога. - Обещания мартовской дорожной карты в основном попали в спецификацию 2026-07-28: ядро без состояния, кэшируемые результаты списков и многораундовые запросы. - Два изменения, которые с наибольшей вероятностью затронут ваш код, это идентичность агентов (DPoP и федерация идентичностей рабочих нагрузок) и прогрессивное обнаружение инструментов для больших каталогов. - Воспринимайте дорожную карту как направление, а не обязательство. Сопровождающие сами это подчёркивают. Не ставьте разработку на паузу в ожидании этих пунктов.

Что именно объявили сопровождающие MCP?

Сначала факты. Обновлённая дорожная карта MCP от 22 августа 2026 года организует следующий цикл спецификации вокруг пяти приоритетных направлений. За каждым закреплены конкретные основные сопровождающие и одна или несколько рабочих групп:

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

2. Унификация и усиление транспорта, ориентированного на HTTP: Streamable HTTP как единая транспортная привязка, в перспективе работающая поверх stdio для локальных серверов, и расширение кэширования до ETags.

3. Идентичность агентов и безопасность, готовая к корпоративному использованию: завершение DPoP (доказательство владения) и определение рекомендуемого пути для идентичности и делегирования агентов на базе существующих стандартов IETF.

4. Улучшенные примитивы: переработка формы результата tools/call и новое направление прогрессивного обнаружения, чтобы клиент узнавал каталог сервера по мере необходимости.

5. Улучшение опыта разработчиков SDK: контракт расширений и эксперимент по генерации SDK уровня 1 и его краткое руководство прямо из спецификации.

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

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

Почему эта дорожная карта вообще важна?

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

Вес дорожной карте придаёт масштаб использования. К июлю 2026 года SDK уровня 1 протокола набирали почти полмиллиарда скачиваний в месяц, а TypeScript- и Python-SDK каждый преодолел миллиард суммарных скачиваний. Когда протокол такого масштаба говорит, куда идёт дальше, карту стоит прочитать.

Источник: дорожные карты MCP за март и август 2026 года и анонс спецификации 2026-07-28.

Мартовская дорожная карта MCP за 2026 год обещала развитие транспорта, взаимодействие агентов, созревание управления и готовность к корпоративному использованию. Пять месяцев спустя спецификация 2026-07-28 принесла ядро без состояния протокола, расширение Tasks, многораундовые запросы и формальную политику устаревания с минимальным окном в двенадцать месяцев.

Что это значит, если вы строите на MCP?

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

Агентный обмен сообщениями: конец постоянного опроса

Настоящая агентная работа плохо помещается в схему «запрос и ответ». Задачи идут минуты, серверы заканчивают работу, пока клиент занят чем-то другим, а сегодня клиенту остаётся только опрашивать сервер, что дорого и некрасиво. Дорожная карта ставит в приоритет события, инициируемые сервером: каналы, подписки и вебхуки, чтобы сервер сам мог сказать клиенту, когда работа закончена. Ревизия композиции не менее важна. Сейчас Tasks, subscriptions/listen и уведомления о прогрессе рискуют стать тремя разными ответами на вопрос «сервер ещё не закончил», а сопровождающие хотят общий жизненный цикл, единую модель отмены и одну поверхность ошибок. Если вы строите долго работающие инструменты, именно за этим направлением стоит следить в Discord.

Один транспорт для любых сред

Релиз 2026-07-28 превратил удалённый MCP-сервер в обычную HTTP-нагрузку. Теперь дорожная карта хочет стереть границу между удалённым и локальным: Streamable HTTP как единая транспортная привязка, которая для локальных серверов работает через stdin и stdout, с HTTP/2 для мультиплексирования, при этом подпроцесс сохраняет свои гарантии безопасности и жизненного цикла. Сегодня каждой функции, ориентированной на HTTP, нужен второй, отдельный вариант для stdio, иначе локально она не работает, а SDK поддерживают два транспортных конвейера. Единая модель транспорта уменьшает эту двойную работу. Кэширование тоже расширится: к подсказкам ttlMs и cacheScope, появившимся в июле, добавятся ETags, чтобы результаты вызовов инструментов можно было версионировать, а не загружать заново.

Идентичность агентов: это заденет раньше всего

Модель авторизации MCP предполагает человека с браузером в момент согласия. Но вызывающей стороной всё чаще становится агент: облачная рабочая нагрузка со своей идентичностью, действующая от имени отсутствующего пользователя, или агент, который порождает субагентов и должен выдавать им более узкие полномочия, чем имеет сам. Honeycomb, как цитируется в июльском анонсе релиза, уже относит почти 20% ежемесячных интерактивных запросов к агентам. При этом множество MCP-серверов в продакшене всё ещё полагается на вставленные вручную API-ключи и долгоживущие токены обновления. Именно от такой практики эта работа и должна уйти. План включает завершение и внедрение DPoP, плюс стандартный путь делегирования через федерацию идентичностей рабочих нагрузок (SEP-1933), механизм выдачи ID-JAG, лежащий в основе корпоративно управляемой авторизации, и обмен токенами по RFC 8693 в координации с рабочими группами IETF OAuth и WIMSE.

Модель авторизации MCP создавалась для человека, который подтверждает доступ в браузере, но вызывающей стороной всё чаще становится агент. Дорожная карта ставит в приоритет DPoP и стандартный путь делегирования на базе федерации идентичностей рабочих нагрузок и обмена токенами RFC 8693, чтобы серверы могли распознавать идентичности агентов без вставленных API-ключей и долгоживущих токенов.

Результаты инструментов и прогрессивное обнаружение

Здесь исправляют две разные путаницы. Первая связана с тем, что tools/call одновременно возвращает content и structuredContent. Из-за этого реализации расходятся, потому что автор сервера не может знать, какую форму клиент покажет модели. Этот контракт переработают. Вторая проблема касается масштаба. Подключите сервер со ста инструментами, и модель расходует контекст на всю поверхность ещё до того, как пользователь задал первый вопрос. По мере роста списка ухудшается и выбор инструмента. Счёт в токенах вполне реальный. В тесте Cloudflare за февраль 2026 года представление API из 2 500 конечных точек в виде определений MCP-инструментов потребовало около 1,17 млн токенов, тогда как через вызовы кода понадобилось около 1 000. Предлагаемый ответ называется прогрессивным обнаружением: небольшая точка входа показывает больше каталога по мере того, как разговор сужается, и связывается с описанной выше работой по кэшированию. Я уже писал о том, когда такой накладной расход делает обычный API лучшим выбором. Прогрессивное обнаружение это попытка MCP сократить разрыв.

SDK, генерируемые из спецификации

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

Что делать сейчас?

Четыре действия, в порядке срочности:

1. На этой неделе: не начинайте новую работу на устаревающих поверхностях. Roots, Sampling, Logging и старый транспорт HTTP+SSE были объявлены устаревающими в спецификации 2026-07-28 с минимальным окном в двенадцать месяцев. Они всё ещё работают. Новые реализации не должны на них опираться.

2. В этом месяце: сделайте сервер дружелюбным к кэшу. Результаты списков уже несут ttlMs и cacheScope, а ETags скоро появятся. Сервер, который сегодня отдаёт разумные подсказки для кэширования, уже на одну миграцию впереди.

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

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

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

Спецификация MCP 2026-07-28 объявила устаревающими Roots, Sampling, Logging и старый транспорт HTTP+SSE с минимальным окном в двенадцать месяцев. Анонс релиза подтверждает, что в этот период они продолжат работать, но новым реализациям не стоит их использовать.

Общая картина

Если отойти на шаг, виден протокол, который взрослеет на публике. В декабре 2025 года MCP был передан в нейтральный к поставщикам Agentic AI Foundation под Linux Foundation, а OpenAI и Block стали соучредителями. С тех пор появились лестница контрибьюторов, жизненный цикл функций, политика устаревания, а теперь и публичное заявление о том, куда сопровождающие тратят внимание. Фреймворк расширений тоже делает тихую, но настоящую работу: SEP-2133 позволяет любой рабочей группе экспериментировать в репозитории experimental-ext- ещё до формального предложения, чтобы идеи проходили проверку без риска для ядра.

В ближайшие два квартала я бы следил за тем, появится ли HTTP поверх stdio. Если локальные и удалённые серверы действительно сойдутся на одном транспорте, «MCP-сервер» перестанет быть особым видом программного обеспечения и станет обычным веб-сервисом со стандартным интерфейсом. В этот момент протокол растворится в инфраструктуре, а хорошая инфраструктура именно так и должна работать.

Частые вопросы

MCP уже достаточно стабилен, чтобы на нём строить?

Да, если соблюдать миграционную дисциплину. Спецификация 2026-07-28 ввела формальную политику устаревания с минимальным окном в двенадцать месяцев, а SDK поставляются с заметками по миграции для ломающих изменений. Протокол продолжит развиваться, но теперь он предупреждает за год, когда исчезнет то, от чего вы зависите.

Что произошло с сессиями MCP?

Их убрали в спецификации 2026-07-28. Рукопожатие initialize и заголовок Mcp-Session-Id исчезли (SEP-2575, SEP-2567). Теперь каждый запрос самодостаточен: он несёт версию протокола и возможности клиента в _meta, а опциональный вызов server/discover заменяет рукопожатие для клиентов, которым нужно заранее узнать возможности. Любой запрос может попасть на любой экземпляр за балансировщиком с циклическим распределением.

Стоит ли ждать следующую спецификацию перед началом разработки?

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