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

# WebMCP and MCP-B extensions

> How MCP-B package behavior relates to the evolving WebMCP proposal.

The WebMCP proposal and MCP-B packages evolve on separate schedules. The
[Community Group draft](https://webmachinelearning.github.io/webmcp/) owns the
proposed browser API. MCP-B package references own the behavior shipped by this
project.

The phrase **strict core** describes MCP-B's portable package boundary. It is
not a second definition of the WebMCP proposal. Keeping that boundary narrow
lets libraries publish tools through native implementations or the polyfill
without depending on an MCP server or transport.

## Three related layers

```mermaid theme={null}
flowchart TB
  subgraph Upstream["Community Group"]
    Proposal["WebMCP proposal<br/>evolving document.modelContext API"]
  end

  subgraph Project["MCP-B packages"]
    Portable["Portable layer<br/>types, helpers, polyfill"]
    Extensions["Extension layer<br/>BrowserMcpServer, MCP features, transports"]
    Portable -->|"extended by"| Extensions
  end

  Proposal -->|"target browser contract"| Portable
```

The live draft owns the exact `ModelContext` members and signatures. MCP-B may
retain compatibility types or adapters while browser implementations converge.
Do not infer proposal status from where a method appears in an MCP-B type.

## Why the extension boundary exists

`BrowserMcpServer` adds `listTools()`, prompt and resource registration, and a
composed official MCP server. Transports, iframe routing, and the local relay
connect that server to explicit MCP clients. These capabilities solve MCP-B
integration problems; they are not browser API methods.

Protocol-specific features remain available through
`BrowserMcpServer.mcpServer`. Keeping them behind the composed server prevents
the browser surface from becoming a second copy of the MCP SDK.

Sites that only publish browser tools can use the portable layer. Applications
that need prompts, resources, bridges, or desktop MCP clients use the extension
layer. See [Runtime layering](/explanation/architecture/runtime-layering) for
the composition model and [Choose a runtime](/how-to/choose-runtime) for
package selection.