MCP Apps vs plain tool output: коли AI-інтеграції потрібен UI

Залишайте plain tool output, коли результат можна надійно прочитати, процитувати або передати наступному кроку як компактний текст чи typed data. Обирайте MCP App, коли користувачеві треба досліджувати багатовимірні дані, керувати станом форми, переглядати rich media або послідовно працювати з багатьма об’єктами. Офіційна extension дозволяє tool оголосити інтерактивний UI resource, який сумісний host показує всередині розмови.

MCP App не робить tool точнішим і не надає йому додаткових прав. Це окремий presentation та interaction layer поверх серверних capabilities. Якщо таблиця з десяти рядків і чітка рекомендація вже закривають намір, iframe, JavaScript bundle, event protocol і нова security surface лише збільшать вартість. Починайте з task analysis: яку дію людина не може зручно або безпечно завершити через звичайну відповідь?

• Коротка відповідь, citation або machine-readable handoff → plain tool result.
• Фільтри, drill-down, canvas, media controls або multi-step review → кандидат на MCP App.
• Наслідкова дія → server-side policy та explicit confirmation незалежно від UI.
• Host не підтримує extension → корисний text/structured fallback.
• Немає перевірюваної interaction benefit → не додавайте app layer.

У базовому патерні tool definition містить `_meta.ui.resourceUri`, що посилається на `ui://` resource. Host отримує HTML resource, зазвичай рендерить його в sandboxed iframe і передає tool result у view. UI та host спілкуються через JSON-RPC поверх `postMessage`: app може отримувати результати, просити host викликати дозволений server tool або оновити model context. Сам tool і його schema залишаються канонічним execution contract.

Розділяйте три типи стану. Authoritative domain state живе у системі-власнику; tool result є versioned snapshot або handle; ephemeral view state містить вибраний tab, фільтр чи незавершене поле. Не приховуйте єдиний ідентифікатор операції лише у браузерному state. Після refresh, повторного render або переходу на fallback користувач має відновити контекст через явний resource ID і перевірену сервером версію.

Для читання одного факту, списку висновків або невеликого набору records plain output краще індексується в transcript, легше перевіряється моделлю і працює в ширшому наборі clients. Для дослідження cohort heatmap, карти, часової шкали або великої таблиці UI з локальним sort/filter зменшує повторні model calls. Проте app повинен передавати моделі лише значущі user decisions, а не кожен hover чи scroll event.

Для введення простих відсутніх параметрів достатньо host-native elicitation або наступного conversational turn. MCP App виправданий для взаємозалежних полів, live preview чи багатоетапного review. Для виконання writes UI готує exact-action proposal, але сервер повторно перевіряє identity, tenant, object version, scope і approval. Кнопка з написом «Approve» не є доказом authorization, а приховане поле з role не є trusted claim.

• Один результат і до п’яти простих полів → спершу text, structured content або native form.
• Великий набір із локальним exploration → app із bounded snapshot і provenance.
• Залежна конфігурація з preview → app, але validation дублюється на server.
• Платіж, publish, delete або production change → proposal, policy gate, idempotency і reconciliation.
• Різні client capabilities → progressive enhancement, не дві різні бізнес-логіки.

Офіційна модель ізолює app від parent DOM, cookies і local storage host та проводить комунікацію через контрольований channel. Resource metadata може оголошувати Content Security Policy origins і запитувані permissions. Host вирішує, які capabilities надати. Отже, app має працювати з мінімальними connect, resource і permission allowlists; microphone, camera, clipboard або external navigation не слід просити про запас.

Розглядайте HTML/JavaScript resource, tool result і дані інших tools як окремі недовірені inputs. Host перевіряє resource URI, extension negotiation, message origin, method allowlist, payload size і correlation ID. Server ніколи не покладається на disabled button або client-side validation. Secrets і bearer tokens не передаються в model context чи view bundle; app викликає server tool через host, а credential boundary залишається поза iframe.

MCP Apps є opt-in extension, а підтримка залежить від host та конкретної версії. Tool повинен повертати корисний semantic result навіть коли UI не рендериться: короткий content summary для людини, `structuredContent` для client/model і стабільні identifiers для наступного call. Не повертайте лише фразу «відкрийте віджет», бо вона перетворює extension negotiation або render failure на втрату функції.

Progressive enhancement означає одну server-side business operation і кілька presentation paths. App не отримує прихований privileged endpoint, якого немає у звичайного client flow. Якщо rich interaction принципово не переноситься, визначте мінімальний fallback: read-only summary, downloadable artifact або безпечне посилання на standalone product. Analytics окремо позначає app, fallback і unsupported-host outcomes, не трактуючи render як успішно виконану бізнес-дію.

Contract suite перевіряє tool metadata, `ui://` resource, MIME profile, initialization, tool-result delivery, message validation і коректну деградацію без extension. Browser tests покривають sandbox, CSP denial, slow bundle, refresh, duplicate event, stale snapshot, offline state і два одночасні views. Security tests намагаються викликати неоголошений tool, підмінити object ID, нав’язати зовнішній origin і повторити consequential request.

Interaction quality перевіряють keyboard-only navigation, focus order, labels, error announcement, color contrast, zoom і narrow viewport. Модельний eval окремо оцінює, чи правильно assistant обирає tool, пояснює app і використовує лише релевантні user selections. Головні product signals — task completion, correction rate, time до перевіреного outcome і fallback success; click count або render count самі по собі не доводять користі.

Оберіть один read-heavy сценарій, де UI має очевидну перевагу: наприклад, exploration витрат із фільтрами та drill-down. Зафіксуйте baseline plain-output flow, реалізуйте app як progressive enhancement і проведіть replay на однакових snapshots. Canary обмежте тестовими tenants та read-only tools; writes відкривайте після negative tests, accessibility review, policy evidence та idempotent reconciliation.

Feature flag має окремо вимикати app resource, не вимикаючи базовий tool. Rollback припиняє нові renders, повертає plain response, інвалідовує проблемний asset version і звіряє незавершені operations. Audit пов’язує server, tool, resource version, host capability, view session, user action, policy verdict і authoritative outcome без запису sensitive form fields. Після rollout видаляйте app, якщо він не покращує визначений outcome або створює неприйнятний operator burden.