Припиніть повертати JSON: Надсилайте інтерактивний інтерфейс разом з додатками MCP

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

Багато запитань все ще підпадають під цю схему. Підрахунок коректних розгортань не вимагає особливих зусиль: достатньо викликати get_deployments(), прочитати компактний об’єкт на кшталт {"total": 12, "healthy": 10, "degraded": 2} та відповісти в одному рядку.

Ситуація змінюється, коли люди хочуть взаємодіяти з результатом. Дашборди, процедури схвалення, таблиці з фільтрацією, форми налаштувань, графіки, панелі розгортання, багатоетапні процеси та механізми участі людини вимагають більшого, ніж просто JSON-дані. Довгий час MCP не мав стандарту для цього між хостами. Тепер він існує під назвою MCP Apps та розширює можливості серверів MCP.

Сервери MCP переважно були машинними інтерфейсами

Перша модель мислення була орієнтована на агентів. Сервери надають інструменти такі як search_projects(), create_ticket(), restart_service() та get_customer(). Моделі виявляють їх, викликають, отримують дані, а люди бачать те, що модель вирішує показати. Це потужно, оскільки операції виконуються через один протокол, а не через індивідуальну інтеграцію для кожного агента. Обмеження полягає у тому, що ці можливості були розроблені для машин, тож людина залишається на крок від первинних результатів.

Це нормально, поки взаємодія не є візуальною за своєю природою. Запит „Покажіть мені всі сервіси у продакшені“ може повернути правильний JSON-об’єкт із статусами, даними про CPU та пам’ять, проте компактна панель керування з індикаторами прогресу, значками та функціями для запису журналів, перезапуску та масштабування є набагато кориснішою. MCP Apps прагне подолати цю прогалину.

Що ж таке MCP Apps?

MCP Apps розширює Model Context Protocol, щоб сервери могли надавати інтерактивні користувацькі інтерфейси разом із своїми інструментами — не скріншоти, не Markdown у вигляді інтерфейсу, а справжні HTML/JavaScript-додатки, які відображаються всередині хоста MCP. У документації описано інструменти, які рекламують ресурси ui://, хости, які відображають ці ресурси у ізольованих iframe, а також те, як один і той самий хост вводить дані інструментів у відображення та дозволяє йому знову викликати інструменти лише через цей хост.

MCP App = MCP Tool + UI Resource + Host/View protocol

Інструмент все ще викликає API, запитує бази даних, виконує бізнес-логіку та повертає структуровані дані. Крім того, він може мати інтерфейс користувача для відображення цих результатів. Інтерфейс користувача — це ресурс MCP, наприклад ui://services/dashboard, який може містити повний фронтенд: HTML, CSS, JavaScript, React, діаграми, форми, кнопки. Таким чином одна операція отримує як можливості для роботи з машиною, так і інтерфейс для людини, стандартизовані між різними хостами.

Звідки виникли додатки MCP?

Це розширення є новим. Розробники, які випускали сервери MCP до 2025 року, не пропустили жодної прихованої функції; офіційного стандарту ще не існувало.

Наприкінці листопада 2025 року з’явився SEP-1865 — пропозиція щодо Apps, розроблена за участю співробітників MCP-UI та адміністраторів від провідних лабораторій з розробки моделей. Паралельні експерименти (MCP-UI, Apps SDK) вже існували; бракувало лише способу взаємодії, який дозволив би серверу надсилати інструменти, дані та інтерфейс, які будь-який сумісний хост міг би відтворити. У публікації блогу MCP за листопад 2025 року описано анонс SEP-1865.

До кінця січня 2026 року та сама група оголосила Apps першим офіційним розширенням, готовим до використання, з більш детальними специфікаціями, SDK та підтримкою відповідних хостів. ChatGPT, Claude, Goose та Visual Studio Code були названі серед перших клієнтів. У публікації блогу MCP за січень 2026 року Apps оголошено першим офіційним розширенням.

