WebMCP Chrome 149 origin trial: what changed after Google I/O

In February, WebMCP looked like a Chrome Canary experiment.

WebMCP is a proposed browser standard that lets websites expose structured tools to AI agents. Since our February post, Google moved WebMCP from a Chrome 146 Canary preview into a Chrome 149 origin trial and tied it to Gemini in Chrome, DevTools for agents, auto browse, and reusable Chrome Skills.

Chrome's WebMCP documentation, published on May 18, 2026, says WebMCP is available behind a local Chrome flag today and will be available in an origin trial in Chrome 149.

If you want the original API walkthrough first, read our February primer: WebMCP turns your browser tabs into AI tools.

That matters because WebMCP changes what an open tab is.

Today a tab is mostly a page you read, search, save, close, or forget about. With WebMCP, a tab can also expose structured tools to an AI agent: search_products, submit_application, date_pick, run_diagnostics, checkout, filter_results. If the tab closes, those tools go away.

Why Google cares

Chrome has a lot to lose if agent work moves out of the browser.

If agents do most of their work through backend MCP servers, private APIs, or AI-native browsers, Chrome becomes less central to the workflow. WebMCP pulls agent action back into the browser: the page is open, the user can see what happened, and Gemini in Chrome gets a standard way to call site-provided tools.

That also explains why WebMCP showed up at I/O next to auto browse, Skills in Chrome, DevTools for agents, and built-in AI. Google is trying to make Chrome the place where agent work happens.

There is a search and commerce angle too. If agents shop, book travel, compare products, fill forms, and complete purchases, Google needs those flows to stay visible to Chrome, Search, ads, shopping, payments, and analytics. A WebMCP tool call is more structured than screenshot clicking. It is easier to inspect, mediate, attribute, and eventually govern.

WebMCP vs MCP

Classic MCP is persistent. You configure an MCP server once, and your agent can call it from anywhere. WebMCP is tab-bound: the website has to be open because the tool runs in the page's browser context.

Google's own WebMCP versus MCP guide frames WebMCP as frontend and tab-bound: it exists when the user has the website open, in the browser context, with the UI and session state available.

Question	Backend MCP	WebMCP
Where tools run	In a configured server or local process	In the open web page
Auth/session model	Server-managed tokens, OAuth, or local credentials	The user's current browser session
Discovery	Configured in the MCP client	Discovered after the page is open
Persistence	Available while the MCP server runs	Available while the tab or webview is open
Best fit	Developer tools, databases, files, internal systems	Website actions that need page UI, cookies, or user-visible execution

That creates a new operational problem.

If tools only exist while pages are open, then the user's open-tab set becomes part of the agent runtime. Close the wrong tab and a capability disappears. Leave too many tabs open and the agent surface gets noisy. Keep duplicate tools open across several sites and the agent has to decide which one should act.

Why technical users should care

WebMCP gives sites a declared API for agent actions, instead of forcing agents to infer actions from the DOM.

Instead of an agent guessing that a calendar widget means "pick a date," the site can register a date_pick tool. Instead of trying to scrape a settings page, the app can register run_diagnostics. Instead of interpreting a complex form visually, a page can expose a schema with the exact fields it expects.

Chrome's docs describe JavaScript registration for imperative tools, HTML annotations for forms, JSON Schema for inputs, and visible page execution so users can see what happened.

For developers and power users, that opens up a new browser workflow:

• Which of my current tabs are agent-ready?
• Which tabs expose read-only tools versus tools that can modify state?
• Which tools are duplicated across open tabs?
• Which project window has the tools my agent needs right now?
• Which tabs should stay open because an agent can call tools from them?

WebMCP Chrome 149 origin trial: what changed since February

Our February WebMCP primer was about a new browser API in Chrome Canary. The practical takeaway was simple: a page could register tools, an inspector extension could see them, and the W3C draft was worth watching.

Google I/O changed the context around it.

Chrome's I/O post put WebMCP inside a larger browser-agent push. Google said the WebMCP origin trial starts in Chrome 149, that Gemini in Chrome will support WebMCP APIs, and that consumer brands are already experimenting with it. The same I/O post also announced Modern Web Guidance, Chrome DevTools for agents, auto browse in Gemini in Chrome, and reusable Skills in Chrome.

Those pieces matter together:

• WebMCP gives sites a way to expose page actions as tools.
• Gemini in Chrome gives those tools a likely first-party agent client.
• DevTools for agents gives developers a way to test WebMCP tools in a real browser.
• Skills in Chrome lets users save repeatable multi-tab prompts.
• Auto browse points at agents taking actions across websites after the user asks for a task.

That is a different story from February. WebMCP is no longer just "here is a proposed API." It is now one part of Google's browser-agent stack.

What is still missing now

The missing pieces we called out in February are still relevant, but the details changed.

Duplicate tools across tabs. The spec now gives browser agents more structure. Tools are exposed through page observations and grouped by document, so an implementation can tell which document a tool came from. That helps inside a page. It does not fully answer the user question: if two open tabs expose search_flights, which one should the agent call?

Pre-visit discovery. Chrome now uses "discovery" to describe pages registering tools in a standard way. That is useful once the page is open. It is different from knowing what tools a site has before visiting it. There is still no .well-known/webmcp, site manifest, directory, or search index for agents to query ahead of time.

Prompt injection and trust. This changed the most. The current spec has a full security and privacy section covering tool-description poisoning, output injection, misleading tool intent, privacy leakage, and same-origin risks. It also defines early signals like readOnlyHint and untrustedContentHint. But the hard part remains: an agent cannot prove that a tool's natural-language description matches what the code will actually do.

The browser state problem

There is still a constraint that matters for people who work with many tabs: WebMCP tools are tied to browsing context.

Chrome's WebMCP docs say a browser tab or webview must be open because tool calls run in JavaScript with a visible interface. They also say clients and browsers must visit a site directly to know whether it has callable tools. The WebMCP versus MCP guide makes the same distinction another way: MCP is available on any platform; WebMCP is available only on the website.

That means WebMCP tools are not like a backend MCP server you configure once and forget. They appear because a tab is open. They disappear when that tab closes. Two open tabs can expose similar tool names. A shopping tab, a staging admin tab, and a production admin tab may all expose state-changing tools, but they should not be treated the same.

For developers, that creates a new debugging question:

• Which tabs currently expose WebMCP tools?
• Which one is the agent about to call?
• Is this the staging tab or the production tab?
• Did the tool disappear because the tab was archived, closed, discarded, or navigated?
• Are there duplicate tool names across windows?

Chrome's inspector answers this inside one page. DevTools for agents helps build and test the tools. The missing layer is cross-tab inventory.

What to watch next

The next useful milestone is Chrome 149 origin-trial behavior in real extensions. Chrome has already shown that a site can register tools. The open question is whether a user-level tool can safely see enough metadata across tabs to help people manage the agent surface without becoming another risky automation layer.