The agent-ready web: Simplify user actions with WebMCP

Buying two concert tickets should not require reverse-engineering a website. Tara Agyemang, introducing herself as a developer relations engineer on Google’s Chrome team, starts with a concert site she built: BeatDrop. A user opens Gemini in Chrome beside the site and asks for two tickets to the Afrobeats Festival. The goal is straightforward; discovering how to carry it out is the expensive part.

An agent might parse the entire DOM, inspect the accessibility tree, and take a screenshot to understand elements those representations did not resolve. It then has to locate the target, work out where to click and perform the action. After all that inference, an advertisement can finish loading at the top of the page, push the content downward and invalidate the calculated coordinates. Agyemang describes the process as brittle and potentially token-heavy, without measuring its token cost.

The first improvements are ordinary web engineering: semantic HTML, robust accessibility, fast page loads, attention to Core Web Vitals and clear user journeys. These make the site easier for people to use and give agents a better representation to work with. WebMCP builds on those foundations. It does not remove the need for them.

Web Model Context Protocol, or WebMCP, is a proposed web standard for describing a site’s capabilities as structured tools. Instead of making the agent infer which combination of controls performs an action, the site supplies a menu of available actions. Agyemang invokes the USB-C analogy: a common interface through which agents can discover what a website supports. She reports improved performance and reliability, but supplies no numerical benchmark or measured token reduction. The mechanism is the important part here: an explicit action contract reduces the work of interpreting the interface.

Chrome DevRel’s Maze Escape makes that contract visible. The Model Context Tool Inspector runs in a Chrome extension side panel and lists the tools exposed by the current page. It offers both natural-language prompting and direct tool invocation; this demonstration uses prompting. The Inspector is a development extension, separate from the Gemini in Chrome panel in the opening example.

The maze is deliberately unusual: clicking around its UI cannot navigate it. It is controlled through AI tooling. Initially, the Inspector discovers only the tool for starting a maze game. With Gemini 2.5 selected, Agyemang asks to start a game. The agent calls the start tool, receives its result and uses that returned information to compose a response. A maze appears on the page.

Starting the game also changes the available tools. The new page exposes movement in the north, south, east and west directions; inspection of the current location and open directions; and tools to pick up, drop and use items. The available actions follow the current page’s state. An agent does not have to work from one global, unchanging list of everything the application might do.

A request to move down and then right becomes calls to the movement tool with the corresponding cardinal directions: south, then east. The next example uses shorthand, including R, which the agent interprets as right before calling the same tool. Natural language supplies the intent; the tool supplies a constrained way to act on it.

A broader instruction—“Complete the maze”—lets the agent repeatedly choose among movement and item tools. But explicit tools do not automatically produce a good plan. Agyemang observes that this prompt can send the agent backward to the start before it moves forward again. Supplying the location of the exit, in the bottom-right corner, gives it a more useful direction. She stops the demonstration before the maze is completed because traversal can take a while, then points viewers to the Inspector’s Chrome Web Store listing.

Most websites will not resemble an agent-only maze. A user may browse normally, delegate a complicated sequence to an agent, and then take control again. WebMCP supports that shared workflow: the agent acts in the browser where the user is already working, rather than requiring the user to abandon the site’s interface.

Agyemang presents MCP and WebMCP as complementary. Her server-side shorthand for MCP needs one qualification: an MCP server is a program that can run locally or remotely. WebMCP borrows the tool concept for a web-native API; it does not adopt the full MCP wire protocol. Her JavaScript/Java analogy is about inspiration, not protocol compatibility.

For WebMCP, the tools live in the browser and the relevant page must be open. That makes the page’s current context central to what an agent can do.

This is useful wherever a user’s goal otherwise expands into many small interactions:

• Booking: complete the steps involved in finding and booking a flight.
• Shopping: apply product filters and select options.
• Forms: help fill complicated medical or financial forms.
• Hard-to-find actions: invoke fixes whose controls are hidden on a page.

The shopping example is specific: find a black faux leather clutch bag large enough to hold a mobile phone. Instead of making the user translate that request into individual fields and checkboxes, the agent can perform those interactions on the user’s behalf.

WebMCP proposes two implementation approaches. The declarative API starts with a standard HTML form: add toolname and tooldescription, and the browser generates a JSON schema whose parameters come from the form fields. The form already describes the inputs; the extra metadata tells the agent what the action means and when to use it.