Кандидат на випуск у липні 2026 року покращив функціонал розширень у цілому — стабільні ідентифікатори, переговори щодо можливостей, окремі репозиторії, незалежне версіонування та розділ Extensions Track, який перелічує додатки. Також було наголошено, що виклики через кнопки все ще проходять через шлях JSON-RPC хоста, залишаючи Agent → Tool та Human → Button → Tool під одним контрольним рівнем. Пост про кандидата на випуск у липні 2026 року на блогу MCP присвятований розділу Extensions Track.

У вересні 2026 року стаття AWS Bedrock AgentCore показала конкретну схему хостингу, не обмежуючи додатки лише AWS: хост → шлюз → середовище виконання → сервер MCP (інструменти + ресурси UI) → Lambda/DynamoDB. У демонстрації використовувався ChatGPT, і зазначалося, що хости додатків Claude та інші працюють так само. Для детального огляду перегляньте статтю на блогу AWS Machine Learning про інтерактивні додатки MCP з Bedrock AgentCore.

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

Підтримка MCP не є тотожною підтримці додатків MCP. Клієнт може працювати зі звичайними інструментами та ресурсами без впровадження розширення Apps. У оголошенні в січні 2026 року згадували ChatGPT, Claude, Goose та VS Code; поточна документація описує вбудоване відображення у Claude, ChatGPT та інших сумісних клієнтах, зазначаючи при цьому, що підтримка хоста варіюється. Проектуйте з урахуванням цієї реальності: не припускайте, що кожен клієнт розуміє додатки Apps. Корисне рівняння має вигляд Сервер підтримує додатки MCP + Хост підтримує додатки MCP = Інтерактивний інтерфейс, і ретельно спроєктований сервер має переходити на текстовий або структурований формат контенту, якщо хост не може відобразити додаток.

Єдине питання, яке справді має значення

Якщо ресурс інтерфейсу — це статичний HTML, як до нього потрапляють змінені дані інструменту? Частота обробки процесора може становити 21% зараз та 87% через десять секунд; повна регенерація фронтенду після кожного виклику інструменту була б абсурдною. Відповідь — розділення: інтерфейс та дані є окремими елементами. Вважайте інструмент виробником даних, ресурс — формою їхнього відображення, а хост — з’єднуючим елементом. Інструмент повертає динамічні дані; ресурс — програму, яка знає, як їх відобразити; хост об’єднує їх під час виконання.

Як насправді працюють додатки MCP

Розгляньмо функцію get_servers(), яка повертає об’єкти серверів з полями id, name, status, CPU та memory, а їхні метадані вказують на ui://servers/dashboard. Життєвий цикл:

Модель викликає get_servers(). Сервер виконує свою логіку — роботу з базою даних, хмарним API, Kubernetes чи внутрішніми сервісами — та повертає структуровані дані. Хост бачить метадані інтерфейсу для ui://servers/dashboard та відправляє запит resources/read. Сервер повертає пакет коду фронтенду (React, Vue чи звичайний JavaScript). Текущі рядки даних про сервери не вбудовуються у цей HTML; інтерфейс знає лише очікуваний формат даних (servers[].id, servers[].status тощо).

Хост відображає додаток у інфраструктурі типу sandboxed iframe, щоб код інтерфейсу з сервера MCP не міг вільно впливати на DOM, сесію чи облікові дані хоста. Потім хост передає результат роботи інструменту у активний вигляд, зазвичай через JSON-RPC за допомогою postMessage між хостом та інфраструктурою sandboxed view.

Фронтенд отримує дані так само, як будь-який SPA, і відповідним чином їх відображає. Один сервер генерує одну картку; п’ятдесят серверів — п’ятдесят карток. Сам додаток залишається незмінним; змінюються лише дані.

Порівняно з класичним веб-додатком, де React викликає GET /api/servers, у MCP Apps агент ініціює виклик tools/call, інструмент повертає JSON, а хост вставляє цей JSON у React-додаток всередині iframe. Інтерфейс не завжди отримує дані самостійно; хост може надіслати їх безпосередньо.

Але MCP Apps — це не просто кращий вигляд результатів інструментів

