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

# @mcp-b/mcp-iframe overview

> When to use the iframe MCP bridge, how it differs from native discovery, and what the child server must provide.

`@mcp-b/mcp-iframe` runs an MCP client in the parent, connects it to an MCP
server inside the iframe, and republishes the child's capabilities on the
parent. It wraps that transport flow in a custom element so applications do not
have to wire the client and transport classes themselves.

## When to use this package

* You want a parent page to mirror an iframe MCP server's capabilities.
* You prefer a declarative element over manual `IframeParentTransport` and `IframeChildTransport` setup.
* You want namespaced tool forwarding tied to an element ID.

## When not to use this package

* You need low-level control over message flow or custom transport wiring. Use [`@mcp-b/transports`](/packages/transports/overview).
* The iframe does not run an MCP server connected through
  `IframeChildTransport`. A standalone `document.modelContext` implementation
  is not sufficient.
* You only need native tool discovery across a document tree. Use the
  browser's `allow="tools"` and `getTools({ fromOrigins })` surfaces instead.

## MCP-B bridge versus native discovery

| Concern | Native cross-document WebMCP | `<mcp-iframe>` MCP-B bridge |
| - | - | - |
| Connection | Browser-managed document tree | MCP client/server over iframe transports |
| Child setup | `allow="tools"` delegation | MCP server connected to `IframeChildTransport` |
| Tool exposure | `exposedTo`, enforced by the browser | `exposedTo`, enforced by the child page |
| Parent lookup | `getTools({ fromOrigins })` | Namespaced registrations on `document.modelContext` |
| Item types | WebMCP tools | Tools, plus MCP-B prompts and resources |

`allow="tools"` delegates the native browser feature. It does not create the
MCP server or authorize transport messages.

## Where it sits in the package graph

This package sits on top of the iframe transport pair from
[`@mcp-b/transports`](/packages/transports/overview). The parent element creates
an `IframeParentTransport`; the child server must use the matching
`IframeChildTransport`. It is a browser-facing convenience layer, not a separate
transport protocol.

## First step

Load `@mcp-b/global` inside the child and configure
`transport.iframeServer.allowedOrigins` for the parent origin. The global runtime
creates and connects the child MCP server automatically. Then import
`@mcp-b/mcp-iframe` in the parent and add `<mcp-iframe>`. The
[reference page](/packages/mcp-iframe/reference) documents the complete
contract.

## Related pages

<CardGroup cols={2}>
  <Card title="Reference" icon="book-open" href="/packages/mcp-iframe/reference">
    Element registration, attributes, methods, and event contract.
  </Card>

  <Card title="Bridge tools across iframes" icon="bridge" href="/how-to/bridge-tools-across-iframes">
    Set up a parent-child iframe bridge step by step.
  </Card>

  <Card title="Transports overview" icon="network-wired" href="/packages/transports/overview">
    Inspect the underlying iframe transport classes.
  </Card>

  <Card title="Global runtime reference" icon="globe" href="/packages/global/reference">
    Configure the child server transport and its allowed parent origins.
  </Card>

  <Card title="WebMCP API sources" icon="brackets-curly" href="/reference/webmcp/standard-api">
    Use native cross-document discovery without an MCP-B bridge.
  </Card>

  <Card title="WebMCP resources and status" icon="flag" href="/explanation/design/spec-status-and-limitations">
    Background on cross-document exposure questions that still affect iframe behavior.
  </Card>
</CardGroup>


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