Chrome Ships WebMCP - Every Website Becomes an AI Agent Tool

Google shipped WebMCP as an early preview at I/O 2026, a proposed open web standard that lets websites expose structured tools to browser-based AI agents without DOM scraping or fragile visual automation.

Chrome Ships WebMCP - Every Website Becomes an AI Agent Tool

At Google I/O on May 19, Google shipped WebMCP as an early preview in Chrome, making it the first browser to natively support a standardized protocol for AI agent tool access. The experimental origin trial opens in Chrome 149. Gemini in Chrome will follow with WebMCP support shortly after.

If that sounds familiar, the name is intentional. WebMCP stands for Web Model Context Protocol, and it takes direct aim at the same problem Anthropic's MCP solved for desktop tools - but inside the browser, where agents have historically had to click and scrape their way through UIs never designed for machines.

TL;DR

  • Google shipped WebMCP early preview at I/O 2026 - origin trial launches in Chrome 149
  • Built with Microsoft under the W3C Web Machine Learning community group
  • Two APIs: Declarative (HTML form attributes) and Imperative (JavaScript via navigator.modelContext)
  • Nine major consumer brands - Expedia, Booking.com, Shopify, Target, Instacart - already testing it
  • Requires a visible browser tab; no headless support now

The Problem Agents Have With Websites

Current browser agents work through "actuation" - they read the DOM, infer what buttons and forms do, and simulate clicks and keystrokes. This works, but barely. Dynamic sites break it. React state changes confuse it. CAPTCHAs stop it. Even a minor CSS refactor can break a workflow that ran fine yesterday.

The root problem is that websites were never designed to be called as tools. They were designed for human eyes. So agents have to reverse-engineer intent from visual layout every single time.

WebMCP flips this. Instead of agents guessing what a site can do, the site tells them directly.

What WebMCP Changes

A WebMCP-enabled site registers named tools with explicit input schemas. An agent calls navigator.modelContext.getTools() and gets back a structured list: checkout, search_products, filter_results, along with the exact parameters each tool accepts and what it returns. No DOM interpretation. No fragile CSS selectors.

HTML code on a monitor showing web development Traditional browser agents parse HTML like this to infer site capabilities. WebMCP replaces that guesswork with explicit tool definitions. Source: pexels.com

Discovery and Tool Registration

WebMCP uses three mechanisms to connect agents with tools. Discovery lets agents enumerate available actions on any page. JSON Schemas define the exact input types each tool accepts - no guessing whether a date field wants ISO 8601 or MM/DD/YYYY. State management gives agents a shared view of current page context, so a multi-step checkout flow doesn't lose track of what just happened.

Tools are gated by a tools Permissions Policy that defaults to same-origin. Cross-origin iframes need an explicit allow="tools" attribute. This is a reasonable baseline for security, though it creates friction for sites with third-party checkout flows.

JSON Schema Control

Every registered tool ships a full JSON Schema for its inputs. That means an agent calling a flight search tool knows in advance that origin is a string, departure_date is an ISO 8601 date, and cabin_class must be one of ["economy","premium","business"]. Validation errors surface before any network call is made, not after the agent has already committed to a broken workflow.

Two APIs, One Protocol

Google shipped two complementary implementation paths. Which one you reach for depends on whether your site's toolable actions are already expressed as HTML forms.

Declarative API

The declarative path adds two attributes to standard HTML <form> elements: toolname and tooldescription. Everything else - input types, validation, submission - stays exactly as written. Zero JavaScript required.

<form toolname="search_flights"
      tooldescription="Search for available flights by origin, destination and date">
  <input name="origin" placeholder="City or airport code" required />
  <input name="destination" placeholder="City or airport code" required />
  <input name="departure_date" type="date" required />
  <button type="submit">Search</button>
</form>

The browser parses the existing form structure and exposes it as a typed tool automatically. For sites whose core flows live in forms - booking, checkout, search - this is a near-zero-cost migration.

Imperative API

The imperative path uses navigator.modelContext.registerTool() for dynamic interactions that don't map cleanly to HTML forms. This covers anything that requires JavaScript logic: fetching product data, managing cart state, triggering multi-step workflows.