Глибшою особливістю є те, що додаток також може викликати інструменти. Кнопки, форми та діаграми не є декоративними елементами; вони можуть використовувати ті самі MCP-інструменти, що й агент, через хоста.

MCP App → call tool → Host → tools/call → MCP Server → restart_server()

Наприклад, кнопка перезавантаження всередині панелі керування може викликати restart_server через хоста, замість того щоб створювати додатковий канал зв’язку:

async function restartServer(serverId) {
  return app.callServerTool({
    name: "restart_server",
    arguments: { server_id: serverId }
  });
}

Хост залишається тим, хто контролює дозволи, облік діяльності та правила.

Таким чином, одна й та сама операція на серверному рівні може мати два вигляди: інструмент, який модель використовує під час розмови, та додаток, яким керує людина візуально. Один не замінює іншого. Агенти залишаються ефективними у розумових операціях з відкритим результатом; додатки проявляють себе найкраще, коли важлива структура, інтенсивність або повторювані дії.

Уявіть собі агента, який складає історію користувача, яку необхідно схвалити перед тим, як її зберегти. Без додатків модель вставляє чернетку у чат та сподівається, що людина введе «схвалити» або «відхилити з поясненнями». За допомогою додатків інструмент на кшталт present_user_story_for_approval може повернути чернетку разом із ресурсом інтерфейсу, який містить кнопки «Прийняти», «Запросити зміни» та «Відхилити». Клацання на «Відхилити» може відкрити поле для введення причин; натискання «Ок» може викликати інструмент, який фіксує рішення та за потреби оновлює контекст моделі, щоб наступний етап вже знав, чому версія 1 провалилась.

Цей підхід передбачає участь людини з реальним інтерфейсом керування, а не крихку процедуру на основі природної мови.

Не кожна кнопка мусить бути інструментом, який бачить модель

Деякі інструменти мають бути доступними лише для агентів, деякі — лише для додатків, а деякі — спільними. Сторінкування всередині панелі керування можна викликати лише з точки перегляду, щоб модель не була завантажена зайвими інструментами для перемикання сторінок. Сервер може визначати різні рівні видимості, створюючи справжні межі доступу замість простої конвенції найменувань.

Комунікація також може відбуватися від додатку до контексту моделі (за умови дозволу хоста): причина відхилення, введена в інтерфейсі користувача, може оновити контекст, щоб наступний крок моделі покращив чернетку, без необхідності для користувача повторного введення критики в чаті.

MCP Apps — це не нова базова примітивна структура

Незважаючи на назву, Apps не є четвертим елементом серед інструментів/ресурсів/запитів. Це розширення, яке стандартизує взаємозв’язок між інструментом та ресурсом інтерфейсу користувача, а також протоколом хоста/перегляду. Якщо інструменти та ресурси вже є знайомими, Apps є інтерактивним шаром навколо них, а не окремим протоколом, доданим ззовні.

Що змінюється, якщо у вас є власний додаток чату

Команди, які створюють власну платформу агентів, стають хостами MCP. Цей хост мусить виявляти метадані інтерфейсу користувача, читати ресурси, інкапсулювати додаток у сендбоксі, передавати дані вхід/вихід інструментів до вікна перегляду, проксювати дозволені виклики інструментів назад на сервер, домовлятися про можливості та контролювати дозволи. Це справжня архітектурна складова.

Існує три учасники — сервер MCP, хост MCP та вікно перегляду додатку MCP — а офіційний SDK розділяє розробників вікон, хостів та авторів серверів. Допоміжні пакети знаходяться у директорії @modelcontextprotocol/ext-apps у TypeScript, що не змушує розміщувати бізнес-логіку в Node. MCP на рівні кабелю все ще використовує метадані інструментів, ресурси, структурований контент та запити MCP, тому сервер на Python/FastMCP може працювати, якщо він надає те, чого очікують хости з підтримкою Apps. Вікно перегляду — це веб-технологія; існуючі бекенди можуть залишатися без змін.

Безпека не може бути питанням на останньому етапі

