# Inside WebMCP: how Google's new browser API lets websites talk to AI agents natively

**Date:** 2026-05-26
**URL:** https://www.tryrankly.com/blogs/inside-webmcp-google-agentic-web
**Section:** Deep Dive
**Read time:** 14 min

WebMCP is a W3C Web Machine Learning Community Group draft co-authored by Google and Microsoft. It adds one new browser API, `navigator.modelContext.registerTool(...)`, which lets a page register JavaScript "tools" that an AI agent inside the browser can call directly. Behind a Canary flag today; origin trial pending in Chrome 149 (currently in the Early Preview Program).

## What WebMCP is

A single new browser API surface: `navigator.modelContext.registerTool(tool, options)`. The spec ships no tools of its own. Each tool is a JavaScript function the page itself registers with four parts: a `name` (regex `[A-Za-z0-9_.\-]{1,128}`), a natural-language `description` the agent reads to decide whether to call it, a JSON Schema `inputSchema`, and an async `execute()`. Lifecycle is the spec's `AbortSignal` pattern - register on mount, unregister on unmount.

Editors: Brandon Walderman (Microsoft), Khushal Sagar (Google), Dominic Farolino (Google). Spec home: https://webmachinelearning.github.io/webmcp/

## Who it's for - human or agent?

For agents only. Humans see no difference. The page declares its actions as tools on a separate channel (`navigator.modelContext`) that humans never touch. Closer in spirit to schema.org for AI than to a UI: schema.org describes content; WebMCP describes capabilities.

## Which agents specifically

Only agents that act through a real browser tab. Five concrete categories see WebMCP tools:

