Skip to main content
WebMCP tools execute inside a document, while a consumer may run elsewhere in the document tree, a Chrome extension, or a desktop MCP client. The browser has a native mechanism for document-tree discovery. MCP-B transports solve a different problem: carrying MCP protocol messages between an explicit client and server.

Native document discovery

Child: registers and executes the tool. Parent: discovers its descriptor through the browser.Execution remains in the child document.

MCP-B iframe bridge

Parent: MCP client. Child: MCP server and tool handler.A transport carries MCP messages across the frame boundary; execution remains in the child.

​
Native cross-document discovery

Native WebMCP stays within the browser’s document model:
  1. A parent delegates the tools Permissions Policy feature to a child with allow="tools".
  2. The child registers a tool with exposedTo when another origin should be able to discover it.
  3. The parent includes that origin in getTools({ fromOrigins }).
The browser returns RegisteredTool values with their owning window and origin. This path needs no MCP client, server, or transport. It does not add MCP-B name prefixes or carry MCP prompts and resources.

​
MCP-B iframe bridging

@mcp-b/mcp-iframe connects an MCP client in the parent to an MCP server in the child. The child server must be connected through IframeChildTransport; @mcp-b/global creates that server and selects the child transport automatically when loaded in an iframe. The parent element creates IframeParentTransport, lists the child server’s items, and republishes them on the parent context. Tools and prompts receive an element-specific prefix. Resources receive mcp-iframe: wrapper URIs. A strict parent context can accept tools; prompts and resources require MCP-B extension methods. These controls are complementary, not interchangeable. allow="tools" does not create an MCP server, and allowedOrigins does not grant the native browser feature. On the bridge the two exposure controls stack: allowedOrigins decides which parents may connect, and exposedTo narrows one tool to a subset of them. A tool cannot reach an origin allowedOrigins already excludes. The browser enforces exposedTo on the native path. The bridge enforces it in the child’s own JavaScript, so only the native path holds against a compromised child.

​
Other MCP-B bridges

@mcp-b/transports also provides:
  • TabServerTransport and TabClientTransport for an MCP client and server in the same Window
  • extension transports for Chrome runtime.Port connections accepted by extension code
There is no dedicated user-script transport. Extension transports require the Chrome runtime messaging API and do not let an extension initiate a port into an ordinary web page. @mcp-b/webmcp-local-relay connects browser tools to desktop clients through localhost and stdio. Upstream chrome-devtools-mcp instead uses the Chrome DevTools Protocol for coding-agent workflows.

​
Security boundary

Each bridge establishes a security boundary. Origin validation, connection identity, extension permissions, and relay exposure must be configured in the corresponding package. For an iframe bridge, the parent validates target-origin and the child validates allowedOrigins. Tool execution remains in the child page even after the parent republishes its descriptor.