MCP App CSP Explained: Why Your Widget Won't Render
This article explains how Content Security Policy (CSP) works in MCP Apps, the three domain arrays, and common mistakes that cause silent failures when rendering widgets.
Why it matters
Properly configuring CSP is critical for MCP App developers to ensure their widgets load and function correctly.
Key Points
- 1MCP App widgets run in a sandboxed iframe that blocks everything by default
- 2Domains must be explicitly declared in _meta.ui.csp to allow connections and asset loading
- 3connectDomains controls runtime connections like API calls, WebSockets, etc.
- 4resourceDomains controls static asset loading like scripts, styles, images, fonts
- 5frameDomains controls embedding of third-party content in iframes
Details
MCP Apps run widgets inside a sandboxed iframe that blocks all external connections and asset loading by default. Developers must declare allowed domains in the _meta.ui.csp section of their MCP resource. The three domain arrays - connectDomains, resourceDomains, and frameDomains - control different types of requests. connectDomains allows runtime connections like API calls and WebSockets, resourceDomains allows loading of static assets like scripts, styles, and images, and frameDomains allows embedding of third-party content in iframes. Failing to properly configure these domain arrays is the #1 problem in MCP App development and can lead to silent failures where the widget simply doesn't render.
No comments yet
Be the first to comment