- **Native browser AI** (e.g. Gemini in Chrome sidebar)
- **Browser extension** (e.g. Google's WebMCP Inspector)
- **In-page widget** the site itself ships
- **Headless browser stack** (Browserbase, Browser Use)
- **CV-driven browser agent** if hooked up (Project Mariner, Anthropic Computer Use)

Two categories do NOT see WebMCP:

- **Server-side crawler** (GPTBot, Googlebot, ClaudeBot, Bingbot) - no browser in the request path
- **Server-side LLM tool-caller** (ChatGPT plugins, server MCP) - use MCP / ACP / UCP server protocols instead

## Why it's locked behind EPP right now

As of May 2026, the API is in Chrome Canary 146+ behind a `chrome://flag`. The public origin trial is announced for Chrome 149 but the registration card is not yet on the Origin Trials dashboard. Path today: Early Preview Program at https://goo.gle/chrome-ai-dev-preview-join

Without an origin trial token, stable-Chrome users won't have `navigator.modelContext` exposed automatically. Three things still work for them: in-page assistants the site itself runs, Google's WebMCP Inspector extension (uses `navigator.modelContextTesting` via extension permissions), Canary users with the flag.

## Who made it and why

W3C Web Machine Learning Community Group draft (not yet on the Recommendation track). Intent to Experiment filed in April 2026; publicly announced at Google I/O 2026.

The gap: browser-side AI agents today have two bad options for taking action on a site:

1. **Parse the DOM and click pixels** - slow, fragile, breaks every redesign
2. **Call the site's server API directly** - requires the agent to discover, authenticate, and authorize against an auth system the user is already signed in to in the browser

WebMCP's answer: the page is already running, already logged in, already has working code paths for every UI action. The agent should call those functions with structured arguments. Eliminates DOM scraping and auth-juggling. Keeps the user's tab as the consent boundary.

## How you allow / disallow specific agents through WebMCP

Two origin-based controls (not User-Agent-based - WebMCP does not look at UA strings).

**1. Permissions-Policy: tools header.** Standard HTTP header. Default is `self` (only your own origin can registerTool). Examples:

    Permissions-Policy: tools=self                                  # only own origin
    Permissions-Policy: tools=(self "https://partner.example.com")  # allow a partner frame
    Permissions-Policy: tools=()                                    # disable WebMCP entirely

**2. Per-tool options.exposedTo allowlist.** A list of agent origins allowed to see and call this specific tool. Other agents see the tool as not-existing.

    navigator.modelContext.registerTool(
      { name: 'complete_checkout', ... },
      {
        signal: ctrl.signal,
        exposedTo: [
          'https://gemini-in-chrome.google',
          'https://inspector.webmcp.dev',
        ],
      }
    )

These compose. Permissions-Policy is coarse on/off at the origin level; exposedTo is fine-grained per-tool. Add `client.requestUserInteraction(...)` on destructive tools and you have three independent gates: server-decided origin allowlist, page-decided per-tool allowlist, user-decided confirm-on-call.

No User-Agent allowlist exists in the current draft. Origin-only.

## Where it sits in the stack

WebMCP is a client-side mechanism. Configuration touches multiple layers:

- **CDN / edge** - decides which clients fetch your HTML. Blocks here happen before WebMCP exists.
- **Origin server** - sends `Permissions-Policy: tools`, ships page JS, injects the `Origin-Trial` token meta tag.
- **Page JS** - calls `registerTool` with per-tool `exposedTo` and lifecycle `AbortSignal`.
- **Browser** - owns `navigator.modelContext`, enforces policy, surfaces tools to in-browser agents.

WebMCP is NOT a substitute for the edge. It is a different control surface for a different audience.

## Scenario A: CDN blocks everything. Can WebMCP let some agents through?

No. If the edge refuses the request, the agent never gets the HTML, never sees the JS, never reaches `registerTool`. WebMCP runs three layers up.

Mostly a moot scenario - Gemini-in-Chrome, the Inspector extension, and in-page widgets all run inside a normal user-opened tab; the HTTP request looks like any human visit and the CDN has nothing to block. The case where it matters: headless browser stacks like Browserbase / Browser Use that hit your CDN with identifiable User-Agents or IP ranges. If your edge blocks them, WebMCP doesn't change anything.

Outcome matrix:

| Edge says | Page WebMCP config | Result |
|---|---|---|
| Blocked | Allowed (any) | Edge wins. 403. No WebMCP. |
| Allowed | `tools=()` Permissions-Policy | Page loads, registry denied, zero tools. |
| Allowed | `tools=self`, no exposedTo | Every browser-side agent sees every tool. |
| Allowed | `tools=self` + per-tool `exposedTo:[A,B]` | Only origins A and B see gated tools. |

## Scenario B: CDN allows everyone. Can WebMCP selectively block some?

Yes - with one asterisk.

- Send `Permissions-Policy: tools=()` to disable WebMCP entirely on the response. Page renders normally for humans; no agent can call the registry.
- Keep WebMCP enabled at origin level, use per-tool `exposedTo` to limit tools to specific agent origins. Everyone else loads the page fine.

**Asterisk:** WebMCP gates by *origin of the calling agent*, not by "is this a bot." You cannot say "allow OpenAI agents only" - you can say "allow this specific browser-side surface only." Server-side bots are unaffected because they never run in a browser.

## How agents actually arrive on a WebMCP-enabled page

Three concrete vectors today:

1. **Native browser AI (e.g. Gemini in Chrome).** Built into the browser. Reads the tool registry via `navigator.modelContext`. The "every Chrome user gets an agent for free" story. Gated on the Chrome 149 origin trial.

2. **Browser extension (Google's WebMCP Inspector).** Installed once, works on any site. Uses `navigator.modelContextTesting` via extension permissions, so no origin trial token needed. Lists tools, lets you execute manually, runs a BYO-key chat (Gemini, OpenAI, Anthropic, Ollama).

3. **In-page widget shipped by the site.** A "chat with us" widget that's actually an agent reading the page's own tool registry. Works for every visitor with no install. Browserbase / Browser Use style headless stacks fit the same shape.

None of these arrive through a request the CDN can identify as "an agent." The HTTP request looks like a normal user's browser, *because it is one*. The agent is acting *through* the browser, not as the browser.

## Our demo: WebMCP on the Rankly Merch Store

Forked the live store, layered WebMCP on top. Shipped:

- **16 globally-registered tools** on every page: search_products, get_product, list_categories, view_cart, add_to_cart, navigate, best_sellers, find_deals, sign_in, sign_in_demo, register_user, authenticate, local_availability, track_order, returns_policy, faq_support.
- **Page-scoped tools** registered only where they make sense: `select_variant` / `set_quantity` / `find_in_store` / `leave_review` on product detail, cart-mutators on cart, address + checkout-completer on checkout. Lifecycle uses AbortSignal.
- **Two ways to drive the registry from the page itself.** A demo mode (hardcoded intent router, no API key, 181/181 regression cases) and a live mode (Claude Messages API direct from browser, chips protocol).
- **Two external surfaces** the same registry serves automatically: Google's WebMCP Inspector (auto-detects all 16 globals via `navigator.modelContextTesting`), and any Canary user with the WebMCP flag.
- **Zero backend changes.** WebMCP is client-side. The store's UCP / ACP / server MCP endpoints are untouched.

Tested side by side with the Inspector. The agent can search, sign in, add to cart, check out, place an order - on the user's real authenticated session, without parsing the DOM.

## What it means for merchants

WebMCP does not replace server-side protocols. ACP for ChatGPT shopping, UCP for Google Universal Cart, server MCP for LLM-host integrations - those are different surfaces for different agents (server-side, not browser-side).

WebMCP adds a fourth surface: browser-side agents acting on behalf of your logged-in user, in their own tab. When Gemini-in-Chrome rolls out broadly and the origin trial opens to stable Chrome, every WebMCP-registered site becomes drivable from a sidebar 65% of internet users already have. Sites that haven't registered their actions fall back to DOM scraping with all the latency and reliability that entails.

The thing to watch is the Chrome 149 origin trial. The day the dashboard listing opens, registering your origin is a 10-minute job that converts "works for Canary devs and extension users" into "works for everyone on stable Chrome."

## References

- WebMCP spec: https://webmachinelearning.github.io/webmcp/
- Chrome for Developers - WebMCP: https://developer.chrome.com/docs/ai/webmcp
- WebMCP EPP announcement: https://developer.chrome.com/blog/webmcp-epp
- Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/gmYffo5WOE8/m/OJxuQRP3AAAJ
- WebMCP Inspector (Chrome Web Store): https://chromewebstore.google.com/detail/webmcp-model-context-tool/gbpdfapgefenggkahomfgkhfehlcenpd
- Inspector source: https://github.com/beaufortfrancois/model-context-tool-inspector
- Google I/O 2026 recap: https://www.tryrankly.com/blogs/google-io-2026-agentic-commerce-ai-search