A person looking at a quote form can tell which fields are required and which button sends the request. A browser agent has to infer the same workflow from labels, DOM structure, visible state and sometimes a screenshot, and it can guess wrong.
WebMCP is a proposed web standard that lets the page describe its actions directly. Chrome offers it through an origin trial starting with Chrome 149, and developers can turn it on locally with the chrome://flags/#enable-webmcp-testing flag (Chrome WebMCP overview). Sites cannot assume visitors' browsers support it, so a WebMCP tool is an addition to a page whose normal navigation and forms keep working without it.
What a page tool looks like
In Chrome's imperative API, a page registers a tool with document.modelContext.registerTool(), passing a name, a description, an inputSchema written as JSON Schema and an async execute function. Discovery goes through document.modelContext.getTools(), which is asynchronous and returns tools in alphabetical order; tools from other origins are returned only when requested with the fromOrigins option. A declarative API covers simpler cases by annotating a standard HTML form.
Tools belong to the page. A page removes one by passing an AbortSignal to registerTool() and aborting it later, so the available set can follow the page's state, for example registering a checkout tool only once the cart has items. WebMCP is only available in origin-isolated documents, its permissions policy defaults to self, and a cross-origin iframe needs allow="tools" before it can register tools.
A quote request, as an illustration
Take a B2B quote flow as an illustrative case. A signed-in buyer has saved items, account terms and a partial contact record. The page could register start_quote_request with required inputs for the selected products, delivery window and notes, with the account contact filled in from the session.
That tool should create a draft and stop. Chrome's API lets a tool carry annotations, including readOnlyHint for tools that only read and consequentialHint for tools whose effects are significant or cannot be reversed. An annotation tells the agent what kind of tool it is dealing with. The confirmation step is still something the page builds: execute saves the draft, shows the missing fields and waits for the buyer to press the real submit button, and the server receiving the quote applies the same validation it applies to the form.
Log tool executions that change data, with the tool name and page, so a support question about a quote nobody remembers submitting can be traced to an agent-initiated draft.
How is this different from a backend MCP server?
A backend MCP server is a separate service that an AI client connects to, with its own authentication and its own tool list, and no browser needs to be involved. A WebMCP tool runs in the page's JavaScript, inside the tab the user has open, with that tab's session, and it goes away with the page. Both can serve the same business flow: a WebMCP tool on the order page and a backend tool used by an internal assistant can call the same order service.
The authorization questions for a backend server are covered in MCP tool permissions in .NET applications. On the page, the existing session and the server's checks on the underlying request still decide what a tool can do.
Which page to start with
A first candidate is a page whose flow users abandon, call support about or retype into another tool. Decide what an agent may read there, what it may draft and what needs the user's confirmation, then register one tool and test it with the local flag. The acceptance check is the progressive-enhancement requirement from the start: with WebMCP unavailable, the ordinary form still completes the same request, and the server applies the same validation to both paths.
Related Reading
For customer booking and reorder examples, read Customer-facing MCP servers: permissions, approvals and retries.