The decision, not the checklist

WebMCP in 2026: what it is, and what the checklists get wrong

What WebMCP actually is

WebMCP gives a page a way to declare its capabilities to an agent running inside the browser. Instead of an agent inferring intent from the DOM and synthesising clicks, the page registers named tools with JSON-schema inputs, and the agent calls them. It is the same idea as the Model Context Protocol, moved from a server the agent connects to into the document the user is already on.

The governance detail matters more than the pitch. The proposal is incubated by the W3C Web Machine Learning Community Group — the webmachinelearning/webmcp repository declares group 110166 and repo type cg-report in its w3c.json, and the specification draft carries Status: CG-DRAFT against group webml. A Community Group report is not a standards-track document: there is no First Public Working Draft, no Candidate Recommendation, and no chartered Working Group behind it. The repository's own README puts a test-tube marker beside the project name on its first line, which is a fair summary of where it sits.

It is active work, not abandoned work. The repository had 113 open issues and a last push of 3 Aug 2026 when this page was written, with the most recent commit on the default branch dated 28 Jul 2026. The editors are Brandon Walderman of Microsoft and Khushal Sagar and Dominic Farolino of Google — two vendors, and neither of the other two engines is among them: WebKit has filed opposition and Mozilla is neutral. That imbalance is recorded upstream too: the W3C TAG design review for WebMCP, opened 11 Jun 2026 and still open, carries the label Missing: Multi-stakeholder support, and Farolino noted on 6 Aug 2026 that a formal position has not yet been reached.

What the circulating checklists get wrong

Three errors show up in almost every "make your site agent-ready" write-up, and each one is checkable in about a minute.

1. The API name. The entry point is document.modelContext. The string navigator.modelContext appears nowhere in the current spec or explainer, and provideContext — the method name most tutorials show — does not exist in the IDL at all. The confusion has a real origin: Chrome's own reference states that navigator.modelContext is deprecated in Chrome 150 and that document.modelContext should be used instead. Checklists written against the older shape were correct once and were never revised. Here is the current interface, verbatim from the draft:

partial interface Document {
  [SecureContext, SameObject] readonly attribute ModelContext modelContext;
};

[Exposed=Window, SecureContext]
interface ModelContext : EventTarget {
  Promise<undefined> registerTool(ModelContextTool tool, optional ModelContextRegisterToolOptions options = {});
  Promise<sequence<RegisteredTool>> getTools(optional ModelContextGetToolOptions options = {});

  attribute EventHandler ontoolchange;
};

Two methods and one event, on the agent-facing side plus an executeTool(). That is the whole surface. Any guide showing a richer API is describing something else.

2. The owning group. If a write-up attributes WebMCP to the WICG, it is wrong. It is not a WICG proposal; it is a W3C Web Machine Learning Community Group deliverable, contact anssiko, as the repository metadata states. This is not pedantry — which incubator holds a proposal tells you which vendors are in the room and what the path to a standard looks like.

3. The consumer side is treated as settled. A tool registry is worthless without something that calls it, and the checklists tend to assume a browser agent is already out there consuming these declarations. No primary Chrome page names the consuming agent. Widely repeated secondary claims exist and we could not confirm any of them against a first-party source, so this page does not name one. What is verifiable is covered below: two Chromium browsers running the trial, one remote browser in developer preview, and one framework with experimental emit support.

A fourth trap sits one layer down, in the tooling you would use to check any of this. The Chrome Platform Status entry for the feature (feature 5117755740913664) reports status Proposed, desktop 157, and origintrial: false. It was last edited 4 Jun 2026 and it contradicts the browser's own shipping record. Treat blink-dev as authority for trial state and the tracker as a lagging index.

Where it runs today, and when the trial expires

Chrome's origin trial is live and time-boxed. The Intent to Experiment on blink-dev, filed 15 May 2026, was approved by Mike Taylor on 18 May 2026 with "LGTM to experiment from M149 to M156 inclusive". M149 reached stable on 2 Jun 2026 and M156 is scheduled for stable around 20 Oct 2026, with current stable at M151 as of 6 Aug 2026. So the window is open today and closes this autumn unless it is extended — which is the number to put in your calendar if you are considering a trial deployment. WebMCP is shipped to stable in no browser.

Edge is the quiet one. Its participation is easy to miss because it is a single line under the Origin trials heading of the Edge 151 web platform release notes — "WebMCP — Enables your site to register tools for an in-browser agent to complete tasks on behalf of a user" — with the same entry in Edge 150. Running a Chromium origin trial is not an endorsement, so read it as trial availability, not a second engine committing.

The more interesting movement is off-browser. On 6 Aug 2026 Cloudflare announced a developer preview of WebMCP on Cloudflare, stating that its remote browser BrowserRun "already added WebMCP support, so an agent can discover and call the tools a site exposes". One caveat if you read that post: it describes the feature as shipping experimentally in Chrome 146, which is the flag-gated developer-trial milestone rather than the origin trial at 149. Prefer Chrome's own numbers.

On the authoring side, Angular has merged experimental WebMCP support, with the surrounding work visible in the framework's pull-request history: disabling registration during server-side rendering, setting additionalProperties: false on the generated form schema, and requiring tool descriptions. Those three commits are a useful preview of the problems you inherit when you adopt this: SSR safety, schema strictness, and the fact that a tool without a good description is invisible to the thing that has to choose it.

The two filed browser positions, and what they object to

Both non-Chromium engines have filed formal positions, and neither reads as a scheduling complaint. They are objections to the design.

