У світі агентних систем і чат-інтерфейсів зараз відбувається одна з найцікавіших інфраструктурних змін: користувацькі інтерфейси перестають бути «чужими» для чатів і стають частиною єдиного протоколу. Про те, як саме це працює, розповідають творці MCPUI та співрозробники специфікації MCP Apps Ідо Саломон та Ліад Йосеф у виступі на каналі AI Engineer. Вони показують, як MCP Apps перетворює інструменти на повноцінні застосунки всередині ChatGPT, Claude, VS Code, Cursor, Copilot та інших хостів — і чому цей протокол претендує на роль глобального стандарту UI в чат-додатках до 2026 року.
Стандартизований діалог між UI та хостом: що саме робить MCP Apps
Ключова ідея MCP Apps — не лише «передати HTML у чат», а формалізувати повний двосторонній діалог між інтерфейсом і хостом (чатом або агент-хостом). Раніше MCP‑інструменти повертали текст, який модель показувала користувачу. Тепер замість тексту інструмент може повернути UI‑ресурс, наприклад HTML, який хост рендерить як інтерактивний застосунок.
Це змінює не тільки вигляд відповіді, а й саму архітектуру взаємодії. MCP Apps визначає, як кожен «шматок» UI (view, chunk, widget) спілкується з хостом: які події він може надсилати, як хост має їх інтерпретувати, і як усе це залишається в одному контексті діалогу.
У традиційній веб-моделі UI часто напряму говорить із бекендом сервісу. У світі MCP Apps це вважається «антипатерном». Коли користувач натискає кнопку в UI, подія не йде безпосередньо до бекенду Shopify, PostHog чи Spotify. Натомість MCP Apps вимагає, щоб кожна взаємодія поверталася до хоста як стандартизоване повідомлення. Хост уже вирішує, що робити: викликати MCP‑інструмент, зробити додатковий запит, згенерувати уточнювальний промпт чи оновити інший фрагмент UI.
Таким чином MCP Apps:
- зберігає повний контекст дій користувача в межах одного діалогу;
- дає хосту контроль над тим, які інструменти викликаються і як;
- дозволяє моделі «розуміти» наслідки кліків і подій у UI, а не втрачати їх за межами свого середовища.
Це не просто технічна деталь, а зміна філософії: сервіси більше не «володіють» користувацькою подорожжю. Вони постачають атомарні можливості й інтерфейси, але саме хост і агент організовують з них цілісний сценарій.
Спектр повідомлень: від нотифікацій до промптів і викликів інструментів
Щоб така модель працювала, протокол має чітко визначати, які саме типи повідомлень можуть передаватися між UI та хостом. MCP Apps описує це як спектр інтеракцій, де різні типи повідомлень дають різний рівень контролю UI та хосту.
На одному кінці спектра — прості нотифікації. Це можуть бути події на кшталт «користувач відкрив вкладку», «змінив фільтр», «прокрутив донизу». Вони не вимагають негайної відповіді від моделі чи інструменту, але дають хосту сигнал про стан інтерфейсу. Хост може використати їх для аналітики, адаптації підказок або для наступних кроків агента.
Далі йдуть події, які ініціюють виклики інструментів. Наприклад, натискання кнопки «додати в обране» в UI музичного сервісу не викликає бекенд напряму. Згідно зі специфікацією MCP Apps, UI надсилає стандартизоване повідомлення до хоста, яке хост інтерпретує як запит на tool call. Хост вирішує, який саме MCP‑інструмент викликати, з якими параметрами, і як потім оновити UI чи текстовий контекст.
Ще один важливий тип повідомлень — промпти. UI може ініціювати ситуації, коли потрібна додаткова взаємодія з користувачем або моделлю. Наприклад, складний віджет аналітики може «попросити» модель пояснити певний крок користувачу, згенерувати рекомендації або запропонувати наступні дії. У цьому випадку UI не просто надсилає технічну подію, а фактично ініціює новий крок діалогу.
У результаті MCP Apps перетворює UI на повноправного учасника розмови. Інтерфейс не є пасивним відображенням відповіді моделі; він може запускати інструменти, ініціювати промпти, надсилати нотифікації про стан і при цьому залишатися в межах єдиного протоколу, де хост зберігає контроль і видимість усього, що відбувається.
XApps: офіційний SDK і шлях до «генеративних» застосунків без коду
Щоб MCP Apps не залишився лише теоретичною специфікацією, спільно з Anthropic та OpenAI підтримується офіційний репозиторій і SDK під назвою XApps. Це не просто набір утиліт, а референсна реалізація, яка постійно тримається в повній відповідності до специфікації MCP Apps.
XApps виконує одразу кілька ролей.
По-перше, це рекомендований спосіб створення MCP‑застосунків. Розробникам не потрібно вручну реалізовувати всі деталі протоколу, обробку повідомлень, формат ресурсів і подій. SDK інкапсулює ці аспекти, дозволяючи зосередитися на логіці й дизайні інтерфейсу.
По-друге, XApps містить вбудовані «скіли», які дозволяють генерувати MCP‑застосунки з мінімальною кількістю коду або взагалі без нього. Це важливо в контексті агентних систем: моделі можуть самі конструювати або модифікувати UI, спираючись на декларативні описи чи приклади, а не на ручне програмування кожного компонента.
По-третє, XApps виступає як спільний майданчик для еволюції стандарту. Оскільки репозиторій підтримується разом з Anthropic та OpenAI, будь-які зміни в специфікації швидко відображаються в SDK, а зворотний зв’язок від розробників допомагає виявляти прогалини або неоднозначності в протоколі.
У підсумку XApps перетворює MCP Apps із «паперового» стандарту на практичну платформу, де розробники можуть швидко створювати застосунки, а моделі — навчатися працювати з UI як з першим класом об’єктів.
Один протокол для трьох підходів до UI: від фіксованих макетів до повністю генеративних інтерфейсів
Одна з найбільш амбітних цілей MCP Apps — об’єднати в одному протоколі три різні парадигми побудови UI: попередньо визначений, декларативний і повністю генеративний.
Попередньо визначений UI — це класичний підхід, коли компанія створює власні компоненти, макети, стилі й логіку. У контексті MCP Apps це означає, що Shopify, Hugging Face, PostHog чи будь-який інший сервіс можуть надсилати у хост свої «рідні» віджети, які виглядають і працюють так само, як на їхніх сайтах. Вони зберігають бренд, знайомі патерни взаємодії, але тепер живуть усередині чат-інтерфейсу.
Декларативний UI дозволяє описувати інтерфейс на вищому рівні абстракції: не конкретний HTML чи компонент, а структуру, стан і взаємозв’язки. У такій моделі хост або SDK можуть самі обирати, як саме рендерити елементи, адаптуючи їх до платформи, розміру екрана чи особливостей користувача. MCP Apps закладає можливість для такого підходу, не обмежуючись жорстко «сирим» HTML.
Нарешті, повністю генеративний UI — це коли інтерфейс створюється моделлю на льоту. Важливий момент: навіть у цьому випадку MCP Apps залишається базовим транспортом. Anthropic уже використовує цей підхід у своєму режимі generative UI в Claude: згенерований інтерфейс фактично стрімиться в MCP App «під капотом». Для хоста й інструментів це все ще той самий протокол, ті самі повідомлення, той самий цикл подій.
Таким чином MCP Apps не змушує екосистему обирати між «ручним» дизайном і «магією» генеративних моделей. Він створює спільну мову, де всі три підходи можуть співіснувати, комбінуватися й еволюціонувати, не ламаючи базову сумісність.
Повторно використовувані представлення: як не рендерити важкі застосунки щоразу
Коли UI стає по-справжньому інтерактивним і складним, постає питання продуктивності. Якщо кожна взаємодія призводить до повного перерендеру застосунку, це б’є і по швидкодії, і по ресурсах, і по користувацькому досвіду. MCP Apps враховує це й рухається до моделі повторно використовуваних представлень (reusable views).
Ідея полягає в тому, що важкі застосунки — наприклад, складні аналітичні панелі, редактори чи конфігураційні інтерфейси — не повинні щоразу надсилатися й рендеритися з нуля. Натомість хост і UI можуть посилатися на вже створене представлення, оновлювати його стан, змінювати окремі частини, але не відтворювати всю структуру.
Це наближає MCP Apps до моделі, знайомої з сучасних фронтенд-фреймворків, де стан і представлення розділені, а оновлення відбуваються інкрементально. Для агентних систем це критично: моделі можуть часто ініціювати дрібні зміни в UI, і повторне використання представлень зменшує накладні витрати як на мережу, так і на обчислення.
Наступний крок, над яким працює комітет MCP Apps, — дати моделям на кшталт Claude можливість безпосередньо взаємодіяти з елементами UI через інструменти, «експортовані» з представлення. Іншими словами, сам view зможе оголошувати набір доступних дій як MCP‑інструменти. Модель зможе викликати їх, не вгадуючи структуру DOM чи внутрішню логіку компонента.
Це відкриває шлях до сценаріїв, де агент не просто генерує UI, а активно «керує» ним: натискає кнопки, змінює фільтри, перемикає вкладки — але робить це через формалізований набір дій, а не через крихкі евристики.
Інтероперабельність: A2UI, WebMCP, LibreChat і єдиний код для різних хостів
Ще один стратегічний напрям MCP Apps — сумісність з іншими протоколами UI для агентних систем. Специфікація не розвивається у вакуумі: комітет працює над узгодженням MCP Apps з Google A2UI та WebMCP, щоб уникнути фрагментації екосистеми.
Вирівнювання специфікацій означає, що розробники зможуть розраховувати на спільні концепції, схожі моделі повідомлень і передбачувану поведінку UI в різних хостах. Це знижує бар’єр входу й зменшує ризик ситуації, коли кожен великий гравець просуває власний несумісний стандарт.
Практичний ефект цієї стратегії вже видно на прикладі LibreChat. Цей клієнт підтримує MCP Apps і може запускати ті самі MCP‑застосунки, що й ChatGPT, з одного й того ж кодового базису. Для розробників це означає, що інвестиція в MCP Apps не прив’язує їх до одного хоста: застосунок, створений для ChatGPT, може працювати в LibreChat, а також у Claude, VS Code, Cursor, Microsoft Copilot чи навіть у термінальному хості Spy, який навчився рендерити UI прямо в консолі.
Така інтероперабельність робить MCP Apps не просто ще одним API, а кандидатом на роль базового шару для UI в агентних системах, подібно до того, як HTTP став універсальним транспортом для вебу.
Від робочої групи до глобального стандарту: дорожня карта до 2026 року
За MCP Apps стоїть не лише технічна специфікація, а й формалізований процес її розвитку. Існує публічна робоча група MCP Apps, яка збирається раз на три тижні. На цих зустрічах обговорюються пропозиції щодо змін, нові можливості, питання сумісності та досвід впровадження в різних хостах.
Паралельно працює офіційний Discord‑сервер комітету MCP Apps і ширша спільнота, де розробники діляться прикладами, обговорюють проблеми й пропонують покращення. Така відкритість важлива, оскільки MCP Apps уже використовується великими гравцями й численними незалежними розробниками, а отже, будь-які зміни мають враховувати реальні сценарії.
Очікування творців протоколу досить конкретні: до 2026 року MCP Apps має бути формалізований як глобальний стандарт UI всередині чат-додатків і агент-хостів. З огляду на те, що MCP Apps уже став першим офіційним UI‑розширенням MCP, стандартизованим у партнерстві з Anthropic та OpenAI, а також на широку підтримку з боку ChatGPT, Claude, VS Code, Cursor, Microsoft Copilot і спільноти, ця мета виглядає не декларацією, а логічним продовженням поточної траєкторії.
Висновок: UI як перший клас громадян у світі агентів
MCP Apps змінює базову модель того, як ми мислимо про інтерфейси в епоху агентів. Замість того щоб зводити інструменти до «стіни тексту», протокол робить UI повноцінним учасником діалогу, але в межах чітко визначеного, контрольованого хостом каналу.
Стандартизоване двостороннє повідомлення між UI та хостом, спектр типів інтеракцій, офіційний SDK XApps, підтримка трьох парадигм UI, повторно використовувані представлення, майбутні можливості прямої взаємодії моделей з елементами інтерфейсу, а також курс на інтероперабельність з іншими протоколами — усе це разом формує інфраструктуру, яка може стати для агентних систем тим, чим HTTP став для вебу.
Якщо дорожня карта до 2026 року справдиться, MCP Apps може закріпити за собою роль глобального стандарту UI всередині чатів і агент-хостів, де бренди зберігають свій інтерфейс, користувачі — звичні патерни взаємодії, а агенти — повний контроль над сценарієм.