WebMCP in Chrome 149: Give AI Agents an API to Your Site

AI agents are already browsing the web. Gemini Auto Browse, GitHub Copilot Workspace, and a growing list of autonomous tools visit websites, fill forms, and complete tasks on behalf of users. The problem is how they do it: screenshot the page, guess where the button is, click, wait, repeat. It’s slow, it breaks constantly, and your site has zero say in how it’s interpreted. Chrome 149 changes that. WebMCP — a proposed open web standard developed jointly by Google and Microsoft — just entered origin trial, giving you a way to declare exactly what your site can do for an AI agent. If you’re building anything that agents might touch, this is worth 10 minutes of your attention.

The Problem With How Agents Browse Today

Current browser automation for AI agents is structurally fragile. An agent trying to book a flight or submit a support ticket has to load the page, render it, interpret the DOM, locate the right fields by their visual position or CSS class names, and fire events — all while hoping nothing changed since the last visit. Each step burns tokens and time. A single task can require 5 to 10 DOM interactions where the agent is effectively guessing. Some succeed. Many don’t.

This is not a model problem. It’s an infrastructure problem. Your site doesn’t have a contract with agents the way it does with browsers (HTML/CSS) or server-side integrations (REST/GraphQL). WebMCP is that contract.

What WebMCP Actually Does

WebMCP lets you expose structured tools — JavaScript functions or annotated HTML forms — that AI agents can call directly from the browser. Instead of interpreting your UI, the agent reads your tool schema, sends structured inputs matching your JSON Schema definition, and gets a typed response back. One round trip. No DOM scraping. No visual guessing.

Think of it this way: your web app already has two user types — humans using the interface, and machines using your API. WebMCP adds a third: AI agents using your declared tools. If you don’t declare them, the agent improvises. That improvisation is what breaks.

Two APIs, One Standard

WebMCP ships with two complementary approaches. The declarative API is the low-effort path: add toolname and tooldescription attributes to your existing HTML forms, and you’re done. Any agent that understands WebMCP can now call that form as a structured tool without touching the DOM.

<form toolname="searchProducts"
      tooldescription="Search the product catalog by keyword">
  <input name="query" type="text" />
  <button type="submit">Search</button>
</form>

The imperative API gives you full control. Use navigator.modelContext.registerTool() to define tools with complete JSON Schema input definitions and async execute handlers — the same pattern you’d recognize from tool use in the Claude or OpenAI APIs, but running client-side in the browser.

navigator.modelContext.registerTool({
  name: "addToCart",
  description: "Add a product by SKU and quantity",
  inputSchema: {
    type: "object",
    properties: {
      sku: { type: "string" },
      quantity: { type: "integer", minimum: 1 }
    },
    required: ["sku", "quantity"]
  },
  execute: async ({ sku, quantity }) => {
    const res = await fetch("/api/cart/add", {
      method: "POST",
      body: JSON.stringify({ sku, quantity })
    });
    return { type: "text", text: JSON.stringify(await res.json()) };
  }
});

Chrome 149 DevTools now includes a WebMCP panel in the Application tab where you can list and manually execute registered tools — a convenient way to verify your implementation before opening it to real agents.

How to Get Started With the Origin Trial

Chrome 149 stable shipped on June 2, 2026. The origin trial is open now. Sign up at the WebMCP origin trial registration page to get a token for production traffic testing. For local development, enable the flag at chrome://flags/#enable-webmcp-testing — no registration needed.

The timing matters. Gemini Auto Browse for Android launches in late June and is explicitly designed to use WebMCP-exposed tools for tasks like appointment booking and product purchase. Sites with WebMCP tools will give agents a clean, reliable path. Sites without them fall back to DOM scraping — slower, less accurate, and more likely to fail mid-task.

WebMCP and MCP Are Not the Same Thing

Worth clarifying explicitly: WebMCP and Anthropic’s Model Context Protocol (MCP) solve different problems and are not competing standards. MCP is server-side — it connects AI agents to databases, APIs, and external services via JSON-RPC. WebMCP is browser-side — it exposes in-page interactions to agents running in the browser. Both use JSON Schema for tool definitions, making them composable. The recommended architecture: use MCP for backend data, WebMCP for what happens on the page. They’re layers, not alternatives.

Security Considerations Worth Understanding

Two attack vectors are worth understanding before you ship. First, malicious manifests: if your tool definitions reference third-party data in names or descriptions, a compromised upstream source could inject instructions that redirect the agent. Second, contaminated outputs: tool responses can carry injected instructions disguised as data. Google’s security guidance recommends treating all tool outputs as untrusted — WebMCP base64-encodes them by default — and using “spotlighting” to clearly demarcate data from instructions in agent prompts. Cross-origin tool access is blocked by default; use the exposedTo option in registerTool to explicitly whitelist origins. Agents are also required to pause and request user confirmation before purchases or social media posts.

Implement Early

WebMCP is experimental. Chrome and Edge only for now. The web standards process is deliberate, and cross-browser timelines are uncertain. Those are fair caveats.

Here’s the case for moving anyway: agents are browsing your site today. The ones that understand WebMCP will get a clean, reliable experience; the rest will guess. Two HTML attributes on your most-used form costs an hour. An origin trial registration takes minutes. The pattern WebMCP establishes — explicit, schema-driven tool surfaces on the client — will survive in some form even if the API changes. The sites that learn to think in those terms now will have a meaningful head start when this becomes the baseline expectation, the same way responsive design and accessibility compliance became non-negotiable after years of being “optional improvements.”