У серпні 2026 року робоча група Model Context Protocol опублікувала вже другий за рік оновлений roadmap протоколу — документ, який для відкритого стандарту виконує не роль product-плану окремої компанії, а роль сигналу пріоритетів для десятків Working Groups, авторів SDK і незалежних контриб'юторів. За даними HackerNews, документ визначає п'ять напрямків роботи на наступні релізи специфікації, і щонайменше три з них ще торік значилися в розділі «на горизонті», а тепер стали пріоритетом номер один.

Питання, яке варто поставити собі, якщо MCP-сервер уже стоїть у продакшн-агенті: хто насправді викликає ваш tools/call, коли за клавіатурою немає людини? Сьогоднішня авторизація MCP побудована навколо людини, що тисне «Дозволити» у браузері. Але дедалі частіше цей виклик робить хмарний воркload, що діє за розкладом, без користувача в кімнаті, — і саме цю прогалину закриває новий roadmap.

Менш ніж за два роки MCP пройшов шлях від внутрішньої специфікації Anthropic, опублікованої в листопаді 2024-го, до протоколу, який де-факто підтримують OpenAI у власних агентних SDK і Google DeepMind у Gemini, а десятки хмарних платформ продають «підключи будь-який інструмент до будь-якого агента» як окрему фічу. Коли стандарт росте так швидко, розрив між тим, що дозволяє специфікація, і тим, що потрібно виробничим системам, росте разом з ним.

П'ять пріоритетних напрямків нового roadmap — агентні message-примітиви, уніфікація транспорту, ідентичність агента й enterprise-безпека, покращені примітиви виклику інструментів і розвиток SDK — це не випадковий список feature request. Це майже точна мапа больових точок, які проступають, коли MCP-сервер переїжджає з ноутбука розробника у прод. Розберемо кожен по черзі.

Звідки взявся цей roadmap і чому саме зараз?

MCP давно перестав бути одноосібним проєктом Anthropic: зміни в специфікацію проходять через Specification Enhancement Proposals (SEP) — процес, що концептуально нагадує те, як TC39 просуває пропозиції для JavaScript або IETF веде RFC через стадії драфтів. У такій моделі roadmap — це не обіцянка конкретних дат релізу, а фільтр пріоритетів: SEP, що потрапляє в одну з п'яти названих зон, отримує прискорений розгляд Core Maintainers, а все інше чекає в черзі за увагою волонтерів-мейнтейнерів, якої завжди бракує.

Показово, що три з п'яти напрямків — server-initiated events, покращення типів результату виклику інструмента й ідентичність агента — ще в попередньому roadmap, опублікованому раніше цього року, значилися лише як спостережувані теми «на горизонті». Те, що вони «дозріли» до статусу пріоритету, означає конкретну річ: набралося достатньо продакшн-скарг, робочі групи дійшли консенсусу, а по частині напрямків уже є оформлений SEP — наприклад, розширення Tasks має номер SEP-2663. Тобто roadmap описує не ідеї, а роботу, під яку вже є драфт і люди, готові її рецензувати.

Другий контекстний факт: цей roadmap безпосередньо спирається на реліз специфікації від 28 липня 2026 року, який уже переформатував історію транспорту MCP. Без цього релізу пункт про уніфікацію транспорту просто не мав би бази, від якої відштовхуватися.

Як саме змінюється протокол під капотом?

Довгі задачі без нескінченного polling

MCP уже має будівельні блоки для роботи, що не вкладається у класичний запит-відповідь: розширення Tasks, метод subscriptions/listen і progress-нотифікації. Проблема в тому, що сервер досі не може проактивно штовхнути результат клієнту без того, щоб клієнт тримав з'єднання відкритим або періодично опитував стан. Roadmap закриває цю прогалину через server-initiated events — вебхуки й канали, — а також через спільний перегляд композиції цих примітивів робочими групами Agents, Transports і Triggers & Events, щоб механізми не жили окремими життями, а працювали разом. Паралельно триває дозрівання самого розширення Tasks (SEP-2663) до статусу частини основної специфікації.

