Accelerating the Autonomous Web with WebMCP

Roadshow schedule

Why agents struggle with websites

Agents have to read an interface built for people and work out how to operate it. People now hand agents whole jobs, such as finding a hotel or working through a support ticket, and much of that work happens on websites. An agent on a site runs a loop: read the page, decide the next step, act, then read the page again to see what changed. The talk illustrates the loop with WebVoyager, a research agent that completes tasks on real websites.

Reading the page is the step everything else depends on. Agents do it in one of three ways, or a mix of them:

• Screenshots. The agent looks at the rendered page and infers its structure from layout, colour and text.
• The DOM. The agent reads the page's full markup.
• The accessibility tree. The browser's condensed, semantic summary of the page, which is what screen readers use.

Any of these can work on a single page. Real tasks span many. The talk's example is booking a hotel for the conference: search for Tokyo, add a price limit and amenities, compare the results, open one. The agent has to keep track of what it read on every page for the whole task, and a less capable model, or the software driving it, loses the thread.

Agent-ready without a new API

Most of this work already helps people. The talk recommends four habits:

• Make actions visible. A control that does something should look like it, with an obvious button and a pointer cursor.
• Keep the layout stable. A page that shifts under the agent makes it reason about the page again, and weaker agents get that wrong.
• Do not hide controls. A search field that appears only after a click, or a next step that appears only on hover, is easy for an agent to miss.
• Use semantic HTML. A <button> or <a> tells the agent something is actionable, and the browser makes it focusable and keyboard-operable at no cost. <nav>, <header> and <footer> tell it what each region of the page holds.

Semantic HTML is the backbone of accessibility, so a site that works well with a screen reader is most of the way to working well with an agent. Both depend on a page that states plainly what is on it and what can be done there. A site does not need a separate path built only for AI to get this benefit.

WebMCP

WebMCP is a proposed web standard for exposing structured tools to AI agents, developed in the W3C Web Machine Learning Community Group. A site registers tools, each with a name, a description and a schema for its inputs, and an agent calls them directly instead of working through the interface.

Take the hotel site again. Rather than finding the search box, typing and reading the results page, the agent calls search_location with a city, then filter_search_results with a maximum price and a list of amenities. Each tool runs the search and filter code the site already has, and the person watching sees the same page update. The tools on offer can change with the page: a search page offers search, and a results page offers filters and a reset.

There are two ways to define a tool:

• The imperative API. Register a tool in JavaScript with document.modelContext.registerTool(), passing a name, a description, an input schema and an execute function that calls your existing code. Optional annotations such as readOnlyHint describe what the tool does.
• The declarative API. Add attributes to an HTML form you already have. By default the agent fills in the form and the person submits it; adding toolautosubmit lets the agent submit it as well.

The declarative example from the talk is a normal search form with three extra attributes:

<form toolname="searchHotels" tooldescription="Search hotels by city">
  <label for="city">City</label>
  <input id="city" name="city" required toolparamdescription="Destination city">
  <button type="submit">Search hotels</button>
</form>

WebMCP and MCP

MCP, the Model Context Protocol, connects agents to tools that run in a server or a local process. WebMCP puts tools inside the web page, where they exist only while the page is open and act on the interface the person can see.

The two sit side by side. A site can offer WebMCP tools without building a separate backend for agents, and existing browser automation keeps working on pages that offer no tools.

Browser support

WebMCP is still experimental. As of September 2026:

• Chrome offers WebMCP through an origin trial, starting in Chrome 149.
• Microsoft Edge runs its own origin trial, which expires on 17 November 2026.
• Mozilla is neutral on the proposal.
• WebKit opposes the current proposal.

A browser exposing the API is a separate question from an agent using it, so test the combination you care about. Feature-detect document.modelContext, keep the regular interface working when it is missing, and report the failures you can reproduce to the people working on the proposal.

Getting started

Chrome's WebMCP documentation, linked in the sources, covers both APIs and the origin trial. Our own browser agent, Auto Browser, calls a page's WebMCP tools when the page offers them and reads the accessibility tree when it does not, so you can use it to try your own tools with an agent.