docs(csp-cors): note that a rejected ui.domain stops the app rendering

[Booyaka101]

Summary

docs/csp-cors.md introduces _meta.ui.domain as the way to give an app a stable origin for an API server to allowlist, and #309 clarified that its format is host-dependent. Neither says what happens when the value isn't one the host accepts, and the answer isn't the intuitive one: the app doesn't fall back to the default sandbox origin, it doesn't render at all.

Why this is worth documenting

Measured against claude.ai web — one probe server, one endpoint, _meta.ui.domain as the only variable between arms, 36 renders each in a fresh conversation:

_meta.ui.domain	iframe mounted
computed sha256(endpoint)[:32] + ".claudemcpcontent.com"	10/10
absent	10/10
present, not the expected value	0/8

Because the field is documented as a CORS convenience and marked optional, it reads as safe to set speculatively. It isn't: a server that adds it while hashing an endpoint URL spelled slightly differently from the one the client connected with — a trailing slash, a missing path segment, a different scheme — converts a working app into one that doesn't render, and the surfaced error is generic enough to send you looking somewhere else entirely.

This is being hit in the wild. #671 has a widely-upvoted comment recommending that servers add this field to fix non-rendering apps; following it with a slightly wrong endpoint string produces exactly this failure. Full measurements and method are in anthropics/claude-ai-mcp#165.

Change

One [!IMPORTANT] callout in docs/csp-cors.md, next to the existing note and matching the callout style already used in the docs. No code or behaviour change.

• npx prettier --check docs/csp-cors.md passes.
• Docs-only, so no tests added.

Happy to mirror the same note on McpUiResourceMeta.domain in src/spec.types.ts (and the spec .mdx) if you'd rather it live with the type — I kept this to the docs page to stay atomic, since #309 already covers the type-level wording.