WebMCP (sometimes written Web MCP) is a proposed browser standard that lets a web page tell an AI agent what it can do on that page, and then do it properly. Instead of an agent reading your screen and guessing which button books a call, your page offers it a tool called something like “book a call”, with the inputs it needs and a clear answer when it has finished.
It is early. It works in Chrome behind a flag or an origin trial, the specification is a draft, and the API has already changed shape once this year. But it is being written by people at Google and Microsoft, and it is the first serious attempt to give agents a front door to a website rather than a window to climb through. If you run a site that people use to enquire, book or buy, it is worth understanding now.
The problem it solves
Today an agent that uses a website on someone’s behalf works the way a very patient stranger would. It looks at the page, finds something that looks like a search box, types, waits, reads the result and tries again. It works surprisingly often. It also breaks when a button moves, when a label is ambiguous, or when the page loads in two stages and the agent acts on the first.
The site owner has no say in any of this. The agent does not know that “Enquire” and “Book a call” go to different people, that a field is optional, or that pressing a button spends money. WebMCP turns that guesswork into a contract the page writes itself.
What WebMCP actually is
A page registers tools. Each tool has a name, a plain-language description, a schema for its inputs, and a function that runs when an agent calls it. The browser collects them, and an AI agent working in that tab can list them and call them.
Three things make it different from giving an agent an API:
It runs in the page. The tool calls the same JavaScript your buttons already call, so the person watching sees the page update as the agent works. Nothing new is exposed on your server.
It uses the visitor’s session. If they are signed in, the agent acts as them, with their permissions and nothing more. There is no separate key to issue or leak.
It only exists while the page is open. Close the tab and the tools are gone. That is a limitation, and it is also the point: a person is there, and can see what is happening.
WebMCP, MCP and your API
The name invites confusion with MCP, the Model Context Protocol that connects assistants to services on a server. Chrome’s own guidance is blunt: WebMCP is not an extension or a replacement of MCP. MCP makes your data and actions available to an agent anywhere, at any time, with no browser involved. WebMCP makes a live page easier for an agent to use while a person has it open.
A reasonable way to divide it: background jobs and integrations belong on your API or an MCP server. Anything that should happen with the customer present — choosing a time, checking a quote, filling in their details — is where WebMCP fits.
The two ways to add a tool
There is a JavaScript API for anything dynamic, and a set of HTML attributes that turn an ordinary form into a tool.
1. Registering a tool in JavaScript
The current draft puts the API on the document. Here is the shape of a tool, close to the specification’s own example:
const controller = new AbortController();
await document.modelContext.registerTool({
name: "add-todo",
description: "Add a new item to the user's todo list",
inputSchema: {
type: "object",
properties: {
text: { type: "string", description: "What the todo says" },
},
required: ["text"],
},
async execute({ text }) {
await addTodo(text); // the same function your button calls
return { content: [{ type: "text", text: `Added "${text}".` }] };
},
}, { signal: controller.signal });
// Remove the tool when it no longer makes sense on this screen:
// controller.abort();Two details matter more than they look. The description is what the agent reads to decide whether to use the tool, so it should say exactly what happens, including anything irreversible. And the tool is removed by aborting a signal, which suits pages that change: register a “cancel booking” tool only while a booking is on screen.
If you read a guide that uses navigator.modelContext, it was written against the earlier Chrome preview. The draft now uses document.modelContext. While both exist in the wild, check for either: const mc = document.modelContext ?? navigator.modelContext.
Tools can also carry hints: readOnlyHint for a tool that only looks things up, consequentialHint for one with real-world effects such as paying or sending, and untrustedContentHint when its output includes text you did not write. They are there so agents and browsers can tell when to stop and ask the person first.
2. Turning a form into a tool
For the forms most business sites are made of, the draft describes a declarative version: a few attributes on the form, and the browser builds the tool for you.
<form toolname="book-intro-call"
tooldescription="Request a free 30-minute intro call">
<input name="name" required
toolparamdescription="The person's full name">
<input name="email" type="email" required
toolparamdescription="Where to send the confirmation">
<button type="submit">Book</button>
</form>Without the toolautosubmit attribute, the agent fills the form in and stops. The browser puts the submit button in focus and the person presses it themselves. For anything that commits someone to something, that is the behaviour you want. The page can also tell an agent’s submission from a person’s through SubmitEvent.agentInvoked, and answer the agent with a structured result instead of a page load.
This part of the draft is the least settled: the attributes live in a separate explainer that is being folded into the main document. Expect names to change before anything ships widely.
WebMCP in Chrome: where it stands in September 2026
The specification is a Draft Community Group Report in the W3C’s Web Machine Learning Community Group, edited by engineers from Microsoft and Google. It is not a W3C standard, and it is not on the standards track yet.
In Chrome, WebMCP opened as an early preview earlier this year, and an origin trial began in Chrome 149, so a live site can switch it on for real visitors for a limited time. For local work there is a flag, chrome://flags/#enable-webmcp-testing, and Chrome’s Model Context Tool Inspector extension lets you see and call the tools a page registers. For now it is a Chrome experiment; no browser has shipped it to everyone.
Chrome’s documentation is also honest about the limits: it is built for a person in a browser, not for headless automation; a complicated interface may need restructuring before its actions make clean tools; and there is no directory of tools — an agent only finds them by visiting your page.
Security is the real design work
The specification spends a long section on what can go wrong, and it is worth reading before writing a single tool. The short version:
A tool’s description and output go straight into an AI model’s context, so both are an opening for prompt injection. Never echo text from other users back through a tool without marking it untrusted.
A tool can quietly ask for more than it needs. Take the minimum inputs to do the job, the same rule as any form.
Access is controlled by a permissions policy called tools, which by default allows only your own origin. Leave it that way unless you have a reason to let an embedded page register tools.
The rule I would hold to: an agent may prepare anything, but a person confirms anything that spends money, sends a message or cannot be undone. WebMCP gives you the hooks to build it that way. It does not make you.
What I would do with a business website today
Nothing irreversible. This is a draft API in one browser, and building a product around it now would be building on sand.
But there is cheap, useful preparation, and most of it improves the site for people too:
Make your forms honest. Clear labels, the right input types, real validation, a proper submit button. The declarative API builds tools from exactly this markup, and a form an agent can understand is one a screen reader can too.
Keep actions in functions, not tangled in click handlers. If “check availability” is a function you can call, it is one line away from being a tool. If it only exists inside a button’s event handler, it is a refactor.
Pick your two or three tools. For most service businesses that is a question, a booking and a quote. Write their descriptions now, as if explaining them to a new colleague. That text is most of the work.
If you have a developer, try it on a staging copy with the Chrome flag and the inspector extension. An afternoon is enough to see whether your booking or enquiry flow survives being driven by an agent, and that is useful to know whatever happens to the standard.
Sources
The WebMCP draft specification and its declarative API explainer, from the W3C Web Machine Learning Community Group (webmachinelearning.github.io/webmcp and github.com/webmachinelearning/webmcp). Chrome for Developers: the WebMCP documentation, the origin trial announcement, and “When to use WebMCP and MCP”. Webfuse’s practical guide to WebMCP (April 2026) is a good walkthrough, written before the move to document.modelContext.
