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