WebMCP in Chrome 149: Make Your Site AI-Agent Ready Now

Chrome 149's WebMCP origin trial is now open for registration, and Microsoft Edge 147 has shipped native WebMCP support by default. WebMCP is a client-side protocol that allows websites to declare what AI agents can do with them in structured, machine-readable terms, enabling faster and more reliable agent interactions compared to vision-based approaches. Developers can adopt it with minimal effort using HTML attributes or JavaScript APIs.

Chrome 149’s WebMCP origin trial is now open for registration. Microsoft Edge 147 has already shipped native WebMCP support by default, no flags required. If you have not heard of WebMCP yet, the short version is this: your website can now declare exactly what AI agents are allowed to do with it — in structured, machine-readable terms — instead of leaving browser agents to squint at screenshots and guess. That is the change. It is more significant than most of the AI tooling news from the past several months, and it requires zero backend infrastructure to adopt. What WebMCP Actually Is WebMCP is a client-side protocol. It runs inside the browser tab, not on a server. Through the navigator.modelContext API, a page registers tools — JavaScript functions and annotated HTML forms — that a browser-resident AI agent can invoke directly. The agent operates under the user’s existing session, with the user’s cookies, authentication, and permissions already in place. You do not wire up new OAuth flows. You do not expose new API endpoints. That distinction matters. Server-side MCP — the Anthropic-originated standard that has become the dominant agent-to-backend protocol — connects agents to databases, files, and external APIs via JSON-RPC. It is the right tool when your agent needs to query a Postgres database or read from an internal knowledge base. WebMCP handles something server-side MCP cannot: the live state of a browser tab. The form a user has half-filled out. The product inventory a React component just fetched from your CDN. The checkout widget sitting in the current DOM. That is WebMCP territory. Vision-based agents — the kind that read your page like a screenshot and try to click the right thing — can also do this, but they are slow, fragile, and break every time you change a CSS class. Early benchmarks show WebMCP-enabled pages completing the same tasks 8 to 12 times faster than vision-based agents on equivalent pages. That is the performance gap you are currently giving away for free. The Declarative API: Two Attributes and You Are Done The fastest path to WebMCP compliance is the Declarative API. You add HTML attributes to an existing form element. The browser reads them, builds a JSON Schema from the field types and constraints already present, and registers the tool internally. No JavaScript required for the basic case. <form toolname="contactSupport" tooldescription="Send a message to the support team." <input name="email" type="email" required <textarea name="message" required </textarea <button type="submit" Send</button </form The required attributes are toolname the identifier agents use to call this tool and tooldescription the natural-language hint that tells an agent when to invoke it . You can add toolparamtitle and toolparamdescription to individual fields for better agent comprehension, and toolautosubmit to let the agent submit the form automatically after filling it. If you have forms on your site today, you can ship WebMCP support with two attributes and a deploy. The Imperative API: For SPAs and Anything Async React apps, Vue apps, anything that does not reduce cleanly to an HTML form submit needs the Imperative API. You call navigator.modelContext.registerTool directly in JavaScript with a full tool definition and an async handler. navigator.modelContext.registerTool { name: "getProductInventory", description: "Returns real-time inventory status for a product SKU.", parameters: { type: "object", properties: { sku: { type: "string", description: "The product SKU to check." } }, required: "sku" }, handler: async { sku } = { const result = await fetch /api/inventory/${sku} .then r = r.json ; return result; } } ; The handler is async and returns whatever the agent should receive — structured data, status objects, error messages. You control the contract entirely. A single page can register multiple tools mixing both APIs. Who Has Already Shipped This Google announced the Chrome 149 origin trial partners at Google I/O 2026. The list includes Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, and Target. These are not beta experiments. Shopify has already published data showing that AI-powered searches against structured catalog data convert at twice the rate of searches using scraped web content. The commerce case for WebMCP is already empirically validated. Microsoft Edge 147 shipped native WebMCP support by default — not an origin trial, not a flag, just on. The W3C Web Machine Learning Community Group https://www.infoq.com/news/2026/06/webmcp-web-agent-standard-chrome/ is incubating the spec with both Google and Microsoft participating. This is a cross-browser standard from the start, which is the response to anyone who wants to call it another abandoned Google web experiment. Before You Ship: Security and Caveats HTTPS only. WebMCP requires a SecureContext. It will not initialize on HTTP pages. Same-origin by default. Cross-origin iframes cannot register tools unless the parent page explicitly grants permission via allow="tools" on the iframe element. Individual tools can be scoped to specific origins using the exposedTo array in registerTool . Edge 147 users do not need origin trial registration. If you are comfortable targeting Edge-first, you can test without a Chrome origin trial token. The spec is a Community Group Draft, not a finalized standard. The API can change before general availability. Write against it, but keep your fallback behavior. To join the Chrome origin trial, register at the Chrome for Developers origin trial page https://developer.chrome.com/blog/ai-webmcp-origin-trial , add the issued token to your pages, and you are in. The official WebMCP documentation https://developer.chrome.com/docs/ai/webmcp covers the full API surface. The comparison guide between WebMCP and server-side MCP https://developer.chrome.com/docs/ai/webmcp/compare-mcp is worth reading if you are already running MCP servers and need to decide where the boundary sits. The Actual Implication The parallel to draw here is mobile responsiveness circa 2014. It was technically optional. It was clearly the direction things were going. Sites that moved early got indexed better, experienced less friction, and did not have to scramble later when it became a ranking signal. WebMCP is in the same position. AI agents are already mediating a meaningful share of web interactions for tasks like booking, shopping, and support. Sites that tell agents exactly what they can do will be preferred. Sites that do not will be accessed via slower, dumber scraping. There is also a stronger claim available: WebMCP may make server-side MCP redundant for purely web-native tools. If your product runs in a browser and its functionality is expressed through forms and JavaScript, you do not need to stand up an MCP server. You annotate the page. The infrastructure cost drops to zero. The origin trial is open. Edge 147 is shipping it now. The window to be early is still open — but not for long once the spec hits general availability.