Skip to main content
Content Security Policy (CSP) controls which domains your views can fetch from, load scripts/styles from, and embed. Views run in sandboxed iframes, so CSP must explicitly allow any external resources.

​
Server and asset origins

Set MCP_URL to your server’s public origin (OAuth resource URL, API calls, CSP connectDomains):
Set MCP_ASSETS_URL when view JS/CSS and public/ files are served from a different prefix (CDN, Supabase Storage):
When MCP_ASSETS_URL is unset, assets use the same origin as MCP_URL (or the request origin behind a proxy). At mcp-use build, MCP_ASSETS_URL rewrites manifest paths to full https:// URLs for static upload workflows.

​
CSP merge order

On each resources/read, the framework merges CSP in this order (high → low priority):
  1. Author view.csp on the bound tool
  2. CSP_*_DOMAINS env vars (per category) or the CSP_URLS shortcut
  3. MCP auto-append: MCP_URL → connectDomains; assets origin → resourceDomains
CSP_URLS and per-category env vars rank above MCP auto-append. Duplicate origins keep the higher-priority entry’s position.

​
Add domains for one view

Declare CSP on the tool’s view: config:
MCP Apps CSP fields: connectDomains, resourceDomains, frameDomains, baseUriDomains.

​
Global CSP env vars

Use CSP_URLS when every view needs the same extra domains (shortcut for all four categories):
Override one category without affecting others:

​
Static deployments (Supabase / CDN)

When assets live on static storage and the MCP server runs elsewhere:
See Supabase deployment for the full workflow.

​
Verify CSP

The mcp-use Inspector provides a CSP Mode Toggle for testing:
  • Permissive: Relaxed CSP for debugging
  • Widget-Declared: Enforces the view’s declared CSP (production-like)
CSP violations are logged in the console. Use Widget-Declared mode to catch CSP issues before production deployment.

​
Next Steps