Render MCP Apps (SEP-1865) ui:// resources in Claude Code

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 17, 2026

What

Claude Code connects to MCP servers but does not render MCP Apps (SEP-1865) UI resources. A tool bound to a ui:// resource via _meta.ui.resourceUri returns its text result and the UI is dropped.

Why it matters

We ship an MCP server whose get_take tool is bound to a ui:// app — a side-by-side shot compare with a note feed and approve / give-notes controls. It mounts correctly in hosts that implement the extension (verified in MCP Inspector 2.6.0, and per the docs on claude.ai / Claude Desktop chat), so the server side is spec-conformant.

In Claude Code the same tool call is JSON. That splits our users in half: the people who live in Claude Code — the ones actually doing the work in a repo — get the strictly worse surface, and the richer one is only available to people who switch apps.

Current behaviour

  • claude mcp add --transport http … connects fine; tools work.
  • capabilities.extensions does not advertise io.modelcontextprotocol/ui, so the server correctly falls back to text.
  • Nothing in https://code.claude.com/docs/en/mcp mentions apps, ui://, or UI rendering — only tools, resources, prompts, channels.

Ask

Implement the MCP Apps client half in Claude Code: advertise io.modelcontextprotocol/ui, resources/read the bound ui:// resource on a tool result carrying _meta.ui.resourceUri, and render it in the sandboxed-iframe surface the app already has for artifacts and widgets.

If that is already planned, a note on where it sits would be useful — right now server authors have to guess whether to build a text-only fallback permanently or temporarily.

Meanwhile

For anyone hitting this: returning an image content block beside the text gets you a visual in Claude Code today, since image content does render. It is not interactive, but it beats a path.

View original on GitHub ↗