Chrome's WebMCP lets websites expose structured actions to AI agents

Websites may soon advertise actions, not just pixels

AI agents can already drive a browser: they read page text, walk accessibility trees and click whatever looks tappable. According to a post on dev.to, that approach forces agents to reverse-engineer interfaces designed for human eyes. WebMCP, an emerging Chrome capability currently available as origin-trial technology, proposes an alternative: a website declares the actions it supports as structured tools, and an agent invokes them with typed arguments instead of guessing which button completes a booking.

Why screen-driven automation is brittle

A person looking at a "Continue" button understands it advances a checkout. An agent has to infer that meaning from surrounding labels and interface state. The dev.to post lists the ways this breaks: labels change, responsive layouts move controls, a modal covers the next step, the page renders differently for another account, an A/B test reshapes the interface, or an action carries a side effect the label never reveals. A tool with a name, description, input schema and defined result gives both the browser and the agent a clearer contract.

Two ways to register tools

The declarative API targets ordinary HTML forms. A developer annotates a form with attributes such as a tool name and description, and the form's existing controls become the tool's parameters. The post stresses progressive enhancement: the form keeps working normally for people and for browsers without WebMCP support.

The imperative API covers actions that don't map to a single form. Application JavaScript registers a tool with a JSON schema and an execute function — the example given is a checkOrderStatus tool that takes an orderId and queries the same API the normal interface uses. Implementations should call the same trusted application layer as the human-facing UI; the author frames WebMCP as a surface for interaction, not a substitute for authorization or business rules.

Security responsibilities don't disappear

A structured action is more reliable than scraping, but it can also make a sensitive capability easier to invoke. The recommended posture is to treat each tool call as untrusted input: authenticate and authorize on the server, re-validate every input server-side, make read-only and state-changing actions clearly distinguishable, require confirmation for purchases, deletions, publication and account changes, return only the minimum necessary data, log consequential calls for auditing, and apply idempotency protection where running an action twice would cause harm.

Start narrow, then test hard

The suggested first tool is not "control my entire application." Good candidates include searching public documentation, checking an order status, producing a quote without purchasing, finding available appointment times, or saving a draft without publishing it — each has clear inputs, predictable output and existing server-side permission checks.

Evaluation should go beyond the happy path. Does the agent choose the tool for the right request, avoid it for unrelated ones, ask for missing required fields, reject invalid values cleanly, explain a failure without inventing a result, request confirmation before consequential actions, and behave correctly when the user is signed out or unauthorized? Chrome's DevTools and Lighthouse tooling can inspect registered tools, the post notes, but application-level tests remain necessary.

The proposed adoption plan keeps the human interface fully functional: select one narrow action, define its name, description and input schema, reuse existing server authorization and validation, add confirmation for meaningful side effects, and test successful, invalid, unauthorized, cancelled and repeated calls — all while treating the implementation as experimental.

Why it matters

Today's agent automation rests on interpretation, which means every redesign is a potential breaking change. WebMCP-style declarations would give the web an agent-facing layer with the same explicitness as its human-facing one, letting sites decide exactly which capabilities agents can discover and under what permission context, while keeping full control over validation and authorization on the server. The caveat is maturity: this is a Chrome origin trial, not a cross-browser standard, so it is too early to make it the only path for a critical workflow. Still, because the declarative route is essentially free progressive enhancement on top of forms that keep working regardless, it is a low-cost experiment now — and a clear signal of where browser and agent interaction is heading.