The talk also introduces agentInvoked as a way to distinguish agent involvement. More precisely, the declarative API defines it as a Boolean property on SubmitEvent, indicating agent-triggered submission. It is not an HTML attribute that records who filled every field. For ordinary forms, the declarative approach keeps the tool definition close to the interface that people already use.

For more complicated or multistep UI flows, the imperative API lets the application register its own tools. registerTool receives an object containing a name, description, manually authored input schema and execution function. The description matters because the agent uses it to decide when to call the tool—not merely to label it in a list.

The execute function runs ordinary JavaScript. It can be a light wrapper around functions the application already uses. In the talk’s addTodoItem example, execution validates and trims the input, creates DOM nodes and adds the item to the page. The following version expresses that pattern using the imperative API documented in August 2026, with document.modelContext.registerTool; it is not a transcription of the earlier slide.

const list = document.createElement('ul');
list.setAttribute('aria-label', 'Todo items');
document.body.append(list);

document.modelContext.registerTool({
  name: 'addTodoItem',
  description: 'Add one non-empty task to the visible todo list.',
  inputSchema: {
    type: 'object',
    properties: {
      text: { type: 'string', description: 'The task to add.' }
    },
    required: ['text'],
    additionalProperties: false
  },
  execute: async ({ text }) => {
    if (typeof text !== 'string' || !text.trim()) {
      throw new Error('Task text must not be empty.');
    }

    const task = text.trim();
    const item = document.createElement('li');
    item.textContent = task;
    list.append(item);

    return {
      content: [{ type: 'text', text: `Added task: ${task}` }]
    };
  }
});

The same operation changes the visible list and returns an outcome to the agent. That returned information lets the agent determine what happened and choose its next step; changing the DOM alone would leave that feedback implicit.

Agyemang expects the imperative approach to be the more commonly used option because many applications have workflows more complex than a standard form. The practical choice follows the existing interaction: expose a form declaratively when it already captures the action, or register a custom tool when the application needs to coordinate more behavior.

Back on BeatDrop, the site now exposes tools alongside its featured events, full event listing and individual concert pages. Agyemang selects Gemini 3.1, saying it has worked better for this particular demo in her experience. This time the request is for two VIP tickets to the Summer Vibes Festival.

The agent carries the request across page boundaries:

1. searchConcerts searches by the concert name and returns information including the concert ID.
2. openConcertPage takes that returned ID and opens the Summer Vibes Festival page.
3. The new page exposes a purchase tool, described in the narration as purchaseTicket. The agent calls it with quantity 2 and the VIP section.

The demo displays a purchase notification reporting £356 spent. Agyemang jokes about putting it on Google’s credit card; this is the demo’s reported outcome, not evidence of a real payment.

Tool calls must keep the visible UI synchronized. The user can see the concert page open, VIP become selected and the quantity update. For a real purchase, Agyemang recommends handing the final checkout step back to the user so they know they are spending money. Preparing a purchase and authorizing payment should remain distinguishable in the interface.

The recording presents WebMCP in early preview, with an API changing quickly enough that the displayed code might differ the following week. The purpose of trying it is to discover useful interaction patterns and report where the API gets in the way.

Agyemang’s setup sequence is:

1. Use a separate Chrome Canary installation for experiments. She gives Chrome 146 and later as the browser baseline at the time of the talk.
2. Enable the WebMCP testing flag through the browser’s flags interface.
3. Install Model Context Tool Inspector to discover, invoke and debug the page’s tools.

Those historical requirements differ from the August 2026 setup: the current Chrome guide describes an origin trial beginning with Chrome 149, while Inspector version 1.9.13 requires Chrome 150.0.7861.0 or later. The Inspector also warns that it lacks production security boundaries, so use it only on trusted sites.

The early-preview announcement is the entry point Agyemang recommends for program signup, initial documentation, best practices and API details. The WebMCP tools repository contains the Inspector, the maze source and other demos. She describes roughly six or seven demos at the time, plus an evals CLI for testing a site and its exposed tools. The next step is to exercise those tools against real user goals, then report friction and bugs so the API can improve before reaching more users.

Agents are already using the web. Making them repeatedly reconstruct actions from screenshots and page structure need not be the only interface available. WebMCP’s ambition is to let a website function as a high-performance API for agents while preserving a useful, visible experience for people. The invitation is to make the site’s capabilities explicit, try them with an agent, and keep the person’s experience central as those actions become easier to delegate.