Для практики це означає різницю між агентом, що раз на кілька секунд запитує «ти вже готовий?» протягом двадцятихвилинного batch-завдання, і агентом, який просто чекає на подію. Перший варіант з'їдає квоту запитів і додає латентність-податок на кожен цикл; другий перетворює MCP-сервер на щось ближче до event bus, ніж до звичайного RPC.

Один транспорт замість трьох

Реліз специфікації від 28 липня 2026 року вже зробив віддалений MCP-сервер практично невідмінним від будь-якого іншого HTTP-сервісу: Streamable HTTP-транспорт замінив стару схему з окремим SSE-з'єднанням. Новий roadmap хоче розтягнути той самий підхід на локальні сервери, які сьогодні спілкуються через stdio (пайпи процесів), щоб вони теж могли говорити Streamable HTTP. Кінцева мета — один транспортний код у SDK замість трьох (стара HTTP+SSE-схема, новий Streamable HTTP і stdio).

Тут є нетривіальний трейдоф: локальний процес і віддалений HTTP-виклик мають різні межі довіри. stdio неявно довіряє «я на тій самій машині», HTTP такого припущення не робить. Тому в roadmap уніфікація йде в парі зі словом «hardening» — це не лише про зручність розробника, а й про закриття дірок, які виникають саме через це неявне довіра-за-замовчуванням локального транспорту.

Хто насправді натискає кнопку

Авторизація MCP сьогодні побудована навколо людини, що підтверджує доступ у браузері через OAuth. Це добре працює для інтерактивних клієнтів, але дедалі більше викликів приходить від агентів, що виконуються як хмарні воркloади з власною ідентичністю, діють від імені відсутнього користувача або делегують вужчі повноваження суб-агентам. Roadmap описує стандартизований спосіб для MCP-серверів розпізнавати й довіряти такій агентній ідентичності — на основі вже існуючих стандартів, а не наклеєних API-ключів і довгоживучих токенів.

Конкретно йдеться про фіналізацію Demonstrating Proof of Possession (DPoP, RFC 9449) і просування її прийняття — механізму, що криптографічно прив'язує токен доступу до клієнта, який його запросив, тож викрадений bearer-токен сам по собі більше не дозволяє відтворити виклик. Паралельно roadmap визначає шлях для делегування ідентичності через Workload Identity Federation, ID-JAG grant, що стоїть за розширенням Enterprise-Managed Authorization, і стандартний token exchange. Команда також обіцяє продовжити взаємодію з органами стандартизації OAuth, включно з IETF OAuth і робочою групою WIMSE (Workload Identity in Multi System Environments), щоб базові стандарти розвивалися разом з потребами агентної ідентичності, а не окремо від них.

Коли інструментів забагато для контексту

Виклик інструмента, tools/call, — та частина MCP, з якою розробники стикаються найперше, і вона загалом непогано витримала перевірку часом. Слабке місце — обробка результату: відповідь може нести той самий вивід у більш ніж одній формі, і автор сервера сьогодні не знає, яку саме форму конкретний клієнт покаже моделі. Roadmap хоче стандартизувати це до одного чіткого контракту замість здогадок.

Друга проблема — масштаб. Підключення до сервера із сотнею інструментів означає, що модель платить контекстом за весь цей каталог ще до того, як користувач поставив перше запитання, а точність вибору потрібного інструмента статистично падає з ростом списку. Roadmap описує запуск роботи над progressive discovery: сервер пропонує невелику точку входу й розкриває глибші шари каталогу в міру того, як звужується тема розмови, замість того щоб одразу вивалювати весь список.

Чим цей курс відрізняється від того, що роблять OpenAI, Google чи Zapier?

Показовий факт: навіть OpenAI, який має власну екосистему Apps SDK і Actions, підтримує MCP-клієнт у своїх агентних SDK. Для прямого конкурента виявилося дешевше говорити спільним протоколом, ніж виграти окрему війну стандартів.

