Skip to content

[v2] [Web] MCP App renderer reads UI resource metadata from _meta instead of _meta.ui #2055

Closed

Description

@benrafshoon

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

Web

Inspector version

2.2.0

Node version

v22.19.0

Operating system

macOS, Chrome

Transport

Streamable HTTP

MCP server under inspection

Any MCP App server declaring UI resource metadata under _meta.ui (e.g. _meta.ui.csp with connectDomains or _meta.ui.permissions).

Steps to reproduce

  1. Start an MCP server that serves an MCP App UI resource declaring network permissions under _meta.ui.csp (e.g., connectDomains: ["https://api.example.com"]).
  2. Launch the MCP Inspector web client and connect to the server.
  3. Open the Apps screen and open the app.
  4. The running view attempts to execute a fetch() request to an allowlisted domain in connectDomains.

Expected behavior

Per the MCP Apps specification (apps.mdx and spec.types.ts), the host reads _meta.ui.csp and _meta.ui.permissions from the UI resource content block (or result level), parses connectDomains, and applies them to the generated CSP <meta> header in the inner iframe.

Actual behavior

In clients/web/src/components/elements/AppRenderer/createAppBridgeFactory.ts, extractHtmlAndMeta reads content._meta directly as McpUiResourceMeta:

meta: content._meta as McpUiResourceMeta | undefined,

Because the spec defines the metadata under _meta.ui, meta.csp and meta.permissions evaluate to undefined. approveCspSources(undefined) produces {} and buildSandboxCspPolicy generates connect-src 'none', blocking outgoing network requests.

Already prototyped a fix?

Prompt to reproduce:

In clients/web/src/components/elements/AppRenderer/createAppBridgeFactory.ts, update extractHtmlAndMeta to extract UI resource metadata from content._meta?.ui (falling back to result._meta?.ui), rather than casting content._meta directly. Update the uiResource test fixture helper in createAppBridgeFactory.test.ts to wrap supplied metadata in { _meta: { ui: meta } } to match the spec.

Verified behavior:

  • createAppBridgeFactory.ts extracts csp and permissions from _meta.ui.
  • createAppBridgeFactory.test.ts passes with the spec-compliant { _meta: { ui: ... } } structure.

Activity

  1. added
    v2Issues and PRs for v2
    bugSomething isn't working
    on Aug 19, 2026
  2. cliffhall commented on Aug 19, 2026

    @cliffhall
    Member

    Triage: Priority Medium (total 8)

    • Severity 4 — reading the UI resource metadata off _meta instead of _meta.ui makes csp and permissions evaluate to undefined for every spec-conforming app, so the declared connectDomains never reach the generated CSP and any app doing network work is unusable in the Apps tab
    • Urgency 3 — wanted this milestone
    • Bonuses: +1 bug label

    Board: #28, Status Incoming (awaiting maintainer review — no milestone yet).

  3. added this to the v2.4.0 milestone on Aug 19, 2026
  4. self-assigned this
    on Aug 23, 2026
  5. cliffhall commented on Aug 24, 2026

    @cliffhall
    Member

    Fixed by #2098, merged to v2/main as 76822633.

    The UI resource's sandbox metadata is now read from _meta.ui rather than _meta, so a spec-conforming app's csp.connectDomains and permissions reach the sandbox instead of evaluating to undefined and rendering under connect-src 'none'. All three carriers ext-apps defines are consulted, most-specific first: read content item → read result envelope (McpUiReadResourceResult) → resources/list entry (the documented static default).

    Two related repairs came along, both surfaced in review: the app-supplied permissions bag is now screened before it reaches the proxy (its buildAllowAttribute() tests keys for truthiness, so { camera: "false" } read as a grant — unscreened only because this bug meant no permissions ever arrived), and the listing carrier is wired through App.tsx.

    _meta.ui.domain (#2056) is not addressed here — it becomes readable but nothing consumes it, and the Origin: null in that report comes from the deliberate opaque-origin sandbox. Still its own issue.

  6. added a commit that references this issue on Aug 26, 2026
    06c7985
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingmcp-appsMCP Apps relatedv2Issues and PRs for v2

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions