WebMCP: Turn Your Website Into Agent Tools

Since Chrome 149, Google has been running a public origin trial for WebMCP — a proposal that lets a page declare its own tools to AI agents instead of forcing them to guess at the interface. The Chrome documentation went live on May 18, 2026 and was updated on June 9, and on May 5 Lighthouse shipped a new set of "agentic browsing" audits, one of which flags any <form> that carries no agent-readable description. The spec itself is developed inside the W3C Web Machine Learning Community Group, and its entry point has already moved from navigator.modelContext to document.modelContext.

The problem: the agent guesses, the product pays

Agentic browsing today is screenshot, scrape the DOM, click and hope. That works in a demo and falls apart in production: rename a class, add a conditionally rendered field, insert one extra verification step, and the whole path breaks. Worse, it fails silently — the agent reports a booking as completed while the form was never submitted.

The irony is that the application already knows exactly what it can do: add to cart, search a flight, book a table. The knowledge lives in the code. There has simply been no standard way to export it.

What changed: the page declares its tools

WebMCP inverts the direction. Instead of inferring intent from pixels, you register tools explicitly — name, description, input schema, execute function — and the browser exposes them to the agent in a structured way. The logic stays in the page, permissions stay inside the user's session, and the interface stays under your control.

The imperative path:

const controller = new AbortController();

document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string", description: "The text content of the todo item" }
    },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return {
      content: [{ type: "text", text: `Added todo item: "${text}" successfully.` }]
    };
  }
}, { signal: controller.signal });

Note the signal. Aborting the controller unregisters the tool, which makes binding registration to a React or Vue component lifecycle straightforward — no manual cleanup bookkeeping.

And a declarative path with no JavaScript at all

Most of what agents care about is already a form. So the spec supports a declarative style built on HTML attributes:

<form toolname="supportRequestTool"
      tooldescription="Submit a request for support."
      action="/submit">
  <label for="firstName">First Name</label>
  <input type="text" name="firstName" id="firstName">

  <select name="select" required
          toolparamdescription="Determines what team this request is routed to.">
    <option value="Customer happiness team">Return my purchase.</option>
    <option value="Distribution team">Check where my package is.</option>
  </select>

  <button type="submit">Submit</button>
</form>

Three attributes: toolname and tooldescription on the form, toolparamdescription on the fields whose meaning is not obvious. When they are missing, the browser falls back to the associated <label> or aria-description.

Where the payoff shows up first

The clearest wins are in e-commerce and booking: searching a product by compound criteria, tracking a shipment, starting a return, reserving a slot. These are long flows full of conditional fields, and they are exactly what breaks under guess-and-click automation. Describing them as explicit tools turns the agent's experience from guesswork into a call with a knowable success or failure. There is a side benefit too: writing an honest tooldescription forces you to state precisely what a form is for — an exercise that usually surfaces ambiguity the human user was suffering through as well.

Caveats worth taking seriously

• Still a trial. The API is under active discussion and has already changed. Treat it as progressive enhancement, not a dependency.
• No headless. It requires a real browser tab or webview, documents must be origin-isolated, and access is gated by a tools Permissions Policy.
• Submission is not automatic. The user still clicks Submit unless you deliberately add toolautosubmit — a good default for anything consequential.
• A tool is not a security boundary. Everything you register runs with the current user's privileges. This is closer to designing a public API than to adding a button: validate inputs, and demand explicit confirmation before a purchase or a delete. The broader question of authenticating agents is covered in MCP and agent authentication.

Takeaway

The web spent thirty years describing itself to humans and to search engines. WebMCP is the first serious attempt to describe it to agents with the same clarity. It does not replace the developer — it multiplies the interface the developer already built, because product intent becomes explicit instead of inferred. The cheapest place to start: add toolname and tooldescription to your single most important form, run the new Lighthouse audit, and watch what the score tells you.

Primary sources: WebMCP on Chrome for Developers and the W3C Web Machine Learning CG spec repository.