Google рухається паралельним шляхом: протокол Agent2Agent (A2A), переданий у Linux Foundation, вирішує зовсім іншу задачу — передачу роботи й делегування між агентами, а не підключення агента до інструмента. Це суміжний, а не конкурентний шар: Gemini одночасно говорить MCP для доступу до інструментів і A2A для координації з іншими агентами, тобто Google тримає обидва рівні замість того, щоб обирати один.

Комерційні агрегатори інструментів — Zapier AI Actions, Composio та подібні MCP-шлюзи — вже сьогодні продають курований, шуканий каталог інструментів як платну фічу. У цьому світлі робота над progressive discovery в MCP — це, по суті, стандартизація в відкритому протоколі того, що проприєтарні гейтвеї вже монетизували ad hoc. Це типовий цикл розвитку відкритих стандартів: комерційний гравець першим знаходить больову точку й закриває її власним рішенням, а відкритий стандарт наздоганяє місяцями пізніше, але в портативній формі, що не прив'язує до одного вендора.

Напрямок з DPoP і Workload Identity Federation теж не винайдений з нуля — він дзеркалить SPIFFE/SPIFFE-ID та шаблони workload identity, які вже роками працюють у хмарній інфраструктурі: Kubernetes, Istio, IAM-ролі AWS чи workload identity GCP. Замість вигадувати нову схему машинної ідентичності MCP підключається до стандартів, які вже витримали enterprise-навантаження, і це знижує поріг довіри для служб безпеки, які вирішують, чи пускати MCP-сервер до прод-систем.

Що це дає тим, хто будує на MCP просто зараз?

Перший сценарій — внутрішня devops- чи data-платформа з великим MCP-сервером на сотню з гаком інструментів. Сьогодні така конфігурація і роздуває контекст, і псує точність вибору інструмента моделлю. Напрямок progressive discovery прямо адресує цю біль: має сенс уже зараз структурувати каталог інструментів за категоріями чи фасетами, щоб бути готовим підключити механізм точки входу, коли він з'явиться в специфікації.

Другий сценарій — автономний агент, що діє в хмарі без людини в петлі: наприклад, агент моніторингу чи деплойменту, який за розкладом торкається прод-систем. Сьогодні такий агент або імітує людський OAuth-потік, або тримає довгоживучий API-ключ, вписаний просто в конфіг, — класичний антипатерн. Напрямок агентної ідентичності дає шлях до короткоживучих, криптографічно прив'язаних до клієнта токенів через DPoP і Workload Identity Federation — прив'язаних до ідентичності воркloаду, а не до сесії людини в браузері.

Третій сценарій — довгі асинхронні пайплайни: обробка відео, підготовка датасету, CI/CD-запуск. Сьогодні агент, що чекає завершення такого завдання, змушений тримати polling-цикл, який спалює токени й запити. Розширення Tasks разом із server-initiated подіями означає, що агент запускає завдання й отримує подію завершення, а не сам її вимолює.

Окремо варто відзначити напрямок покращення SDK: команда MCP прямо називає причину інвестиції — усе більше розробників пишуть MCP-сервери й клієнти, спрямовуючи агента прямо на бібліотеку та її документацію, а не читаючи docs самостійно. У такій моделі якість і повнота документації SDK напряму визначає, чи згенерований агентом код взагалі запрацює з першого разу, — це прямий аргумент на користь того, щоб автори тулінгу тримали conformance-тести й приклади в актуальному стані.

Чого тут бракує і що може піти не так?

Roadmap — це сигнал пріоритету, а не поставлений код. SEP-процес свідомо повільний: потрібен розгляд спільнотою, драфт робочої групи, консенсус вендорів SDK. Те, що три пункти пройшли шлях від «на горизонті» до пріоритету за один цикл роадмапу, — це наочний доказ, що зміни тут рухаються темпом комітету стандартів, а не темпом стартапу; будівельникам, які чекають на progressive discovery чи фіналізований контракт результату вже в наступному релізі, варто закладатися на кілька циклів, а не на один.

