[FEATURE] Render MCP Apps for locally-configured MCP servers (config file / localhost or internal-network HTTP)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Problem

MCP Apps (SEP-1865, ui:// resources) only render for remote connectors on
claude.ai / Claude Desktop. Locally-configured servers never get UI rendering:

• Claude Code (CLI and VS Code extension) shows only the text result.
• Claude Desktop with a Streamable HTTP server from

claude_desktop_config.json or project mcpServers — whether on localhost
or on a company-internal host — tools work, but the UI resource is ignored
and silently falls back to text.

• Custom connectors require a publicly reachable URL. Localhost and

internal-network servers (intranet / VPN-only, not exposed to the public
internet) can't take that route, and exposing them publicly just for UI
rendering is not an option in a corporate environment.

Net effect: MCP Apps are unusable for any server behind a corporate network,
which is a large share of real MCP deployments.

Steps to reproduce

1. Run an MCP server (Streamable HTTP, on localhost or an internal-network

host) with a tool that declares _meta.ui.resourceUri and a registered
ui:// resource (text/html;profile=mcp-app), per the ext-apps examples.

1. Add it via config file in Claude Desktop or Claude Code.
2. Call the tool.

Expected: UI renders in an iframe/webview, as for remote connectors.
Actual: plain text result only.

Proposed Solution

Extend MCP Apps rendering to locally-configured HTTP servers (localhost and
private-network URLs) — at minimum in Claude Desktop, ideally also in the
Claude Code VS Code extension/webviews.

Alternative Solutions

• Public custom connector: not possible — the server must stay behind the

corporate firewall; exposing it (even via a tunnel like ngrok/Cloudflare)
violates company security policy.

• Config-file server via mcp-remote proxy: connects and tools work, but

the rendering path is tied to remote-connector infrastructure, so the UI
still falls back to text.

• Plain-text/markdown tool output: works everywhere but loses the point of

MCP Apps — no interactivity (filtering, drill-down, forms).

• Building a separate internal web app: duplicates the UI outside the chat

context and loses the model↔widget integration MCP Apps provide.

None of these are viable, which is why host-side support for rendering
locally-configured HTTP servers is the ask.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

We run an internal MCP server (Streamable HTTP) on our company network for our
ERP/operations tooling. A tool like get_order_status returns structured data
that is meant to render as an interactive widget — a sortable table with
filters and drill-down, defined as a ui:// resource on the server.

The server can never be publicly reachable: it sits behind the corporate
firewall and talks to internal systems. Every employee's Claude Desktop /
Claude Code can reach it via the internal URL (e.g.
http://mcp.internal.example:3000/mcp), and the config-file setup connects
fine — but the widget silently degrades to a text dump, so users get a wall of
JSON instead of the UI the server ships. The only path that renders widgets
(public custom connector) is exactly the one a corporate deployment cannot use.

Additional Context

Similar features in other tools: Per the MCP Apps client matrix
(https://modelcontextprotocol.io/extensions/client-matrix), other hosts
already render MCP Apps for locally-connected servers — e.g. Goose, Postman,
and MCPJam render ui:// widgets from servers added by local URL, and VS Code
GitHub Copilot renders them in editor webviews. Claude Desktop is the outlier
in tying rendering to publicly-reachable connectors.

Technical considerations: Public reachability shouldn't be technically
required for rendering. The widget HTML is not fetched from the server's URL
by the browser — the host retrieves it via resources/read over the
already-established MCP connection and renders it in a sandboxed iframe
(srcdoc). That exact rendering path already exists in Claude Desktop for
remote connectors; the ask is to route config-file HTTP servers through the
same path (i.e. not exclude them via the feature-flag gate, see #88566).
The sandbox/CSP model is identical either way, since the host never contacts
the server's network location from the render surface.

Other: Rendering support could be gated behind an explicit opt-in setting
per server if there are trust concerns about non-directory connectors.