Standardizing ui.domain for Cross-Platform Portability

[yannj-fr]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Context

The current handling of ui.domain in the MCP apps spec leads to fragmentation across host implementations.

Today:

• OpenAI requires a URL and derives a domain like: https://mydomain.com → mydomain-com.oaicontent.com
• Anthropic (Claude) derives a domain from a hash of the MCP URL: $hash.claudemcpcontent.com

This creates a portability issue:
-The same MCP app results in different origins depending on the host
-Developers must understand host-specific policies

• No stable origin → limits reuse of browser primitives (e.g. localStorage, cookies, origin-scoped caching)

Problem

ui.domain is currently underspecified in terms of:
-Deterministic derivation
-Cross-host consistency
-Intended use (security boundary vs persistence vs isolation)

As a result:

-Implementations diverge
-Apps are not portable without adaptation
-Cross-platform state persistence is effectively impossible

Proposal

Introduce a standardized, host-agnostic origin scheme.

1. Reserved shared domain

Allocate: mcpappscontent.com
We (mcpappsbuilders.com) have bought this domain, and are really happy to offer it for this purpose.

Governance: neutral body (e.g. Agentic AI Foundation or equivalent)

2. Deterministic origin format

hash.mcpappscontent.com

hash = stable hash of MCP app identifier (e.g. MCP URL or manifest digest)

3. Opt-in mechanism (optional)

{
  "ui": {
    "request_portability": true
  }
}

4. Host behavior

If request_portability = true:

Host MUST use: hash.mcpappscontent.com

Host only needs to serve a blank HTML shell, Actual UI content is still injected from MCP resources (unchanged model)

Rationale

• Portability

Same app → same origin across all compliant hosts

• Predictability

Developers can reason about storage, caching, and security once

• Low implementation cost

Hosts already generate synthetic origins

This only standardizes the derivation

Backward compatibility

Fully opt-in

Existing host-specific schemes remain valid
Ecosystem alignment
Enables consistent behavior across:

• OpenAI
• Anthropic
• OSS hosts (OpenWebUI, LibreChat, etc.)

Security Considerations

• Collision risk is negligible with standard hashing (e.g. SHA-256 truncated)
• Origin isolation is preserved (one app = one origin)
• Since iframe content is host-injected (not remote-loaded), this does not introduce new XSS vectors
• Shared domain does not imply shared storage across apps (origin still hash-scoped)

Additional Benefits

• Enables cross-platform persistence (e.g. localStorage)
• Simplifies debugging and tooling
• Makes MCP apps closer to a true “write once, run anywhere” model

Open Questions

What should be the canonical input for the hash?

• MCP URL?
• Manifest digest?
• App ID?
• Should hosts be REQUIRED to honor request_portability, or is MAY sufficient?
• Should the spec define: Hash algorithm? Length / encoding?
• Is a foundation-managed domain necessary, or could this be purely spec-defined without DNS ownership?

Conclusion

Standardizing ui.domain behind an opt-in portability flag removes unnecessary divergence while preserving host flexibility. The implementation cost is minimal, and the upside for developer experience and ecosystem cohesion is significant.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[fredericbarthelet]

Thanks @yannj-fr for mentioning this!
We've had to implement a custom meta factory for resource/read handlers on Skybridge to solve this, changing ui.domain depending on who is asking for it (original code):

const readUiResourceHandler = (uri, extra) => {
  const isClaude =
    extra?.requestInfo?.headers?.["user-agent"] === "Claude-User";

  let contentMetaOverrides: { domain?: string } = {};
  if (isClaude) {
    contentMetaOverrides = { domain: `${hash}.claudemcpcontent.com` };
  }

  return {
    contents: [
      {
        uri: uri.href,
        mimeType,
        text: html,
        _meta: { ...defaultContentMeta, ...contentMetaOverrides },
      },
    ],
  };
};

But my understanding was to allow app builders to opt-in on individual MCP hosts. How would this be achieved with your ${hash}.mcpappscontent.com proposal?