WebMCP Explained: AI Agents Can Now Use Websites

AI agents have been stuck doing the digital equivalent of squinting at a screen and guessing where to click. WebMCP changes that. It is a proposed web standard that lets your site hand structured, typed tools to a browser AI agent directly, instead of forcing the agent to scrape screenshots and fake mouse clicks. It shipped as an origin trial starting from Chrome 149, and this guide covers what WebMCP is, how it differs from MCP, and how to try it in a few minutes.

WebMCP in one paragraph

So, what is WebMCP? It is a browser API that lets a web page expose JavaScript functions and annotated HTML forms to an AI agent as structured, typed tools. Rather than an agent taking a screenshot of your checkout page and trying to infer which button submits the order, your page declares a tool like "placeOrder" with typed inputs, and the agent calls it directly. The agent gets a reliable contract; you keep control over what it can and cannot do. It arrived as a public origin trial in Chrome 149.

The problem it solves

Today's browser agents interact with websites the way a person would, only worse. They screenshot the page, run vision models to locate elements, then simulate clicks and keystrokes. This "screenshot-scraping" approach is brittle:

• A minor CSS change or a moved button breaks the agent's guesses.
• Multi-step flows (search, filter, add to cart, checkout) compound the error rate at each step.
• The agent has no reliable idea what an action will do before it does it.

The result is slow, flaky automation that fails in ways that are hard to debug. WebMCP flips the model. Instead of the agent reverse-engineering your UI, your page tells the agent exactly which actions exist and what arguments they take. The agent stops guessing at pixels and starts calling functions with a known signature — the same shift that made APIs more reliable than screen-scraping in every other corner of software.

There is a second payoff for you as the site owner. Because you decide which tools to expose, you set the boundary of what an agent can do. Screenshot-driving gives an agent access to anything a user could click; a declared tool surface gives it access only to the actions you chose to publish.

WebMCP vs MCP: how they differ and work together

This is the comparison that dominates the search queries, so let's be precise. MCP, Anthropic's Model Context Protocol, connects an AI agent to external tools and data sources — a database, a filesystem, a third-party API. It is the wiring between an agent and the services it uses.

WebMCP is the in-page equivalent for web apps. It exposes tools that live inside the current website to an agent running in the browser. They are complementary, not competitors: MCP handles the agent-to-external-services link, while WebMCP handles the agent-to-this-page link. A single agent can use MCP servers for backend data and WebMCP tools for the site the user is currently on.

How it works: imperative vs declarative

WebMCP offers two authoring styles, so you can pick the one that fits your codebase.

Imperative JS API

You define tools as functions and register them with the agent. A rough sketch of the shape:

window.agent.provideContext({
  tools: [
    {
      name: "searchFlights",
      description: "Search available flights for a route and date",
      inputSchema: { /* typed parameters */ },
      async execute({ from, to, date }) {
        return await searchFlights(from, to, date);
      }
    }
  ]
});

The agent sees a typed tool with a name, description, and input schema, and calls execute with validated arguments.

Declarative HTML forms

If your app is form-driven, you can annotate standard HTML forms so the agent treats them as tools without extra JavaScript. A search form or a booking form becomes a callable tool by adding annotations, which means many existing pages can participate with minimal rewriting. The declarative path is the low-effort on-ramp; the imperative path gives you full control when a tool needs custom logic.

Because these method names come from an evolving origin trial, treat the exact API surface as provisional rather than final — expect it to shift before any stable release. The two-track design is deliberate: pick declarative when your interactions already map to forms, and reach for the imperative API when you need typed parameters, validation, or logic that a plain form can't express.

Chrome 149 origin trial: enable and test locally

You can experiment right now. Two paths:

1. Local testing. Enable the flag at chrome://flags/#enable-webmcp-testing, restart Chrome, and you can prototype WebMCP tools on your own machine before signing up for anything.
2. Origin trial. To test against real users, register your origin for the Chrome 149 origin trial and add the trial token to your pages. Origin trials are Chrome's mechanism for shipping experimental APIs to a real audience for feedback.

Start local, confirm your tool schemas behave, then move to the origin trial when you want live testing. When you inspect what your page exposes, a JSON formatter makes it easy to read the JSON tool schemas your page hands to the agent.

Security model: hints and human-in-the-loop

Handing an AI agent callable tools on your live site raises an obvious question: is WebMCP safe? The design leans on annotation hints so agents know how much to trust an action.

• untrustedContentHint flags data that came from an external or untrusted source, signaling the agent to be cautious with it.
• readOnlyHint marks operations that do not mutate state, so an agent can safely call them without asking a human first.

The intent, per Chrome's spec notes, is to let agents skip human confirmation only for safe, read-only actions while keeping a human in the loop for anything that changes data or spends money. This is a young security model on an experimental API, so do not treat these hints as a complete guardrail. Audit which tools you expose, and default to requiring confirmation for anything sensitive.

Who's already building with it

The early-adopter list skews toward commerce, travel, and finance — flows where reliable agent automation has obvious value. Companies named as experimenting include Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, and Target. Read that as "kicking the tires," not "shipped in production." These are trials of an experimental standard, and the list comes from third-party reporting rather than formal vendor announcements.

Standards status: W3C, Google, and Microsoft

WebMCP is not a Google-only effort. The spec is incubating in the W3C Web Machine Learning community group, with involvement from both Google and Microsoft, according to multiple reports. Google's Chrome team is reported to have confirmed on May 19, 2026 that WebMCP moved from a behind-a-flag prototype to a public origin trial in Chrome 149. That date comes via InfoQ's reporting rather than a direct primary post in our sources, so treat it as reported.

Community-group incubation matters because it signals an intent toward cross-browser interoperability rather than a single-vendor API. That is the path a proposal takes if it wants to become a real web standard.

Browser support timeline

Where things stand, with appropriate caveats:

• Chrome: origin trial live from Chrome 149.
• Firefox: support reportedly committed for Q3 2026.
• Safari: expected Q4 2026.

The Firefox and Safari dates are third-party reported, not confirmed by Mozilla or Apple directly. Plan around Chrome for now, and watch for official vendor statements before assuming multi-browser coverage.

Should you add WebMCP to your site yet?

A pragmatic verdict for web devs weighing whether to expose their app to agents:

• Experiment now if agent-driven flows are strategic for you (commerce, travel, booking, productivity) and you have capacity to track a moving API. The origin trial is the right time to learn the model and shape feedback.
• Wait if you need stability, run a small team, or can't commit to reworking your integration when the API changes. Origin-trial APIs can and do shift before they stabilize.

The honest risks: the API surface may change, browser support beyond Chrome is unconfirmed, and the security model is new. None of that is a reason to ignore WebMCP — it is a reason to prototype behind a flag rather than bet production on it today.

WebMCP is an early but genuinely different approach to the agentic web: your site describes what it can do, and the agent calls those tools instead of guessing at pixels. The models doing the calling matter too — if you want to know which ones are strongest at tool use, browse the AI models powering these browser agents and the best agentic models for tool use. Start local with the Chrome flag, read the schemas your page exposes, and treat the whole thing as the promising experiment it currently is.