Origin-Agent-Cluster requirement requires custom server headers on non-Chromium browsers

[beaufortfrancois]

The WebMCP spec requires an origin-keyed agent cluster for secure, isolated context execution. We did not notice this deployment friction earlier because Chromium-based browsers enable origin-keying by default.

Other browsers like Firefox and Safari still default to site-keyed clusters. For WebMCP to work on these browsers, web devs must explicitly serve this HTTP response header:

Origin-Agent-Cluster: ?1

This creates a (non-necessary?) barrier for web devs hosting WebMCP apps on platforms with no custom header support (like GitHub Pages).

@domfarolino Is there anything we can do at the spec level to help ease or remove this adoption barrier for web devs?

[domfarolino]

We have two options:

• ACK that this will get better once other browsers catch up to Chromium and ship origin-keyed agent clusters by default, and hope that happens before they implement WebMCP
• Drop this requirement from the spec

I'm speaking with @camillelamy about this offline. The concern is around whether document.domain should impact WebMCP tool registration and invocation, since document.domain technically changes a document's origin, and we need to either think through how that should interplay with WebMCP tools (which are origin-exposed and gated), or just ban both document.domain and WebMCP coexisting at the same time.

The more I think about it, I'm not totally convinced that the two can't co-exist. document.domain doesn't change the origin value of MessageEvent#origin when a message is sent form a document that has used document.domain. Since WebMCP is based off of a similar mechanism, I think we can safely say that document.domain doesn't impact the origin in exposedTo or fromOrigins.

So I personally think we can remove the OAC requirement without breaking the safety that the current requirement provides (i.e., treat WebMCP like postMessage() origin semantics). But I'd love to hear from Camille.

[johannhof]

Maybe the point is that exposedTo may be bypassed if the documents do a document.domain origin override, which would allow synchronous script access and thus calling the tools directly? Otherwise I agree that if fromOrigins ignores document.domain this should be fine, unless I'm missing something.

[domfarolino]

While strictly true, disabling WebMCP in that case doesn't protect you from the fact that you're already intentionally using document.domain to synchronously script another documennt. The problem there is document.domain—disabling WebMCP doesn't protect you against that. It's true exposedTo kind of becomes "inaccurate" because if your tool is reachable in script, suddenly another "origin" can access it, but that's true regardless of whether you use WebMCP.

Since I don't think this restriction mitigates any security concern, I'd like to see us relax it.