An AI agent that books, orders, or fills in a form for someone has two ways to reach a business today. It can drive the website the way a person does, reading the page and simulating clicks, or it can skip the website and talk to a backend integration directly. Which one it takes decides whether your website is part of the transaction at all. WebMCP is a proposed web standard for a third path: the site declares what it can do, in a format the agent reads directly, and the work happens inside the page the user already has open. This note covers the pattern, the part you can act on now, the cost almost nobody mentions, and why a small disposable pilot beats a platform bet.
Use you, or route around you.
The strategic sentence is in the explainer's Goals list, not in any launch copy. One goal reads, verbatim: "Prevent disintermediation of web apps by backend integrations by adapting front-ends for use by agents, rather than replacing them."[1] Disintermediation is the business story. Agents that call a service's servers through a backend integration, such as the Model Context Protocol or an OpenAPI connector, go straight past the website. The explainer lists what that costs: the web interface is bypassed and its context lost, the user's session and login have to be rebuilt on a separate server, and the business has to write and run that server instead of reusing the code its pages already run.
Translate that for a business with a booking page. When the agent goes around the site, your offer page, your confirmation screen, your add-on, and your brand are not in the transaction. The agent and the backend settle it between themselves. WebMCP's bet is that the front-end can stay in the loop if it becomes something an agent can use well. The tools run in the user's own browser tab, with their session and login already in place, and the page updates where the user can see it.
What WebMCP actually is.
WebMCP is a proposed browser API, drafted in a W3C community group and in origin trial in Chrome, that lets a web page register tools an AI agent can call instead of driving the page with simulated clicks. A page calls document.modelContext.registerTool() with a name, a plain-language description, a JSON Schema for the inputs, and an execute callback. A browser-based agent asks the browser which tools the page has registered, picks one, and calls it with structured arguments. The callback runs the page's own code. There is also a declarative path that annotates existing HTML forms, with no JavaScript, for the simple cases.[1][2]
Three things it is not, from the proposal's own Non-Goals. It is not a replacement for MCP. It borrows MCP's vocabulary (tools, schemas, parameters) but deliberately did not adopt the spec, because MCP was built for server-to-client and process communication and has no notion of origins, browser permissions, the DOM, or tab lifecycle. It is not a replacement for the human interface, which stays primary. And it is not meant for fully autonomous agents running with no browser at all. It is also gated: it only runs in origin-isolated documents, and behind a tools permission policy that defaults to the page's own origin, so a third-party iframe needs explicit permission.[2]
- 1Read the page: screenshots, the DOM, the accessibility tree
- 2Guess what each button and field is for
- 3Simulate the clicks and keystrokes
- 4Re-read the page to see whether it worked
- 5Repeat for every step of the task
- 1Ask the browser which tools the page registered
- 2Pick one by its name and description
- 3Call it with arguments that match its JSON Schema
- 4The page's own code runs; the visible UI updates
- 5A structured result comes back
A tool is four things.
This is the part an operator can act on today. A tool is a name, a description, a JSON Schema, and a callback that runs code your own interface already calls. That last part is what keeps the cost down. If your quote form already validates its fields and POSTs JSON to an endpoint, a tool wraps that call. You are not writing a second code path; you are giving the one you have a label an agent can read.
// Browsers without WebMCP skip this block entirely.
if ("modelContext" in document) {
const tools = new AbortController();
await document.modelContext.registerTool({
name: "start-quote-request",
description:
"Fills in the quote request form for a service the user names. " +
"The user reviews it and presses Send.",
inputSchema: {
type: "object",
properties: {
service: {
type: "string",
enum: ["workflow audit", "agent build", "support retainer"],
description: "The service the user wants priced."
},
details: { type: "string", description: "The job, in the user's words." },
email: { type: "string", description: "Where the reply should go." }
},
required: ["service", "email"]
},
async execute(input) {
// Strict checks live here, not in the schema: return an error it can fix.
const problem = validateQuote(input); // the form's own validator
if (problem) return { content: [{ type: "text", text: problem }] };
fillQuoteForm(input); // the form's own fill logic
return { content: [{ type: "text", text: "Form filled. The user will review and send." }] };
}
}, { signal: tools.signal });
}
Most of the design decisions in that snippet come straight from the explainer's best-practices section.[1] The name uses a precise verb: start-quote-request fills the form and stops, where a send-quote-request would submit it. The spec draws exactly that distinction between doing a thing now and starting the workflow. The enum uses words a person would say rather than internal IDs. The schema is loose and the callback is strict, because strict schema failures can make an agent stall, while a clear error message lets it correct itself and retry. And the visible form fills in on screen, because the agent and the person share one session.
We chose the fill-and-stop version on purpose. A send version would call the same submit function your form already calls, POSTing the same JSON to the same endpoint, and it would be just as short. But how a tool should ask the user for confirmation before it commits them is one of the questions the spec lists as open, so for anything that sends, books, or charges, leave the last button to the human until that is settled. The feature check on the first line is what makes the whole thing a progressive enhancement, Chrome's own term for it: a browser without WebMCP sees an ordinary form.
registerTool(): name, description, schema, callback inputSchema Every tool spends context.
The idea in this proposal with the longest reach is not WebMCP-specific. The explainer's best practices put it plainly: every registered tool's name, description, and input schema "consumes tokens in the model prompt, adds to inference latency, and increases the potential for tool confusion or hallucination." Then the warning: "Exposing too many tools (e.g., dozens or hundreds) can severely degrade agent performance or lead agent browsers to drop tools or fail to process them."[1] That is guidance from the spec's authors, not a measured threshold, and the spec sets no hard limit. The direction is still not in doubt. A tool list is a context budget, and it is spent before the agent has done anything.
The same arithmetic applies to every MCP server a small business is being sold. Unless the assistant loads tools on demand, each server you connect puts its whole tool list into the prompt, whether or not the job needs it. When a vendor's pitch is that their server exposes eighty tools, the useful reply is to ask how many the agent needs for the task in front of it. We made the same point from the harness side in the build-order note: keep tool sets minimal and non-overlapping, because if a person cannot say which of two tools to use, the model cannot either. The explainer's version is "single responsibility," with an explicit warning against overlapping or redundant tools. And because tokens are money, a bloated tool list shows up in the per-step cost trace we described in the cost-metric note long before anyone notices it in quality.
What nobody has measured.
Neither source offers evidence that it works. Chrome's page says WebMCP "can significantly improve the performance and reliability of agent actuation."[2] That is an unmeasured claim by a co-author organization about its own proposal. No benchmark, dataset, or comparison figure appears on either source, and the only thing offered in support is a side-by-side demo of an appointment booking. The improvement is a plausible hypothesis. It might well turn out true, and it is still a hypothesis.
It cannot make an agent find you. Chrome's own Limitations section: "Clients and browsers must visit a site directly to know if it has callable tools."[2] Whatever WebMCP does, it acts on a site the agent is already on. It does nothing for whether an agent ends up there. The explainer lists background discovery through service workers as an open question, and until something like it ships, findability is unchanged. If someone sells you WebMCP as a way to get recommended by AI, they are making a claim the implementer's own documentation contradicts.
The API is not settled. It is in origin trial in Chrome from version 149 and in Edge from version 150, with a Chrome flag for local testing, while Mozilla's and WebKit's standards positions were still pending at the time of writing.[1] The explainer lists ten open questions, most with issue links, among them a structured output schema, how a tool asks the user for confirmation, what happens when a tool's form submission navigates to a new page, and multimodal inputs and outputs. Anything built during the trial should assume those move. The two sources also disagree on headless use: Chrome calls the API "primarily designed for local browser workflows with a human in the loop,"[2] while the explainer lists headless browsing as a goal. Read together, headless with a browser is in scope and de-emphasized, and no browser at all is out.
The tooling is an extension, not DevTools. Google's tester is the Model Context Tool Inspector, an extension from the Chrome Web Store. It lists a page's registered tools, lets you call them by hand, checks your schema, and shows what your tool returns.[2] Some secondary coverage describes this as built-in DevTools support, and that is wrong. One detail matters for Quebec businesses: by default the inspector's chat sends your prompts to a hosted Gemini model, so test with made-up data, never with real customer records.
For what it is worth, when we assessed WebMCP for our own sites, the prior we wrote down was "probably no measurable lift on a brochure site." That pilot has not run. A site where people complete multi-step tasks, a booking flow, a configurator, a support form with branches, is where the hypothesis has room to show up.
If you pilot it, keep it disposable.
The right posture for an origin-trial API with unmeasured benefits is a pilot you can delete in one commit. Five rules:
- Pick one task the site already does well.
A quote request, a booking, a product filter: something with working code and an endpoint behind it. Not a catalog of everything the site can do. Three tools that wrap existing code beat thirty that need new code.
do · one to three tools, each wrapping code that already exists - Feature-detect it and keep it in one file.
Browsers without WebMCP should see exactly the site they saw yesterday. If the API changes shape during the trial, and the spec says parts of it will, removing the pilot should be a one-line revert, not a refactor.
do · isolate the registration code so deleting it is trivial - Fill, don't send, for anything that commits the user.
Until the spec settles how a tool asks for confirmation, let the agent prepare the form and let the person press the button. It costs one click and removes the worst failure mode.
do · keep the human on the last step of any purchase, booking, or send - Write the success metric before you ship.
Decide what a completed task is, how you will count it, and in which agent, then measure the same task without the tools first. Without a baseline, the only result you will get is that it feels better.
do · write down the metric, the baseline, and the date you will kill it - Test with dummy data only.
The inspector's chat goes to a hosted model by default. Under Quebec's Law 25, that is not where a customer's name and email belong, test or no test.
do · keep personal information out of every hosted test session
If you are weighing whether your site is a WebMCP candidate at all, the contact form is the fastest way in. Tell us which task your customers complete on the site and what sits behind the form, and we will send back a written read on whether a pilot is worth running, free.