You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Host-controlled WebMCP access between iframes #317
Consider a host application that composes several cross-origin applications in iframes, with one iframe containing an agent:
Host
├── Agent iframe
├── App A iframe
├── App B iframe
└── App C iframe
Apps A–C may expose WebMCP tools. The host wants the agent to use those tools, but does not necessarily want the apps to discover or invoke tools exposed by other frames.
The host therefore wants to define a topology like:
Frame
Expose tools
Use tools
Agent
no
yes
App A
yes
no
App B
yes
no
App C
yes
no
The current model seems awkward for this use case because cross-origin access relies on providers and consumers knowing each other's origins through exposedTo and fromOrigins.
In a composed application, the embedded apps may not know or care which agent implementation the host uses. The host is the component that knows the intended relationship between the frames.
Would it make sense to separate the current tools permission into two independently delegatable capabilities, conceptually:
This would let the embedding host decide which frames may expose WebMCP capabilities and which frames may consume them.
There would probably also need to be a way for a provider to opt into host-authorised exposure, rather than having to enumerate every possible consuming agent origin.
This seems particularly useful for host applications that compose independent first- and third-party web applications alongside an embedded agent.
There would probably also need to be a way for a provider to opt into host-authorised exposure, rather than having to enumerate every possible consuming agent origin.
more than tools-provide and tools-consume, right? Because it sounds like what you really want is the tool provider to not have to know which origins to expose tools to explicitly.
Activity
domfarolino commentedon Sep 24, 2026
The crux of this proposal really leans on:
more than
tools-provideandtools-consume, right? Because it sounds like what you really want is the tool provider to not have to know which origins to expose tools to explicitly.