navigator.modelContext.registerTool({
  name: "add_to_cart",
  description: "Add a product to the shopping cart by SKU",
  inputSchema: {
    type: "object",
    properties: {
      sku: { type: "string", description: "Product SKU identifier" },
      quantity: { type: "number", minimum: 1, default: 1 }
    },
    required: ["sku"]
  },
  execute: async ({ sku, quantity }) => {
    const result = await cartAPI.addItem(sku, quantity);
    return { cart_id: result.id, item_count: result.items.length };
  }
});

The execute handler runs in the page context, with full access to existing JavaScript APIs and auth state. No separate server infrastructure needed.

A developer writing code on a laptop Both WebMCP APIs let developers expose site features to agents using tools they already know - HTML forms and JavaScript functions. Source: pexels.com

How WebMCP Relates to Anthropic's MCP

The similarity in names isn't accidental, but the two protocols solve different problems. Anthropic's MCP is a general-purpose tool-calling protocol that connects AI models to desktop applications, file systems, APIs, and code execution environments. It runs over stdio or HTTP, works headlessly, and has broad adoption across dozens of client and server implementations.

WebMCP is narrower and browser-native. It handles the specific case of agents operating inside a visible browser context, with access to DOM state, cookies, and existing user sessions.

WebMCPAnthropic MCP
TransportBrowser-native APIstdio or HTTP
ScopeIn-browser agentsDesktop apps, APIs, files
AuthPermissions Policy (same-origin default)OAuth, API keys
DiscoveryLive page registrationServer manifest
Headless supportNoYes
Current statusEarly preview (Chrome 149)Broadly adopted
Backed byGoogle, Microsoft, W3CAnthropic, growing ecosystem

The two can work together. Chrome DevTools already ships an MCP server that exposes Chrome's debugging capabilities to external AI tools. WebMCP extends that into the page layer, where the content lives.

Who's Already Testing It

Google named nine consumer brands in the launch announcement: Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, and Target. That list covers travel, e-commerce, personal finance, real estate, and tax preparation - all categories where agents are already being rolled out but where DOM automation is notoriously brittle.

Shopify is the most interesting name on that list. The platform already ships an AI toolkit for agents and has been moving aggressively toward agent-native commerce. Adding WebMCP support to Shopify's storefront SDK would make every merchant on the platform agent-ready by default.

Requirements and Compatibility

RequirementDetail
Chrome version146+ (flag), 149 (origin trial)
Testing flagchrome://flags/#enable-webmcp-testing
Testing toolWebMCP Inspector extension (Chrome Web Store)
Permissions Policytools (default: same-origin)
Iframe supportRequires allow="tools" attribute
HeadlessNot supported
Gemini in ChromeComing after origin trial
Standard bodyW3C Web Machine Learning CG

Where It Falls Short

The headless restriction is the biggest practical limit right now. Most production agent pipelines run without a visible browser. WebMCP requires a live tab, which means running Chrome in windowed mode or using a remote debugging setup. That's workable for development but awkward for scale.

Same-origin defaulting is sensible for security but creates a real problem for checkout flows that run through third-party processors. Merchants using Stripe or PayPal can't expose those payment steps as WebMCP tools without the processor adding allow="tools" to their embedded iframes. That's a coordination problem that'll slow adoption in exactly the checkout context where agents most need reliable tooling.

The spec is still a community incubation. Moving to a formal W3C draft takes months, and browser vendors other than Chrome and Edge haven't committed to implementation. Building on WebMCP today means betting on Google's track record of shepherding web standards - which has had mixed results with anything requiring cross-browser buy-in.

And 51% of web traffic already comes from bots, mostly scrapers and indexers. Exposing machine-readable tool registries to any in-browser agent adds surface area that security teams will need to think through carefully, especially for tools that modify state.

The spec is young, the adoption list is real, and the underlying problem - agents guessing at sites built for humans - is the right one to solve. Getting from early preview to an actual standard is the hard part.


Sources:

Sophie Zhang
About the author AI Infrastructure & Open Source Reporter

Sophie is a journalist and former systems engineer who covers AI infrastructure, open-source models, and the developer tooling ecosystem.