Виконуваний інтерфейс користувача підвищує ризики. Інфрейми з ізоляцією та виклики через хост допомагають, проте кожен додаток слід розглядати як ненадійний інтерфейс користувача — особливо коли він може запустити restart_service(), delete_resource(), approve_payment() або deploy_to_production(). Діалогові вікна підтвердження корисні, але недостатні. Аутентифікація, авторизація, валідація, політики, журнали аудиту, ідемпотентність, перевірки версій та обмеження швидкості все ще мають знаходитися на бекенді. Інтерфейс користувача — це не межа довіри.

Де додатки MCP справді мають сенс

Не обгортайте кожний інструмент у додаток. Для повернення коду 42 або рядка версії не потрібен React. Додатки стають корисними, коли взаємодія має певну структуру:

Панелі керування операціями — послуги, розгортання, інфраструктура, журнали, метрики, завдання, черги: перевірка та подальші дії.

Процеси схвалення — схвалити/відхилити, прийняти/запросити зміни, розгорнути/sкасувати, опублікувати/залишити у чернетці. Часто це найкращий варіант для корпоративних потреб.

RAG та пошук корпоративних знань — фільтри, прапорці та опція „Порівняти обране“ дають кращі результати, ніж двадцять пошукових результатів у простому тексті, при цьому агент все одно виконує логічні обчислення.

Керування агентами — мова природного спілкування допомагає визначити, хто може отримати доступ до продакшн-версії Salesforce; перегляд реєстру є кращим способом для перевірки та схвалення змін у правах доступу.

Форми та налаштування — описувати параметри як „CPU 2, пам’ять 4GB, регіон us-east-1, копії 3“ є гіршим варіантом, ніж використання форми, яку агент може викликати за потреби.

Не створюйте окремий додаток для кожного інструменту

Уникайте поширення tool_1 → app_1. Віддавайте перевагу додаткам у форматі доменів. Додаток „Управління розгортанням“ може об’єднати операції отримання даних, журналування, перезапуску, масштабування та скасування змін у єдину групу. Один інструмент дозволяє відкрити додаток; після цього інтерфейс може безпосередньо викликати відповідні операції. Інтерфейс користувача залишається послідовним, а інтерфейс MCP — чистішим.

Більша архітектурна зміна

Цікавою зміною є не сам iframe. Операції, розроблені для агентів, тепер можуть надавати стандартизований інтерфейс для людей:

OPERATION → Machine Interface (MCP Tool) + Human Interface (MCP App)

Якщо функціонал упакований як плагіни для агентів, пакет Salesforce може постачати разом інструкції, інструменти (search_accounts, create_opportunity, update_lead), дозволи, оцінки та додатки (браузер облікових записів, форма для оформлення можливостей, панель керування потоком роботи). Таким чином функціонал стає повноцінним інтерфейсом взаємодії як для агентів, так і для людей.

Агенту не обов’язково знати про існування React чи iframes. Він викликає get_services(...) або present_user_story_for_approval(...); метадані повідомляють хосту про наявність інтерфейсу. Інтерфейс залишається у шарі UI, де відбувається взаємодія з агентом, а бізнес-логіка — у бекенді.

Як я впровадив би це у існуючу систему

