WebMCP Explained: Google and Microsoft's Browser-Native Agent Protocol

What WebMCP Is: A Page That Declares Its Own Tools

Today, when an agent wants to do something on a website it does not have a backend integration for, it reads the DOM, infers what the buttons and forms mean, and drives the page like a human would. This is brittle by construction. A redesign breaks it. A lazy-loaded component breaks it. An A/B test breaks it for half your users. And the agent is guessing at intent the whole time, because rendered HTML describes layout, not capability.

WebMCP inverts that. The page declares its capabilities explicitly. Your frontend registers named tools on the window.AICommands surface, each with a human-readable description, typed parameters, and a handler function. A WebMCP-aware browser exposes those tools to its in-browser agent. When the agent decides a tool is relevant to the user's request, it calls the handler with validated arguments, and your code runs in the page context with the user's session intact.

The mental model is close to an MCP server, except there is no separate server process. Registration happens in the live document, in JavaScript you already ship. A rough shape of what a registration looks like in the current Canary preview:

// Feature-detect before touching anything. The flag may be off.
if (window.AICommands?.register) {
  window.AICommands.register({
    name: "search_products",
    description:
      "Search the product catalog by keyword. Returns up to 20 items " +
      "with title, price, and availability. Read-only.",
    parameters: {
      query: { type: "string", description: "Search keywords" },
      inStockOnly: { type: "boolean", description: "Filter to in-stock items" },
    },
    handler: async ({ query, inStockOnly }) => {
      const results = await storeApi.search(query, { inStockOnly });
      return { count: results.length, items: results.slice(0, 20) };
    },
  });
}

Two things matter here. First, the tool description is the contract the agent reasons over, exactly like with MCP. Vague descriptions produce wrong calls. Second, the handler runs as the user, on the user's session. That is the whole power of being browser-native, and also the whole risk, which is why the read-only marker in that description is not decoration.

Treat the exact API shape as provisional. WebMCP is incubating, the naming and method signatures are still moving in the W3C Web ML CG, and window.AICommands is what the Canary preview exposes today, not a frozen interface. Write against it to learn the model, not to ship a dependency.

WebMCP vs MCP vs A2A: The Three Protocol Slots

The single most common confusion I see is people calling WebMCP "MCP for the browser." It shares a philosophy with MCP, declare tools, let agents discover and call them, but it occupies a different slot in the stack. Getting the slots straight is the whole game, because production agent systems will use more than one at once.

Read it left to right. MCP is how an agent reaches your backend: it exposes server-side tools over stdio or Streamable HTTP, things like databases, CRMs, and internal APIs, with OAuth 2.1 for anything network-facing. A2A is how two agents coordinate work between themselves. WebMCP is the missing middle: how an agent already running in the user's browser acts on the frontend the user is looking at, using the session they already have.

These compose. Picture a shopping agent in an agentic browser: it calls a WebMCP add_to_cart tool declared by the page, that handler in turn hits an MCP-backed inventory and pricing server on the merchant's infrastructure, and if the merchant's fulfillment agent needs to coordinate with a logistics agent, that hop is A2A. One user action, three protocols, three slots. For the full breakdown of the server-side and agent-to-agent layers, our MCP vs A2A vs AG-UI comparison maps the protocol stack in detail. WebMCP is the client-page layer that comparison did not yet have a name for.

How to Expose Your Site to Agents Today

You can prototype WebMCP right now. Here is the honest path, with the caveats that keep it from blowing up later.

1. Enable the preview. Install Chrome 146 Canary and enable the experimental WebMCP flag (the early preview landed in April 2026). This is a moving target; the flag name and location change between Canary builds, so check the current chrome://flags listing rather than trusting a hard-coded path from a blog post, including this one.

2. Feature-detect, never assume. Every line of WebMCP code lives behind a window.AICommands check. The flag is off for almost everyone, and will be for a long time. Progressive enhancement is not optional here, it is the only safe pattern:

function registerAgentTools() {
  if (!window.AICommands?.register) return; // No-op without the flag.
  registerReadOnlyTools(); // safe, idempotent
}
document.addEventListener("DOMContentLoaded", registerAgentTools);

3. Start read-only. Register tools that surface information and nothing else: product search, availability lookup, "what's in this article," store hours. A wrong agent call on a read-only tool costs nothing. Hold every state-mutating action back for now.

4. Write descriptions like API docs. The agent picks tools entirely from names and descriptions. Be specific about what the tool does, what it returns, and its limits. This is the same discipline that separates good MCP servers from bad ones, and we cover the tool-design patterns in depth in the MCP developer guide. Mark side effects explicitly so the agent (and your future self) knows the blast radius.

5. Instrument from day one. Log every tool registration and every invocation: which tool, what arguments, what it returned, how long it took. When WebMCP stabilizes, this telemetry is what tells you which tools agents actually use and how they interpret your descriptions, which is reliably more surprising than teams expect.