Mozilla: neutral. The Firefox standards position for WebMCP is labelled neutral, and the review names the risk surface plainly: in an adversarial setting a site may "tar pit automated browsers, provide prompt injection that is invisible to typical users, collect user data from the inputs of the tools" (Mozilla's review comment, 1 Jun 2026). That third one is easy to skip past. Tool arguments are supplied by an agent acting on the user's behalf and can carry material the user never chose to type into that origin.

WebKit: oppose. The WebKit standards position records "position":"oppose", with concerns filed under duplication, internationalization, privacy, security, venue, use cases, portability, and API design. The substantive argument is that the capability belongs in HTML and ARIA rather than in a parallel model-facing API — and it quotes the draft's own admission that there is "no guarantee that a WebMCP tool's declared intent matches its actual behavior". That is the crux for anyone weighing adoption: the spec concedes that a declared tool is a claim, not a contract, and every consumer has to treat it as untrusted input. If that sounds familiar, it is the same threat model as prompt injection, relocated to a place where the attacker owns the schema.

The auditing situation is better than reported, and still not CI-shaped

Three WebMCP audits exist in Lighthouse and are actively maintained. They shipped in Lighthouse v13.2.0 on 1 May 2026 as webmcp-form-coverage, webmcp-registered-tools, and webmcp-schema-validity, and they have been revised since: v13.4.1, published 20 Jul 2026, refined the WebMCP gatherers to check document.modelContext and removed snapshot mode. The gatherers tracking the API rename is a reasonable sign the audits are being kept in step with the draft.

The real constraint is not the audit, it is the runtime. Chrome's own documentation states that WebMCP requires a browser context and does not support headless operation. That rules out the cheapest place you would want this check to live — a headless run in a build pipeline — and pushes verification into a full browser session, which is a different cost and a different flake profile. Plan for that before you promise anyone a green tick in CI.

The call we made, and the condition that would re-open it

On 26 Jul 2026 this platform logged WebMCP as no build. The reasoning was the state above, not a view on the idea: an experimental Community Group draft, an API surface the ecosystem was describing incorrectly, a thin consumer side, and — decisively — nothing to register on the layer this page lives on. A guide page like this one exposes no tools. There are no actions for an agent to invoke, so a tool registry would be an empty object announced to nobody.

The decision was written with an explicit re-open trigger, quoted from the record: "it leaves origin trial into stable Chrome, OR a second independent consumer ships. The only surface here that would ever justify it is /sample's quiz runner, never a guide page." That second clause is the useful half. Even if the platform question flips, the answer is scoped to the one surface the trigger names — the free sample lesson quiz runner — and not to the guide layer, however much of it there is.

Two honest amendments to the record, both from re-verifying it for this page. First, the original note described the Lighthouse audits as broken; they are not, they are maintained, and the citable constraint is the browser-context requirement rather than any defect in the audits. Second, the note named a specific consuming agent that we could not confirm against a first-party source, which is why this page names none.

Where the trigger stands is a matter of record, not of announcement. Chrome has not left origin trial. Whether Cloudflare's remote-browser developer preview constitutes a second independent consumer is exactly the kind of judgement the trigger leaves to the person who owns it, and it is the condition to watch. Nothing here reverses the decision.

When WebMCP would be worth building for you

The filter is not traffic and it is not how modern your stack is. It is whether an agent can do anything on your site.

• Build it if your pages expose real user-facing actions. Booking and rescheduling, faceted search over your own inventory, adding to and modifying a cart, filing and updating a ticket, running a configurator, submitting a structured form with server-side validation. These are things a tool declaration can describe honestly and an agent can complete, and they are where the origin trial is worth spending on.
• Skip it if your pages are content. Articles, documentation, guides, marketing pages. There is nothing to register. Text is already legible to anything that fetches it, and a tool registry over a read-only page is ceremony.
• Two conditions apply either way. You need to be comfortable with a trial-gated API that expires this autumn unless extended, and you need to design as if every consumer treats your declared intent as unverified, because the specification says it is.

The transferable lesson is about the checklist, not the API. Checking the claims on this page cost a few minutes each — against a repository file, a mailing-list thread, or a vendor release note — and several of those minutes overturned something that was being repeated confidently. That is the habit worth having when the next capability starts circulating — the same one we apply to the curriculum.

Frequently asked questions

Is WebMCP the same as MCP?

They share an idea and a name, not a specification. MCP is the client-server protocol an AI application uses to reach tools and data outside the page; WebMCP is a browser API through which a page declares tools to an agent inside the browser. MCP is widely implemented; WebMCP is a Community Group draft in origin trial.

Can I use WebMCP in production today?

Not as a stable platform feature. It ships to stable in no browser. It is reachable through Chrome's origin trial, which is approved for M149 to M156 inclusive, with M156 scheduled for stable around 20 Oct 2026. Edge exposes the same trial.

Is it navigator.modelContext or document.modelContext?

document.modelContext. Chrome's documentation records that navigator.modelContext is deprecated in Chrome 150 and that document.modelContext replaces it. The current draft interface exposes registerTool(), getTools() and an ontoolchange handler.

Will Safari or Firefox support it?

Neither has committed. WebKit has filed a position of oppose, arguing the capability belongs in HTML and ARIA and raising privacy, security and API-design concerns. Mozilla's position is neutral, naming prompt injection and data collection through tool inputs among the risks.

Changelog

• 2026-08-10 — Initial publication. The claims on this page were verified on 10 Aug 2026 against the primary sources listed below: the specification repository and draft, the W3C TAG design review, Chrome's WebMCP documentation, the blink-dev Intent to Experiment, the Chrome release schedule, the Mozilla and WebKit standards positions, the Edge 151 release notes, Cloudflare's announcement, and the Lighthouse release notes. Corrects two points in our own 26 Jul 2026 decision note: the Lighthouse audits are maintained, not broken, and the consuming agent named there is not confirmable against a first-party source.