WebMCP Explained: How Your Site Could Tell AI Agents What It Can Do

An agent arriving at your booking page today has to work out, from pixels and markup, which control opens the calendar and which field wants a surname. It is an inference problem, and inference fails on anything unusual. WebMCP proposes replacing the inference with a declaration: the page states what it can do, and the agent reads the statement.

This explainer is for marketers, founders and site owners who keep seeing the acronym and want to know whether it is their problem yet. The short answer is that it is a draft, it is moving quickly, and ten minutes of reading now saves a bad decision later.

A tool, in the narrow sense the spec means

WebMCP lets a web page offer named actions to an AI agent. Each action carries a description and a defined set of inputs, which is what the specification calls a tool. Patrick Brosset, who works on the web platform at Microsoft, compresses it into a sentence: it is an API for exposing tools from a webpage (Patrick Brosset).

The name borrows from the Model Context Protocol, the vocabulary that AI clients already use to talk to servers. The borrowing is partial and the difference matters, which is the next section.

Where the draft actually stands, in October 2026

The specification is published by the Web Machine Learning Community Group and dated 9 October 2026. Its status section says plainly that it is a Draft Community Group Report, and that it is neither a W3C Standard nor on the W3C Standards Track (WebMCP specification). That is a meaningful label rather than a formality: a community group report can change shape or stop entirely.

What the draft defines is concrete, though. Pages reach the feature through document.modelContext, which exposes registerTool(), getTools() and executeTool(), along with the ontoolchange, ontoolactivated and ontoolcancel event handlers. Access sits behind a permissions policy feature named tools (WebMCP specification). If an engineer tells you the API is vapour, those are the method names to ask about.

Chrome opened an origin trial at version 149

Chrome's own documentation is the clearest signal of how far this has travelled. It invites developers to join a WebMCP origin trial from Chrome 149, and for local work it points at the flag chrome://flags/#enable-webmcp-testing, with a second flag for trying client-side tool use through the Prompt API (Chrome for Developers). The page still describes WebMCP as a proposed web standard under active discussion and subject to change.

Two details from that page are worth more than the version number. First, there are two routes to declaring a tool: an imperative one written in JavaScript, and a declarative one that works by annotating existing HTML forms. Second, both routes are gated by the tools Permissions Policy, which defaults to self, so a cross-origin iframe needs an explicit allow="tools" to participate (Chrome for Developers). If your checkout, booking widget or demo form is embedded from another origin, that default is the first thing to check.

Alongside the trial, Chrome's agent-ready toolkit post ships guidance aimed at coding agents implementing tools, and the Lighthouse agentic browsing category can inspect whether a page registers valid tools. We cover what that audit actually reports in our note on the agentic browsing score. That is the whole verifiable footprint: a draft, an origin trial, developer guidance and a test. No public evidence shows the major assistants consuming page-registered tools in production, so nobody should claim they do.

The declarative route is the one that will matter

Most commentary treats WebMCP as a JavaScript feature, and that framing leads teams towards a project they do not need. Our position: for the large majority of sites, the declarative route, annotating the forms you already have, is the only part worth planning for, and the imperative API is for single-page applications whose available actions genuinely change as the user moves around.

The reasoning is about where the work lands. Annotating a form is a change to markup you already maintain, and the same discipline that makes a form annotatable, one labelled field per input, a clear submit action, predictable names, is the discipline that makes it usable by a screen reader, parseable by a server-side fetcher and comprehensible to a new developer. That work keeps its value whatever happens to the draft. A hand-written tool registry in JavaScript, by contrast, is a bet on a specification whose own status section refuses to promise stability (WebMCP specification), and its value evaporates if the shape changes. Our piece on how agents actually read a site covers the overlap in more detail.

Assistants may start to prefer imperatively registered tools because richer descriptions and dynamic state make them more reliable. If so, form annotation becomes a floor rather than a strategy, and anyone running a transactional site would need to invest in the JavaScript path early. Watch what the origin trial participants report. If the interesting results come from single-page applications rather than from annotated forms, we are on the wrong side of this.

Two registration styles, and when each earns its keep

Brosset describes the two shapes in script: declare the full set of tools in one go, or add and remove individual tools as the application changes state (Patrick Brosset). The second suits an application where a cart exists on one screen and not another. The first suits a page whose capabilities are fixed, which describes most marketing and documentation sites.

Consent is part of the mechanism, not a layer above it

The draft allows a tool to ask the browser to confirm with the person before it completes, so an agent cannot finish a purchase on its own initiative. Brosset's stated reason is to keep the human in the loop (Patrick Brosset). He also walks back his earlier description of the browser as an MCP server, calling it a simplification: WebMCP supplies the primitives, and the browser handles the data and transport layers underneath.

What a page-registered tool cannot reach

A tool declared inside a page exists only while somebody has that page open. That boundary rules out a large class of uses.

• Server-side MCP runs on infrastructure you operate, authenticates separately, and answers at any hour.
• WebMCP runs inside the visitor's browser, inherits whatever session they are already signed into, and disappears when the tab closes.

So an answer engine that fetches your URL from a server and never opens a browser session gets nothing from a registered tool. Headings in plain text, facts in markup rather than images, and a readable first response still decide whether you appear in an answer at all. The server side of that story is in our piece on why your API may outrank your website.

What to do about it this quarter

1. Sort your site into one of two buckets. People book, buy or submit something: this is on your roadmap within a year. People read: it is a watch item and nothing more.
2. Name your three most valuable actions as verbs with inputs. For a software company, start a trial, book a demo, check a price. Write the inputs each one needs.
3. Make those three work as ordinary labelled HTML forms. This is the step that pays whatever happens to the draft.
4. Check the embed boundary. If any of the three lives in a cross-origin iframe, note that the tools policy defaults to self (Chrome for Developers).
5. Give one person the spec and a quarterly reminder. The status section is the part to re-read, not the examples.

For a lean team the practical lever remains content: your pricing page and your documentation are what an agent consumes before it chooses any action at all. That argument is set out in how lean teams compete in the agent economy.

Three things nobody can answer yet

Whether a community group draft becomes a stable cross-browser standard. Whether assistants will actually favour page-declared tools over their own inference. And how sites will defend people against agents that are confused, hijacked or hostile, given that the draft's confirmation step depends on a person reading the prompt. Anyone selling you certainty on those three is selling something.

Know your three actions, and keep them legible

Implementation can wait. Knowing which three actions matter, and keeping them expressed in clean, labelled HTML, cannot, because that work is useful to people, to accessibility tools, to server-side fetchers and to whatever the standard turns into. It is the cheapest preparation available, and it is preparation you would want even if WebMCP disappeared tomorrow.

Questions publishers keep asking

What does WebMCP do, in one sentence?

It lets a web page declare named actions, with described inputs, so an AI agent can call them directly instead of inferring what each button does from the page layout.

How is it different from the Model Context Protocol?

It reuses the vocabulary of tools but lives in the browser, inside the visitor's own session. Brosset's correction is that WebMCP supplies the primitives while the browser handles the data and transport layers below them.

Has it been standardised?

No. The specification is a Draft Community Group Report from the Web Machine Learning Community Group, dated 9 October 2026, and it states that it is not a W3C Standard and not on the Standards Track. Chrome has opened an origin trial from version 149.

Does a publisher or blog need to care yet?

Not urgently. Transactional sites, where people book, buy or submit, have the clear case. Everyone else gets more value from clean HTML, labelled forms and facts in text, all of which are prerequisites anyway.