WebMCP: How Chrome Lets a Website Expose Its Own Tools to AI Agents

An AI agent browsing your site today has one real option: read the rendered HTML and guess. It clicks buttons, fills forms, and scrapes text the same way a human would, except slower and more error-prone, because none of it was built for a machine to parse. WebMCP changes that by giving a page a second interface, one built specifically for agents, sitting right next to the one built for humans.

We covered the server-side pattern in detail: a deployed MCP server exposing your database or internal APIs as tools over JSON-RPC. WebMCP is the same idea, moved into the browser, with a different tradeoff.

What actually gets exposed

A WebMCP tool is a JavaScript function with a name, a description, and a JSON Schema describing its inputs, registered against navigator.modelContext:

// Requires HTTPS (SecureContext)
navigator.modelContext.registerTool({
  name: "searchProducts",
  description: "Search the product catalog by keyword. Returns matching products with name, price, and availability.",
  inputSchema: {
    type: "object",
    properties: {
      query: {
        type: "string",
        description: "The search keyword or phrase"
      },
      category: {
        type: "string",
        enum: ["all", "clothing", "electronics", "books"],
        description: "Product category to filter by"
      }
    },
    required: ["query"]
  },
  execute: async (input) => {
    // Reuses your existing frontend search logic
    const results = await productStore.search(input.query, input.category);
    return { products: results, total: results.length };
  },
  annotations: { readOnlyHint: true }
});

That execute function is doing nothing exotic. It’s calling productStore.search, the same function your search bar already calls. WebMCP’s job isn’t to build new functionality, it’s to describe functionality you already built in a shape an agent can discover and invoke without guessing at your DOM structure.

The browser throws InvalidStateError if you register two tools with the same name, or if inputSchema doesn’t validate as proper JSON Schema, so the failure mode is loud and immediate rather than a silently ignored tool.

Where the call actually runs

This is the part worth sitting with. A server-side MCP server acts with its own credentials, a service account, an API key, something provisioned separately from any one user’s session. A WebMCP tool runs inside the page the user already has open, using whatever they’re already authenticated as. There’s no separate credential to provision or rotate, because there’s no separate service. The tool’s permissions are exactly the permissions that browser tab already has.

That’s a real security simplification for one class of problem (nothing new to lock down) and a real constraint for another (the tool can only do what the logged-in user is already allowed to do, in that session, from that tab). If you need an agent to act outside any specific user’s session, on a schedule, from a backend job, WebMCP isn’t the tool for that. Server-side MCP still is.

The Chrome origin trial, and a rename to watch for

Google announced the move from a behind-a-flag prototype to a public origin trial at I/O 2026, landing in Chrome 149 and running through Chrome 156. Origin trial means opt-in: a site registers a trial token, and users on Chrome 149+ with that token active get WebMCP support without needing to flip a flag themselves. You can also test it locally by enabling the WebMCP flags in chrome://flags.

One detail worth flagging if you’re prototyping against the current docs: Chrome 150 deprecates navigator.modelContext in favor of document.modelContext. If you’re writing code today against navigator.modelContext (as most current examples, including the one above, still do), expect a migration once you upgrade past Chrome 149. It’s a small change, but it’s the kind of thing that breaks a demo silently if you’re not watching the changelog.

Why the token-usage number matters more than the API itself

The API surface is straightforward. The actual case for adopting it shows up in cost and reliability. One early implementer who built a WebMCP layer reported up to a 90% reduction in LLM token usage compared to letting an agent scrape the rendered DOM. That tracks: a full page’s HTML, styling, and layout markup is enormous compared to a structured JSON response with exactly the fields a tool call needs. An agent that gets { products: [...], total: 12 } back from a tool call spends far fewer tokens than one that has to parse a rendered product grid out of a DOM tree, and it’s far less likely to misread a price or miss a button that moved between page versions.

That reliability point compounds. DOM scraping breaks every time you ship a CSS redesign that an agent wasn’t tested against. A registered tool with a stable schema doesn’t care what the page looks like, only that the function signature stays the same.

What to actually do with this today

WebMCP is origin-trial software, not a shipped standard. Treat it accordingly:

1. Prototype it on a low-stakes surface first. A search tool or a read-only lookup is a safer first WebMCP tool than anything that mutates state, both because readOnlyHint gives agents an explicit signal and because a read path failing is cheaper than a write path failing.
2. Don’t build a core user flow that depends on it exclusively. Origin trial APIs change. Build WebMCP as a progressive enhancement, agents that support it get a better path, everything else falls back to the page working the way it always has.
3. Watch the navigator.modelContext to document.modelContext transition if you start today, so a Chrome upgrade in your test environment doesn’t silently break your registered tools.
4. Keep your existing server-side MCP servers, if you have them, for anything that needs to run outside a specific browser session. The two patterns are complementary, not competing.

If you’re already investing in agent-facing infrastructure, worth talking to our team about which of your workflows actually belong client-side versus server-side, WebMCP makes that a real architectural decision now instead of a hypothetical one.