In February 2026, Chrome 146 Canary shipped a new browser API called navigator.modelContext. The proposal, called WebMCP, lets any website expose typed, callable tools that AI agents can invoke directly through the browser. No DOM scraping. No screen captures. No fragile CSS selectors. The agent calls searchFlights({origin, dest, date}) and gets back structured JSON.
The W3C Web Machine Learning community group released the draft specification on February 10, 2026. Microsoft Edge 147 added support in March. Google’s André Cipriani Bandarra called it “a standard way for exposing structured tools, ensuring AI agents can perform actions on your site with increased speed, reliability, and precision.” That single quote has been pasted into roughly every piece of coverage of the launch.
What that coverage misses is the part that actually matters for production: WebMCP is not MCP. The wire protocols differ. The authentication model differs. The security boundary differs. Operators who treat WebMCP as MCP-in-a-browser will misjudge both the integration work and the risk posture. Here is what is actually shipping, what it does well, and where it breaks today.
What it is, plainly
The Model Context Protocol that Anthropic released in November 2024 uses JSON-RPC 2.0 as its wire format. An MCP client connects to an MCP server over stdio, Streamable HTTP, or Server-Sent Events. The server hosts the tools, handles authentication via OAuth, and returns structured responses to the client. By April 2026, MCP had crossed 97 million installations, been donated to the Linux Foundation, and earned keynote slots at AI Engineer Europe.
WebMCP shares the conceptual model and almost nothing of the implementation. It is a browser-native API, not a wire protocol. A web page calls navigator.modelContext.registerTool() with a tool name, description, and JSON schema for inputs and outputs. The browser, not the page, mediates between the AI agent and the registered tool. The agent never sees JSON-RPC. The page never sees the agent directly. Patrick Brosset, who works on the Edge team and co-authors the spec, has been blunt about this: in a clarification post in February, he corrected his own earlier framing that called the browser an “MCP server.” It is not. The browser translates page-side tool registrations into the protocol the agent expects, but the wire format is internal to the browser implementation and is not part of WebMCP.
The W3C working group made this decoupling explicit. A WebMCP-instrumented page does not need to know JSON-RPC. An MCP server does not need to know navigator.modelContext. The two layers solve adjacent problems and the browser is the bridge.
The two APIs and the code that makes them work
WebMCP exposes two parallel surfaces. The Declarative API uses HTML attributes on form elements: add toolname, tooldescription, and parameter annotations to an existing form, and the browser registers it as an agent-callable tool with no JavaScript required. For sites with clean, semantic HTML, this is the cheap path. For an e-commerce search form, it is roughly five lines of HTML edits to ship a structured search tool.
The Imperative API is for everything else. JavaScript code calls navigator.modelContext.registerTool({name, description, inputSchema, handler}). The handler runs inside the page’s normal JavaScript context, with full access to whatever state the page already has loaded. The agent invokes the tool by name with parameters that match the schema, the handler runs, and the return value is serialized back to the agent as JSON. Conceptually it is identical to OpenAI or Anthropic function calling, except the tools live in the browser tab rather than on a backend server.
The behavior is striking when it works. A travel site registers searchFlights, selectFlight, and bookTicket as tools. The agent, instead of taking screenshots, reasoning about pixel positions, and clicking through five pages of UI, makes three structured function calls. The cost difference is real. A typical browser-use sequence on a long booking flow might burn 15 to 25 multimodal inference calls and roughly the same number of screenshot-DOM round-trips. WebMCP collapses that to three structured calls. Token consumption drops by an order of magnitude. Reliability rises because the agent stops guessing what a button does.
The authentication model is the part nobody is writing about
This is the most consequential property of WebMCP and the one that almost every introductory article skips. Standard MCP integrations require a credential management stack: OAuth client registration, token refresh logic, secure credential storage, audit logging, and security review. Connecting an agent to HubSpot or Salesforce through MCP means provisioning OAuth applications, managing refresh tokens, and instrumenting telemetry for tool-call attribution. The infrastructure work is non-trivial and is the reason most enterprise MCP adoption happens through managed gateways rather than direct integrations.
WebMCP eliminates all of that. The user is already logged into the website. Their browser session carries the cookies. Tools registered through navigator.modelContext execute in the page’s normal JavaScript context, which means they share the user’s authenticated session. There is no separate credential to provision, no token to refresh, no OAuth dance. The agent calls a tool, the tool runs as the logged-in user, and the action takes effect with the same authority the user already has.
For human-in-the-loop workflows on user-visible pages, this is the right design. The user authenticated themselves through normal browser flows. The agent assists by making structured calls into the same authenticated context. No new auth surface gets added. But the implication, which the spec acknowledges and most tooling does not, is that the agent inherits whatever access the user has. A WebMCP-enabled banking site would let an agent move money. A WebMCP-enabled medical portal would let an agent request prescriptions. The browser mediates, but the spec says nothing definitive yet about what mediation actually looks like in production.
The current answer is agent.requestUserInteraction(), a method added to the spec in early 2026 that lets a tool request browser-rendered confirmation before performing a sensitive action. It is the right primitive but it is one method, not a security architecture. Tool authors decide which actions are sensitive. Agents decide whether to call them. The user decides whether to approve the prompt the browser renders. The chain has multiple weak points and the spec leaves most of them to implementation.
The state of the spec, in plain terms
This is a draft community group report, not a finalized standard. The API surface has already moved. In March 2026, the spec removed the provideContext and clearContext methods that earlier versions defined for setting and clearing tool registrations in bulk. Replacement primitives (registerTool, unregisterTool) are now the canonical pattern. Code written against the February draft will not run against the March draft without changes. Code written against the March draft may not run against the May draft.
The W3C Working Group has Google, Microsoft, Mozilla, and Apple at the table. That is a strong signal for eventual standardization, but the historical pattern for cross-browser API rollout is twelve to eighteen months from first implementation to broad availability, and longer for APIs with security implications this large. Edge follows Chromium quickly because Edge ships Chromium. Firefox and Safari have not committed to timelines. WebKit has not posted a position document on navigator.modelContext as of April 2026.
Production teams shipping today are using the @mcp-b/global polyfill (version 2.2.0, roughly 16 KB ESM), which exposes the navigator.modelContext surface in browsers that do not yet have native support. The polyfill is the workaround that lets WebMCP-instrumented pages reach the entire browser audience while waiting for stable releases. A separate project, webmcp-connect, bridges any remote MCP server to Chrome’s WebMCP API in three lines of code, which gives operators a way to wrap existing MCP integrations into the browser-native interface without rebuilding them.
Why this matters for builders right now
The strategic question is not whether WebMCP becomes the standard. With Google and Microsoft both shipping implementations and the W3C process active, the directional bet is reasonably safe. The question is what to build during the eighteen-month window before stable cross-browser support arrives.
For B2C product teams, the answer is hedge: instrument WebMCP behind feature detection, fall back to JSON-LD and semantic HTML for agents on browsers without support, and treat the spec churn as a known cost. Detection is one line: 'modelContext' in navigator. Graceful degradation is the SDK pattern that several early adopters have already converged on.
For developer-tools and SaaS companies, the calculation is different. WebMCP changes the integration economics for any product whose primary surface is a web app. Today a SaaS company that wants its product to be agent-accessible writes a backend MCP server, hosts it, manages OAuth, and ships an integration that competes against fifty others in a directory. With WebMCP, the same product can be made agent-callable by adding tool registrations to existing pages. The integration ships when the page ships. The marginal cost of making a product available to agents falls to roughly zero.
That is also where the chicken-and-egg problem lives. Tools only exist on pages that have registered them. There is no central directory. Agents discover tools by visiting the page, which means agents need the URL first, which means search engines and dedicated registries will likely emerge to fill the gap. The team that ships a credible WebMCP discovery layer will own a meaningful piece of agent infrastructure.
Limitations and the honest list of failure modes
Three things will go wrong in 2026 deployments and the spec does not yet solve them.
The first is prompt injection through tool descriptions. WebMCP tools include natural language descriptions that the agent reads when deciding whether to call them. A malicious site can register a tool whose description manipulates the agent into ignoring earlier instructions, leaking session data, or invoking other tools with attacker-chosen parameters. The browser does not sanitize tool descriptions for agent consumption. This is the same class of attack that has plagued MCP servers since launch and the same defenses (agent-side input filtering, restricted tool capabilities, user confirmation gates) apply, but WebMCP’s lower friction makes the attack surface larger.
The second is data exfiltration through tool chaining. A page might expose a benign-looking tool that reads a value from the page and a second tool that writes that value to an external endpoint. An agent that calls both in sequence has just exfiltrated data the user never authorized. Browser CORS and CSP policies still apply, but they protect the network layer, not the tool-call sequence. The current spec does not require origin checks on tool registrations or rate-limit policy on outbound calls.
The third is the discovery ambiguity. Tool descriptions are written by site authors who want their tools called. The descriptions are read by agents that need to decide which tool serves the user’s goal. There is no third-party verification of either side. A site can write “cheapest flights to Paris” on a tool that returns sponsored results. The agent has no way to know. Search engines built reputation systems over twenty years to handle this exact problem. WebMCP arrives without one.
What comes next
Three milestones to watch. First, Chrome stable. The current rollout is Canary plus flag, which means production deployments are technically possible but operationally fragile. Google I/O in May and Cloud Next later in the year are the most likely venues for a stable announcement.
Second, Firefox and Safari position documents. Mozilla and Apple participate in the W3C process but have not yet committed to implementation. Their stance will determine whether WebMCP becomes a true cross-browser standard or a Chromium extension that forces the rest of the web into polyfills indefinitely.
Third, the security architecture. The spec calls out prompt injection and data exfiltration in its security considerations section but defers the harder design work to implementations. Whoever lands the first credible answer to agent-mediated capability sandboxing inside the browser will shape what the next decade of web automation looks like. The current model, where the user’s session is the agent’s session, works for low-stakes tasks. It does not work for the workflows enterprises actually want to automate.
WebMCP is a real shift, not a marketing one. The shift is also early enough that anything built against it today will be partially rewritten before stable. Build with that frame in mind and the upside is significant. Build assuming the API is stable and the rewrite cost will be the surprise.
Specification: W3C WebMCP draft (Web Machine Learning community group). Implementation status: Chrome 146 Canary (February 2026), Microsoft Edge 147 (March 2026). Polyfill: @mcp-b/global v2.2.0. Underlying protocol: Anthropic Model Context Protocol.