> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcp-b.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Transports and bridges

> Why WebMCP needs transports when page-hosted tools cross browser boundaries.

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.

<Columns cols={2}>
  <Card title="Native document discovery" icon="window-restore">
    **Child:** registers and executes the tool. **Parent:** discovers its descriptor through the
    browser.

    Execution remains in the child document.
  </Card>

  <Card title="MCP-B iframe bridge" icon="bridge">
    **Parent:** MCP client. **Child:** MCP server and tool handler.

    A transport carries MCP messages across the frame boundary; execution remains in the child.
  </Card>
</Columns>

## 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.

| Control | Native document discovery | MCP-B iframe bridge |
| - | - | - |
| Browser policy | `allow="tools"` | Independent of MCP connection |
| Who may connect | Document tree | `allowedOrigins` |
| Child exposure | `exposedTo` | `exposedTo`, within `allowedOrigins` |
| Parent selection | `fromOrigins` | `target-origin` |
| Payload | WebMCP tools | MCP protocol items |

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.

## Related pages

* [Bridge tools across iframes](/how-to/bridge-tools-across-iframes) for the MCP-B setup
* [mcp-iframe reference](/packages/mcp-iframe/reference) for element behavior and namespacing
* [Transports reference](/packages/transports/reference) for low-level class contracts
* [WebMCP API sources](/reference/webmcp/standard-api) for `exposedTo` and `fromOrigins`
* [Connect desktop agents with local relay](/how-to/connect-desktop-agents-with-local-relay) for the localhost bridge


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.