The reason to do this now, even behind a flag almost no one has on, is not traffic. It is that designing good tool schemas and clean handlers takes iteration, and you want that iteration done before browser-native agents reach your real users, not after.

WebMCP vs Web Agent Bridge: Two Trust Models

WebMCP is not the only proposal for letting agents act on sites. Web Agent Bridge, at v3.2, takes a fundamentally different stance on where trust lives, and the difference is the whole story.

WebMCP is browser-native. The browser vendor sits between the agent and the page, tools live on window.AICommands inside the document, and trust is mediated by the browser plus the user's session. Web Agent Bridge is transport-native. A domain advertises its agent capabilities through DNS records and signs them with Ed25519 keys, so trust is anchored at the domain and cryptographic-key level, independent of which browser, or whether a browser is involved at all.

Neither is strictly better; they fit different deployments. WebMCP wins when your users run agentic browsers from Google or Microsoft and you want page-level, session-aware actions with the least frontend ceremony. Web Agent Bridge wins when you want a browser-independent, cryptographically verifiable contract that any agent, server-side or client-side, can validate against your domain without trusting an intermediary.

My read: most teams should track both and hard-code neither. The trust models are different enough that they may end up coexisting, with WebMCP handling in-tab interactivity and a DNS-plus-signature scheme handling machine-to-machine contracts. This is the same "declare your machine-readable intent" pattern we are already seeing with the llms.txt discovery standard and with AGENTS.md for coding agents. The web is steadily learning to describe itself to machines explicitly instead of making them guess, and WebMCP and Web Agent Bridge are two competing dialects of that same shift.

What Changes for SEO and Frontend Teams

WebMCP moves part of discovery from crawling to declaration, and that reframes work for two teams at once.

For SEO, the through-line is the same one driving llms.txt, AGENTS.md, and structured data: machine-readable intent beats scraped guesswork. Today a crawler or agent infers what your page can do from rendered HTML. With WebMCP, you tell it directly. Agent affordances become a first-class output alongside markup, schema.org structured data, and metadata. The mu-plugin angle makes this concrete: a WebMCP WordPress plugin distributed through the plugin ecosystem could, in principle, reach the roughly 43% of the web that runs on WordPress, the same distribution dynamic that let structured-data plugins blanket the web in a few years. If that lands, "does my CMS expose WebMCP tools" becomes a checkbox, not a project.

For frontend teams, the shift is treating the page as something an agent operates, not just something a human renders. That has practical consequences:

The near-term move is not to rebuild your site for WebMCP. It is to get your declarative surfaces in order now, llms.txt, structured data, an accessible DOM, so that instrumenting WebMCP later is a thin layer rather than a rewrite. This is exactly the kind of agent-readiness audit we run for clients at Particula Tech: map the actions your site needs to expose, design the tool schemas, and stage them so the read-only surface ships behind the flag while the high-stakes ones wait for the spec.

When to Ship It Now vs Wait for Spec Stability

This is where most coverage waves its hands. Here is a concrete decision rule.

Ship now, behind a flag, if the flow is read-only and low-stakes. Product search, availability, store hours, "summarize this page," catalog browsing. The worst case of a wrong agent call is a useless result, which the user ignores. You get real telemetry and a head start on schema design at essentially zero downside. Keep it fully feature-detected so the 99.9% of users without the flag never notice.

Wait if the flow moves money, mutates state, or touches auth. Checkout, payments, account settings, password changes, anything destructive or irreversible. Two reasons. First, the API is still incubating in the W3C Web ML CG and the shape can change between Canary builds, so you would be building on sand. Second, and more important, the security model is not locked. A write tool runs as the authenticated user, which means prompt injection against the in-browser agent could, in a weak security model, trigger real actions on a real account. You do not want to be the cautionary CVE for that class of bug.

Use the waiting period productively. Instrument analytics on the read-only surface, design and version your tool schemas, write down your side-effect classifications, and watch how agents actually interpret your descriptions. When stable browser support and a hardened security model land, the teams that prototyped early will instrument the high-stakes flows in days. The teams that waited entirely will start from a blank window.AICommands and a clock that is already running.

WebMCP is early, genuinely early, but it fills a real gap in the agent protocol stack, and it has the two browser vendors with the most reach behind it. The smart posture is neither "ignore it until stable" nor "bet the checkout flow on Canary." It is to learn the model now, ship the safe surface behind a flag, keep your declarative agent surfaces clean, and watch both WebMCP and Web Agent Bridge until the standards stop moving. For the broader picture of how these pieces fit together, our AI development tools pillar tracks the protocols, standards, and tooling as they mature. The browser is about to become an agent surface. The teams instrumenting it now are the ones who will not be scrambling when it stops being optional.