На платформі, яка вже має користувацький чат, агентів та сервер FastMCP, уникайте повної переробки. Почніть з однієї функції лише для читання, наприклад get_agents(), разом із найпростішим переглядом (ui://agents/list), який відображає імена, статуси та кількість інструментів — без кнопок. Доведіть цей цикл: агент викликає інструмент, хост виявляє UI, читає ресурс, відображає iframe, а результат інструменту потрапляє у перегляд.

Потім додайте функцію оновлення, далі справжню операцію, наприклад вимкнення агента, потім механізми авторизації та обліку дій, а також розширені функції додатків. Впровадження відбувається поступово без необхідності переписування логіки роботи агента.

Команди, які оцінюють можливості впровадження, також повинні передбачити кошти на переговори щодо можливостей хоста. Сервер, який розуміє додатки та завжди передає метадані інтерфейсу, все одно може правильно функціонувати на старіших клієнтах, якщо хост просто ігнорує невідомі поля, а структурований вміст інструменту залишається повним. Навпаки, хост, який стверджує підтримку додатків, повинен впровадити механізми ізоляції, читання ресурсів та проксі-обробки викликів інструментів перед тим, як увімкнути відповідний флаг для кінцевих користувачів; неповно реалізовані хости створюють несправні іфрейми, які швидше підривають довіру, ніж це могло б зробити звичайний JSON.

Механізми спостережуваності також мають бути включені до того ж плану впровадження. Фіксуйте, які інструменти передають ресурси користувацького інтерфейсу, які хости їх обробляють, які виклики інструментів через кнопки були успішними, а які замінилися текстовим форматом. Ці показники допоможуть з’ясувати, чи справді додатки передають інтерактивний контент, чи користувачі все ще воліють писати повідомлення в чаті. Без такої телеметрії легко створити панелі керування, якими ніхто не користується.

Нарешті, підтримуйте версіонування схем контрактів. Додаток та інструмент мають узгоджувати назви та типи полів. Якщо розділити servers[].cpu на вкладені об’єкти, не оновлюючи контракт користувацького інтерфейсу, це призведе до відображення порожніх елементів, хоча агент все одно отримуватиме правильний JSON. Розглядайте очікуваний набір даних додатка як публічний API, який належить тій самій команді, що й інструмент.

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

Останні міркування

MCP відповідає на питання про те, як агенти взаємодіють з зовнішніми системами через один протокол. MCP Apps відповідає на питання про те, як люди можуть використовувати ті самі функції, не залишаючи рамок розмови.

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

Саме тому MCP Apps — це більше, ніж просто кращі відповіді: сервери еволюціонують від кінцевих точок, орієнтованих на машини, до портативних шарів взаємодії як для агентів, так і для людей.

У документації до вашого сервера у розділі README чітко вкажіть можливості резервного функціонування: які інструменти оголошують ресурси користувацького інтерфейсу, які хости відомі тим, що можуть їх відображати, та як виглядає текстовий/структурований резервний варіант, коли додатки недоступні. Така документація запобігає поступленню заявок на підтримку у форматі „MCP не працює“, коли справжньою проблемою є хост без увімкненої розширення.

Додаткова література

Основна документація до розширення Apps опублікована за адресою apps.extensions.modelcontextprotocol.io (розділи загального огляду та API). Описи подій у часовій послідовності розміщені на blog.modelcontextprotocol.io щодо пропозиції для 2025 року, оголошення про випуск у 2026 році та версій розширень, призначених для тестування. У блогу AWS Machine Learning пізніше було представлено шаблон розміщення Bedrock AgentCore, який залишається незалежним від конкретного хоста.

Якщо ви сьогодні підтримуєте кілька серверів MCP, стримуйте бажання створювати приватні міні-фреймворки для кожної команди. Краще використовувати спільні інструменти хоста для керування життєвим циклом iframe, спільні типи TypeScript для даних інструментів, які використовують додатки, та короткий чек-лист для перевірки дизайну: чи потребує цей інструмент інтерфейсу? Чи є вже додаток, який міг би його поглинути? Яка буде альтернатива, якщо хост не зможе відтворити додатки? Хто відповідає за автентифікацію запитів, викликаних кнопками? Ці чотири запитання допомагають уникнути надмірного розширення додатків.

Навчання також має велике значення. Агенти, які раптово бачать менше інструментів через те, що деякі операції перемістилися у режим видимості лише в додатку, будуть поводитися інакше. Оновлюйте системні підказки та набори для оцінки, коли розділяєте рівні доступу, та підтримуйте тест «золотого шляху», який відкриває додаток, натискає безпечну дію та перевіряє, чи з’являється рядок аудиту на сервері. Без цього тесту проблеми залишаються прихованими в iframe, поки клієнт не повідомить про недіючу кнопку.

Коли всі ці елементи на місці, додатки MCP перестають здаватися чимось новим та починають виглядати як звичайні елементи інтерфейсу для платформ агентів. Це створює замкнений цикл впровадження з чіткими альтернативами та вимірюваним рівнем використання.