Support `frameDomains` → `frame-src` CSP Mapping for External Iframe Embeds

[fdaudens]

Problem

MCP Apps currently support connectDomains (→ connect-src) and resourceDomains (→ img-src, font-src, media-src) in _meta.ui.csp, but there's no way to allow external iframes. The host always applies:

frame-src 'self' blob: data:

This blocks legitimate use cases like embedding YouTube videos, Twitter/X posts, LinkedIn posts, or other third-party widgets inside an MCP App.

Evidence

Console logs from the Claude host:

[Host] Extracting metadata from _meta.ui.csp: connectDomains, resourceDomains
[Host] Applied CSP: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' blob: data: https://...; connect-src 'self' https://...; frame-src 'self' blob: data:; ...

The host reads connectDomains and resourceDomains but ignores frameDomains. Attempting to embed an iframe results in:

Refused to frame 'https://www.linkedin.com/' because it violates the following Content Security Policy directive: "frame-src 'self' blob: data:".

Proposed Solution

Add support for frameDomains in _meta.ui.csp that maps to frame-src:

_meta: {
  ui: {
    csp: {
      connectDomains: ['https://api.example.com'],
      resourceDomains: ['https://cdn.example.com'],
      frameDomains: ['https://www.youtube.com', 'https://platform.twitter.com', 'https://www.linkedin.com']
    }
  }
}

Host would generate:

frame-src 'self' blob: data: https://www.youtube.com https://platform.twitter.com https://www.linkedin.com

Use Cases

• Embedding YouTube/Vimeo videos in educational or briefing apps
• Embedding Twitter/X posts for social content curation
• Embedding LinkedIn posts in professional content apps
• Embedding Substack articles or other newsletter content
• Any app that aggregates third-party embeddable content

Environment

• Claude Desktop (macOS)
• MCP Apps SDK with TypeScript backend
• Widgets using React with official embed URLs

[idosal]

Thanks @fdaudens ! This is supported in the spec (exactly the way you've described it)

[mattpodwysocki]

@idosal I'm trying to add support for frameDomains but still having the same issue. Described below

CSP configuration not applied in Claude Desktop and VS Code (works in Goose)

We've implemented MCP Apps following the 2026-01-26 specification with CSP configuration in _meta.ui.csp, but Claude Desktop is not applying the CSP metadata and instead enforce the default restrictive CSP that blocks all iframes.

Implementation

We're implementing three MCP App tools that need to iframe external Mapbox domains. We've placed CSP metadata in the resource content as shown in the spec:

return {
  contents: [
    {
      uri: uri.toString(),
      mimeType: RESOURCE_MIME_TYPE, // "text/html;profile=mcp-app"
      text: html,
      _meta: {
        ui: {
          csp: {
            connectDomains: ['https://*.mapbox.com'],
            resourceDomains: ['https://*.mapbox.com'],
            frameDomains: ['https://api.mapbox.com']
          }
        }
      }
    }
  ]
};

Reference implementation: https://github.com/mapbox/mcp-devkit-server/tree/add-mcp-apps-support

Relevant files:

• GeojsonPreviewUIResource.ts - Uses fetch (works in all hosts)
• PreviewStyleUIResource.ts - Iframes api.mapbox.com (works in Goose only)
• StyleComparisonUIResource.ts - Iframes agent.mapbox.com (works in Goose only)

Expected Behavior

According to the MCP Apps specification, hosts should construct CSP headers based on declared domains in _meta.ui.csp:

Hosts must construct CSP headers based on declared domains and apply a restrictive default when ui.csp is omitted

The frameDomains array should map to CSP's frame-src directive, allowing our MCP Apps to iframe the specified Mapbox domains.

Actual Behavior

Goose correctly applies our CSP configuration - all three tools work perfectly, including both iframe-based tools. ✅

Claude Desktop shows CSP violations for ANY domain we try to iframe:

For preview_style_tool (iframes api.mapbox.com):

Refused to frame 'https://api.mapbox.com/' because it violates the following Content Security Policy directive: "frame-src 'self' blob: data:".

For style_comparison_tool (iframes agent.mapbox.com):

Refused to frame 'https://agent.mapbox.com/' because it violates the following Content Security Policy directive: "frame-src 'self' blob: data:".

This indicates they're using the default restrictive CSP (frame-src 'self' blob: data:) and completely ignoring our frameDomains: ['https://*.mapbox.com'] metadata.

The geojson_preview_tool (which uses fetch instead of iframes) works fine in all hosts, proving the basic MCP Apps infrastructure is working - it's specifically the CSP configuration that's not being applied.

Host Compatibility Summary

Goose:

• CSP Configuration Applied: ✅ Yes
• All Tools Working: ✅ Yes (all 3 tools)

Claude Desktop:

• CSP Configuration Applied: ❌ No
• All Tools Working: ⚠️ Partial (fetch works, iframes blocked)

VS Code Insiders:

• CSP Configuration Applied: ✅ Yes
• All Tools Working: ✅ Yes (all 3 tools)

Use Case

This is a real-world production use case: visualization tools for maps and geospatial data. Many useful MCP Apps will need to embed external content (maps, charts, data visualizations, etc.) that's hosted on trusted domains. Without CSP configuration support, these apps are severely limited.

Questions

1. Is CSP configuration (frameDomains, connectDomains, resourceDomains) fully implemented in Claude Desktop?
2. If not, is there a timeline for implementation?
3. Are we implementing the CSP metadata correctly according to the 2026-01-26 spec?

The fact that Goose correctly applies our CSP configuration for all domains suggests our implementation follows the spec properly. We want to ensure this works across all MCP Apps hosts.

[idosal]

Thanks @mattpodwysocki !

To clarify, the spec supports frameDomains. However, some hosts choose to deny or restrict access to the feature (e.g., for review/auditability, design principles, etc.)

VSCode merged the code to support it if I'm not mistaken, but @connor4312 is the best person to answer that.

Deferring to @ochafik @antonpk1 for Claude support.

[mattpodwysocki]

Thanks @mattpodwysocki !

To clarify, the spec supports frameDomains. However, some hosts choose to deny or restrict access to the feature (e.g., for review/auditability, design principles, etc.)

VSCode merged the code to support it if I'm not mistaken, but @connor4312 is the best person to answer that.

Deferring to @ochafik @antonpk1 for Claude support.

@idosal

Apologies, after some rework in the server, the CSP frameDomains works fine in VS Code, thanks for the work @connor4312, but still leaves Claude Desktop support. The comment has been updated with my latest findings.

[fdaudens]

Thanks for the clarification @idosal ! Definitely interested in Claude Desktop integration.