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?

[khandrew1]

We also recently ran into this issue when trying to submit on both ChatGPT and Claude.

On ChatGPT, ui.domain also drives the UI link destination for the app. For example, we set ui.domain to https://manufact.com so that clicking on the app name "Manufact" in the chat UI brings the user to our homepage. This lets builders use ui.domain as a branding/navigation anchor independent of where the MCP server actually lives.

Perhaps a new field like ui.homepage_url could be used to drive this instead.