Our MCP server is adding an MCP App, an interactive HTML view the host renders in the chat. What does the host's sandbox actually protect, what can the app still do, and how do we lock it down so a bug or a hostile input in the view can't call our tools or leak data?

What should I check, step by step?

1. Declare only the origins the view needs in _meta.ui.csp: connectDomains for fetch, XHR and WebSocket, resourceDomains for scripts, styles, images and fonts. Leave frameDomains and baseUriDomains out unless you need them; omitted, the host uses frame-src 'none' and base-uri 'self'.

2. Prefer bundling scripts and styles into the HTML over loading them from a CDN, so there's no third-party origin in resourceDomains that could change what runs.
3. Request camera, microphone or geolocation in _meta.ui.permissions only if the view truly needs them; hosts map them onto the iframe's allow attribute and may still refuse.
4. Mark tools that only the view should call with _meta.ui.visibility ["app"] so the host keeps them out of the model's tool list, and mark tools the view must never call with ["model"].
5. Authorize every tools/call on the server as if it came from anyone: visibility is enforced by the host, not by your server, and a host that doesn't support MCP Apps simply treats the tool as a normal tool.
6. Treat tool input and tool results the host pushes into the view as untrusted data: render them as text, never through innerHTML or eval, since they can carry content from the model or from third parties.
7. Don't put API keys, tokens or user data in the ui:// HTML. Hosts may prefetch and cache the resource, and any client that can call resources/read can fetch it.
8. Don't have the view send ui/message or ui/update-model-context text the user didn't write or see; content that steers the model is exactly what a reviewer will flag.
9. Keep the template stable between releases and version it on purpose, and scan its text for hidden markup before publishing, because hosts may hash, review or allowlist templates.

What does the MCP Apps iframe sandbox and CSP protect?

The spec requires every view to run in a sandboxed iframe, with all communication through postMessage, so the view can't read the host page's DOM, cookies or local storage, navigate the parent page or run script in the host's context. A web host must also put the view behind a sandbox proxy on a different origin from the host, and the proxy loads your HTML with a CSP built from your declared domains and with object-src 'none'.

• Hosts must block connections to domains you didn't declare, may restrict the policy further but must not allow undeclared domains; they should warn users when a view needs external domains and should log the CSP they applied. If you need a stable origin so your API can allowlist the view for CORS, the spec's _meta.ui.domain field exists for that, and its format is up to each host.

What can an MCP App view still do inside the host, and do hosts ask the user first?

Through the host, a view can request tools/call on its own server, send a message into the conversation (ui/message), replace the context the model sees on its next turn (ui/update-model-context), ask the host to open a link (ui/open-link) and ask for a different display mode. The spec says hosts should add ui/message content to the conversation and may request user consent, should pass model-context updates to the model and may show them to the user. The project's announcement says hosts can require explicit approval for UI-initiated tool calls; it isn't a requirement.

• The spec's own threat model lists a malicious server delivering harmful HTML, a compromised view trying to escape the sandbox, unauthorized tool execution, exfiltration of host data, and phishing or social engineering, and notes that a view can still show misleading content and burn CPU and memory. A real example of the gap between host and view: one of the critical MCP Inspector advisories published on October 21, 2026 let a remote MCP App steal the Inspector proxy's token (fixed in 1.0.3).

Does MCP Apps tool visibility (app-only tools) protect your server's tools?

_meta.ui.visibility defaults to ["model", "app"]. With ["app"], the host must leave the tool out of the model's tool list, only the view from the same server connection may call it, and cross-server calls to app-only tools are always blocked. The host must reject a view's call to a tool whose visibility doesn't include "app".

• All of that happens in the host. Your server receives an ordinary tools/call and can't tell whether a person clicked a button, the model called the tool or a different client sent it. So check the caller's authorization and the arguments on every call, require a confirmation step such as elicitation for anything that writes, spends or deletes, and log each call with its origin as far as you know it.