WebMCP lets your website hand AI agents a proper set of tools

Agents are already browsing your site

At Google I/O in May 2026, Chrome described Gemini in Chrome as running on desktop, iOS and now Android, with auto browse carrying out multi-step tasks for people: compare these, fill that in, book the next free slot. Other assistants do the same in their own browsers. Some of the visitors to your booking form are no longer looking at it with eyes.

Today those agents mostly work from what they can see. They take a screenshot or read the page structure, decide which box is the date field, type, look again, and hope the custom date picker behaves. It works surprisingly often, and fails in exactly the places that matter: the step that takes payment, the dropdown built from divs, the button that only appears after a scroll.

What WebMCP is

WebMCP is a proposed web standard that lets a page register structured tools for agents running in the browser. A tool has a name, a plain-language description, a JSON Schema for its inputs, and a function that does the work. The agent reads the list of tools a page offers and calls one, much like a developer calls an API.

The name nods to the Model Context Protocol, the way many AI apps already connect to tools, but the difference matters: WebMCP runs inside your web page, in the visitor's own browser, with the visitor there. There is no separate server to run, and the tool executes with the same session and permissions the person already has on your site. The Chrome team says it is designed for that human-in-the-loop case first.

The easy way: describe the form you already have

The declarative API is two required attributes on a form, toolname and tooldescription, plus an optional toolparamdescription on any field that needs explaining. The browser turns the form's fields into the tool's input schema. Hover a field to see what an agent is handed.

{
  "name": "book_table",
  "description": "Book a table for a date,
     time and party size.",
  "inputSchema": {
    "properties": {
      "date":   { "type": "string" },
      "time":   { "type": "string" },
      "guests": { "type": "number" },
      "name":   { "type": "string" }
    }
  }
}

<form toolname="book_table"
      tooldescription="Book a table for a date, time and party size."
      action="/reservations" method="post">
  <label>Date
    <input type="date" name="date" required
           toolparamdescription="The day of the booking">
  </label>
  <label>Guests
    <input type="number" name="guests" min="1" max="12" required
           toolparamdescription="How many people, from 1 to 12">
  </label>
  <label>Name <input name="name" required></label>
  <button>Book a table</button>
</form>

When an agent fills and submits the form, the submit event tells you so: SubmitEvent gains an agentInvoked flag and a respondWith() method, so you can send the agent a useful answer instead of a page it has to read. Two new CSS pseudo-classes, :tool-form-active and :tool-submit-active, let you show visitors when an agent is working on a form. By default the agent fills the fields and the person presses the button; a toolautosubmit attribute lets the agent submit as well.

form.addEventListener('submit', e => {
  if (!e.agentInvoked) return;
  e.preventDefault();
  e.respondWith(
    book(new FormData(form)).then(r => `Booked for ${r.guests} at ${r.time}.`)
  );
});

The flexible way: register tools in JavaScript

Not every useful action is a form. The imperative API registers tools on document.modelContext with registerTool(). It suits single-page apps, search boxes, filters and anything that only makes sense in a certain state, because a tool can be registered when it becomes useful and removed with an AbortController when it stops being useful.

const controller = new AbortController();

await document.modelContext.registerTool({
  name: 'check_order_status',
  description: 'Look up the delivery status of an order by its number.',
  inputSchema: {
    type: 'object',
    properties: {
      order: { type: 'string', description: 'The order number, like CH-1042' },
    },
    required: ['order'],
  },
  annotations: { readOnlyHint: true },
  execute: async ({ order }, { signal }) => {
    const res = await fetch(`/api/orders/${encodeURIComponent(order)}`, { signal });
    const { status, eta } = await res.json();
    return `Order ${order} is ${status}, arriving ${eta}.`;
  },
}, { signal: controller.signal });

// When the tool no longer makes sense on this page:
controller.abort();

Annotations tell the agent how careful to be. The Chrome docs list readOnlyHint for tools that change nothing, consequentialHint for tools with real effects such as a purchase, and untrustedContentHint for results that contain text from other people, such as reviews. Both APIs sit behind a tools permissions policy that defaults to your own origin, so a cross-origin iframe only gets tools if you allow it.

How to try it today

1. 01
   Turn on the flag

   In Chrome, open chrome://flags/#enable-webmcp-testing, set it to Enabled and relaunch.

2. 02
   Install an inspector

   The Chrome team publishes a Model Context Tool Inspector extension that lists the tools a page registers and lets you call them by hand.

3. 03
   Annotate one form

   Start with the form that earns you money: bookings, enquiries, quotes. Write the description the way you would brief a new colleague.

4. 04
   Join the origin trial

   From Chrome 149, register for the WebMCP origin trial to switch it on for real visitors on your domain.

What I would expose first

My view, for a small business site: start with the two or three actions a person would ask an assistant to do for them, and make them honest and boring.

Anything that spends money should carry consequentialHint and keep a visible confirmation step. The point is to make your site easier to use correctly, not to remove the person from decisions that are theirs.

Also from Chrome at I/O 2026

• The Prompt API is stable from Chrome 148, so pages can run prompts on the built-in model, alongside the Summarizer, Translator and Language Detector APIs that shipped in Chrome 138.
• The Soft Navigations API is coming, so single-page apps get proper Core Web Vitals for each route change.
• Chrome DevTools for agents lets coding agents drive and debug Chrome, and DevTools' own AI assistance can now read Lighthouse data.