Стек ідентичності — DPoP, token exchange, Workload Identity Federation, ID-JAG — це багато рухомих стандартів, які треба реалізувати правильно одночасно. Часткова або неправильна реалізація одним з авторів SDK може створити хибне відчуття безпеки: сервер заявляє підтримку sender-constrained токенів, але фактично не перевіряє прив'язку на своєму боці. Це типова категорія вразливостей для будь-якої молодої auth-екосистеми, і саме тому варто перевіряти реалізацію, а не довіряти маркетинговому «підтримує DPoP» на слово.

Уніфікація транспорту вимагає перехідного періоду з подвійною підтримкою: старі клієнти на HTTP+SSE чи чистому stdio нікуди не зникнуть одразу, тож автори серверів деякий час муситимуть підтримувати кілька транспортів одночасно — тобто короткостроково складність коду не падає, а росте.

Progressive discovery поки що на стадії «ми починаємо роботу над цим», без зафіксованого механізму. Це залишає вікно, в якому MCP-шлюзи та проприєтарні агрегатори типу Composio можуть закріпити власні, несумісні між собою рішення ще до того, як стандарт приземлиться, — повторюючи ранню фрагментацію stdio проти HTTP+SSE, яку екосистема лише зараз закінчує прибирати.

Поширені запитання про новий roadmap MCP

Коли ці зміни з'являться в специфікації MCP?

Roadmap не фіксує дати релізів — він фіксує пріоритет розгляду. Найдалі просунулося розширення Tasks (SEP-2663), тож логічно очікувати його дозрівання в основну специфікацію першим; решта напрямків, особливо ідентичність агента через залежність від зовнішніх органів стандартизації (IETF OAuth, WIMSE), розтягнуться на кілька релізних циклів.

Чи потрібно вже зараз щось міняти у своєму MCP-сервері?

Термінового breaking change немає. Але якщо ваш сервер віддає користувачам понад п'ятдесят інструментів або обслуговує автономних хмарних агентів без людини в петлі, вже зараз варто стежити за робочими групами з agent identity й progressive discovery — і, за можливості, брати участь у обговоренні відповідних SEP, поки контракт ще формується.

Висновок AiiN

Цей roadmap — це фактично визнання MCP-командою, що протокол перестав бути іграшкою для демо і став інфраструктурою, на якій компанії будують реальні продакшн-системи. Усі п'ять напрямків — про проблеми, які проявляються не в прототипі на ноутбуці, а тільки після того, як MCP-сервер тижнями працює під живим навантаженням: чужа ідентичність, транспортні дірки, роздутий контекст, неоднозначний контракт результату.

Прогноз AiiN на найближчі 6–12 місяців: розширення Tasks, як найбільш просунуте технічно й формально (уже з номером SEP), із найбільшою ймовірністю ввійде в основну специфікацію першим. Уніфікація транспорту, найімовірніше, приземлиться як опційний шлях із тривалим періодом паралельної підтримки старих транспортів — повної заміни stdio за рік не буде. Напрямок ідентичності агента рухатиметься найповільніше з усіх п'яти: він залежить від координації з IETF OAuth і WIMSE, а міжорганізаційна стандартизація типово займає більше року. А ось progressive discovery, попри те що формально це наймолодший з п'яти напрямків, має шанс отримати перші експериментальні розширення (за схемою SEP-2133) вже протягом кількох місяців — біль від роздутого контексту відчувають просто зараз усі, хто підключив великий каталог інструментів, і тиск спільноти тут буде найсильнішим.

Практична порада тим, хто зараз будує на MCP: якщо у вас автономний агент без людини в петлі, вже сьогодні варто звірити свою схему авторизації з напрямком agent identity — довгоживучий API-ключ у конфігу через рік виглядатиме так само застаріло, як пароль у відкритому тексті виглядає сьогодні. А якщо ваш каталог інструментів переріс два десятки записів, почніть групувати їх логічно вже зараз — коли progressive discovery приземлиться в специфікації, структурований каталог адаптується за дні, а не за тижні.

Roadmap відкритого протоколу — це не обіцянка дат, а мапа того, куди піде увага мейнтейнерів. Для тих, хто будує на MCP, це найдешевший спосіб дізнатися завтрашні вимоги enterprise-безпеки й масштабу сьогодні.