navigator.modelContext. The authoritative definition belongs to the W3C WebMCP spec and the Chrome team’s design documents, not to the MCP-B packages. MCP-B exists to help you use that standard today, then extend it when you need browser MCP features beyond the standard.
The problem WebMCP solves
Today, when an AI agent interacts with a website, it often does so through UI automation. The agent reads the page, decides which element to click, types text into fields, and hopes it understood the interface correctly. That is slow, fragile, and expensive in tokens. Consider an airline’s booking page. A UI-actuation agent has to infer calendars, airport codes, passenger limits, and business rules from rendered controls. A WebMCP-enabled site can publish that action as a tool with a schema. The agent receives the contract directly and reasons over the contract instead of the pixels. That is the core value of WebMCP. It turns page actions into explicit, structured interfaces.Two APIs: imperative and declarative
WebMCP offers two complementary surfaces. Imperative WebMCP is the JavaScript lane. A page registers tools in code. Declarative WebMCP is the HTML lane. A page exposes tool-like form workflows directly from markup. The distinction matters, but the exact API details are still owned upstream. If you want the precise imperative API surface, use the WebMCP standard API reference and then follow the links to the W3C spec. If you want the evolving declarative model, start with Declarative API, which points to the Chrome team’s explainer.Where WebMCP sits in the ecosystem
WebMCP is not a replacement for the server-side Model Context Protocol (MCP). MCP is the broader protocol. It includes tools, resources, prompts, and client-facing flows. WebMCP is the browser-specific standard for site-exposed tools. The relationship is complementary. A site can expose one set of capabilities in the browser through WebMCP and another on the server through MCP. They may share concepts, but they live in different runtimes and different trust boundaries. For the full comparison, see WebMCP vs MCP.Who participates
The specification is developed under the W3C Web Machine Learning Community Group. Editors include engineers from Microsoft and Google. Chrome ships an early preview behind a flag starting in version 146. The MCP-B project is a runtime layer on top of that work. It provides a strict polyfill for the standard, a fuller browser runtime when you need more than the standard, React hooks, and bridges to extensions and desktop agents. For that split, see Strict Core vs MCP-B Extensions and Native vs Polyfill vs Global.Design values
Several design choices shape WebMCP and distinguish it from alternatives like raw UI automation or server-side-only approaches: Familiar tools. Developers expose capabilities from ordinary page code and page markup. Local execution. Tool calls run in the page’s JavaScript context. The tool can work with the page’s DOM, state, cookies, and existing application logic. Browser mediation. The browser sits between the agent and the page. It can enforce permissions, show confirmation dialogs, and respect the user’s choices. Human-in-the-loop. WebMCP assumes a human is present. A browsing context is required, and the declarative model includes explicit review points. For more on this model, see Security and Human-in-the-Loop. Progressive adoption. A site can start with one tool. The cleanest first step is native WebMCP or the strict@mcp-b/webmcp-polyfill. If you later need transport, prompts, resources, or other MCP-B-only behavior, move up to @mcp-b/global.