[Feature] Render MCP Apps (interactive ui:// artifacts) inline in sessions

Author: robottwoCreated Aug 16, 2026Updated Aug 16, 2026

Summary

MCP Apps is the first official extension to the Model Context Protocol (now part of the formal extensions framework in the 2026-07-28 spec). An MCP tool can return an interactive UI resource (ui://…) alongside its normal result, and the host renders it inline in the conversation — a sandboxed iframe speaking JSON-RPC over postMessage (the ui/ dialect). User interactions inside the widget can call server tools, update model context, or push follow-up messages, so the model stays informed without being the bottleneck for every click.

Rendered today by Claude (web + desktop), ChatGPT, VS Code, Goose, Postman, and MCPJam. Reference SDK: @modelcontextprotocol/ext-apps. Spec + quickstart: apps.extensions.modelcontextprotocol.io.

Why this fits Vibe Kanban — the building blocks already exist

Two things Vibe Kanban ships today make this a natural extension rather than a new subsystem:

  1. The preview browser. Vibe Kanban already embeds a browser pane (devtools, inspect mode, device emulation) for previewing the app being built. That's precisely the rendering surface MCP Apps needs: a sandboxed iframe with tool-result data fed in. Artifacts from MCP tools could render through the same machinery.
  2. MCP is already native here. Vibe Kanban runs its own MCP server (MCP_HOST/MCP_PORT) and orchestrates 10+ coding agents (Claude Code, Codex, Gemini CLI, Copilot, Amp, Cursor, OpenCode, Droid, CCR, Qwen) — every one of which speaks MCP. Any MCP server those agents load can emit apps; the dashboard is the layer that would show them.

Concretely: an agent loads mcp-dashboards, builds a chart of query performance, and the interactive chart appears on the task card instead of a file path. On the phone (browser UI), a live widget beats scroll-lengths of terminal output.

What lights up on day one

There's a growing ecosystem of OSS MCP servers built on MCP Apps that are essentially pure rendering services — implementing the host side makes all of them work for free:

  • mcp-dashboards — 32 tools / 45+ interactive chart types (sankey, candlestick, funnel, geo, radar…), KPI dashboards with drill-down navigation, live API polling, PNG/PPT export
  • Mermaid diagram apps — draggable/zoomable diagram editing with draft persistence via callServerTool (the spec's flagship demo, shipped as a double-clickable .mcpb extension)
  • threejs-server / map-server — 3D visualizations and interactive maps (official MCP Apps example servers)
  • markmap-mcp-server — Markdown → interactive mind maps

Hosted SaaS products (Asana, Figma/FigJam, Hex, Amplitude, Slack, Canva) already ship MCP Apps versions of their tools, which signals where the baseline is heading.

Suggested MVP scope

  1. Surface _meta.ui.resourceUri from tool results on task cards / session view
  2. Fetch the ui:// resource (readResource) and render it in the existing preview-browser infrastructure (sandboxed iframe)
  3. Implement the host side of the ui/ dialect: ui/initialize, callServerTooltools/call, updateModelContext, follow-up messages
  4. Keep text results rendering exactly as today — the spec is progressive-enhancement/backwards-compatible by design, so nothing breaks for agents or servers that don't emit UI metadata

The security model is already specified by the extension: sandboxed iframes, pre-declared UI resources that can be reviewed before execution, consent gates for UI-initiated tool calls, and auditable JSON-RPC messaging.

Prior art / demand signals

  • anomalyco/opencode#10884 — open since Jan 27, 2026, steady +1s, community PR attempts not yet merged (OpenCode desktop app)
  • openchamber/openchamber#2945 and getpaseo/paseo#3428 — the same request filed for OpenChamber and Paseo (both agent-agnostic frontends like Vibe Kanban)
  • open-webui/open-webui#20995 and #20969 — closed as "completed" via a community plugin (mcp-app-bridge) that shims the spec on top of Open WebUI's existing iframe/Rich UI system — proof of demand, and of the gap left by not doing it natively
  • Open requests with no traction yet in LibreChat (#10641), anything-llm (#5061), Jan (#7556)

No self-hosted agent frontend renders these natively today — first mover gets a real differentiator.

Happy to help spec, review, or test this.