What Is WebMCP in Chrome, and Should You Ship It Yet?

WebMCP is a browser API that lets a web page hand an AI agent a list of things it can do, rather than leaving the agent to work out where the buttons are. The page registers named tools, each with a plain-English description and a JSON schema for its inputs. An agent running inside that browser reads the list and calls them directly. The clicking, the waiting and the guessing come out, and the site decides what is on the menu.

What is WebMCP, and what problem does it solve?

Browser agents today mostly drive a site the way a person does, only worse: find an element, click it, wait for something to change, hope the layout did not shift. It works until a class name changes. WebMCP inverts the arrangement. Instead of the agent reverse-engineering the interface, the page publishes its own capabilities. The specification describes it as a "form-fitting, client-safe solution designed natively for the web platform."

The practical difference is who holds the contract. A DOM-driving agent has no idea whether the button it just clicked cancelled an order or created one. A WebMCP tool has a name, a description, a typed input schema and a function the site itself wrote. The site can offer three tools and no more. It can mark the read-only ones as read-only. It can decline to expose anything that spends money.

One thing worth correcting early, because the press coverage is lopsided: this is not a Google project with Microsoft watching. The specification credits three Microsoft authors (Brandon Walderman, Leo Lee and Andrew Nolan) alongside three from Google (David Bokan, Khushal Sagar and Hannah Van Opstal), with Dominic Farolino driving the recent specification work. Edge is running the trial too.

Is it navigator.modelContext or document.modelContext?

It is document.modelContext, and it has been since 27 May 2026. Pull request #184 in the specification repository, titled "Move the modelContext getter to Document", did exactly what its title says: it took the getter off the Navigator interface and put it on Document, so tools are scoped to a document rather than a window. It was authored by Dominic Farolino, closed issue #173, and merged with three approvals.

That single move is why so much of the material on this subject is quietly broken. Twenty-two published guides with a clear position on the API were checked for this article. Eighteen of them teach navigator.modelContext or a method that has never existed in any version. Only four teach the current name, and all four were published or updated after July 2026. Every page dated before roughly July 2026 is wrong, including the ones ranking at the top of search for the obvious queries.

The invented methods are their own problem. Across those pages you will find navigator.registerTool, provideTools, listTools, clearContext, provideContext, unregisterTool and requestUserInteraction presented as working code. None of them exist in the current specification. One guide teaches the declarative attribute as tool-param-description; the real attribute has no hyphens.

What does a WebMCP tool actually look like?

A tool is an object with a name, a description, an input schema and an async execute function. It is registered against the document, and unregistered by aborting a signal you pass in at registration time. This example is the shape used in the specification repository itself.

// Current API. The getter lives on document, not navigator.
const controller = new AbortController();

document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string", description: "The text content of the todo item" }
    },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return { content: [{ type: "text", text: `Added: ${text}` }] };
  }
}, { signal: controller.signal });

// To remove the tool later, abort the controller.
// There is no unregisterTool() method, and there never was.
controller.abort();

The AbortSignal pattern is the single most-missed detail. Six of the audited guides teach a call to unregisterTool(), which will throw. Chrome refined the behavior since: as of Chrome 153 a tool can be unregistered without cancelling and breaking executions that are still in flight.

There is also a declarative form, which annotates an existing HTML form so that submitting it becomes the tool. The attributes are toolname, tooldescription, toolparamdescription and toolautosubmit, all lowercase and unhyphenated. Be aware that this half is unfinished: section 4.3 of the specification currently reads, in full, "This section is entirely a TODO. For now, refer to the Declarative API explainer."

For inspecting what a page is offering, document.modelContext.getTools() returns the registered set and executeTool() runs one by name. A toolchange event fires when the set changes, which is what a debugging extension listens for.

How is WebMCP different from MCP?

They are different layers and they are not competing. Chrome states it plainly: "WebMCP is not an extension or a replacement of MCP," and suggests treating it as "a set of 'MCP-inspired' APIs, rather than a direct JavaScript implementation of MCP." The same post calls the two "partners, not opponents." The specification repository agrees that WebMCP "derives direct inspiration and shares a common vocabulary with MCP (e.g., tools, schemas, parameters)" while being built for the web platform specifically.

The clearest way to hold the difference is to ask where the tool code runs and who is already authenticated.

So a WebMCP tool cannot replace an MCP server for anything that has to run when nobody has the tab open, and an MCP server cannot see the shopping cart the user is looking at right now. That is the whole division of labor.

Is WebMCP a W3C standard?

No. The document is published as a Draft Community Group Report by the W3C Web Machine Learning Community Group, and it carries the standard boilerplate: "It is not a W3C Standard nor is it on the W3C Standards Track." Chrome's own tracker records its maturity as a specification "being incubated in a Community Group," and lists the TAG review, the security review and the privacy review as all still pending.

A Community Group is open to anyone and produces no standards. A Working Group produces Recommendations. The confusion is easy to explain, because there is a Web Machine Learning Working Group at the W3C, but its deliverable is WebNN, a neural network API, not this. Anything describing WebMCP as an official W3C standard has skipped that distinction.

Which browsers support WebMCP, and how do you enable it?

Two engines, both Chromium. Chrome runs an origin trial that began at Chrome 149 and is scheduled to end at milestone 156, with 157 recorded as the expected shipping milestone. For local development the instruction is simpler: Chromium 146.0.7672.0 or later, with the #enable-webmcp-testing flag switched on. Microsoft Edge lists WebMCP in the origin trials section of its 151 release notes, described as a feature that "enables your site to register tools for an in-browser agent to complete tasks on behalf of a user."

Note what is missing. Dominic Farolino filed position requests with both Mozilla and WebKit on 28 May 2026, the day after the rename landed. Three months later, neither has endorsed it. Mozilla has since closed its issue with a "position: neutral" label, which is a shrug rather than a commitment. The WebKit issue carries concern labels for API design, privacy, security, internationalization and portability, but no stated position. Chrome's tracker records Firefox and Safari as "No signal" apiece.

Is anyone actually using it in production?

Yes, and at a scale that makes the common "nobody has shipped this" framing out of date. On 5 August 2026 Shopify turned WebMCP on across its storefronts. The changelog entry is unambiguous: "Online stores now expose WebMCP tools that AI agents can call. Agents can search your catalog, manage the shopper's cart, and go to checkout on the shopper's behalf, all in the tab they're looking at." For merchants, "There's nothing to install or configure."

The tools exposed are the obvious commerce set: catalog search, store browsing, product and variant lookup, cart read and write, checkout, order management and a policy or FAQ search. It went live on every Liquid storefront and on the Hydrogen developer preview at the same time.

Beyond that, the record thins out fast. WordPress has an open issue proposing a WebMCP experiment, filed in April 2026 and still marked as needing a decision, and that issue itself takes care to note the specification is not a W3C standard. No second production adopter of comparable size turned up in this research. One large platform switching it on by default, and a long queue of people writing about it, is roughly the honest picture.

What changes about security when a page hands an agent tools?

The threat model shifts, and the specification is candid about it. The section on security and privacy names prompt injection first: "malicious instructions are embedded in tool metadata, inputs, or outputs to manipulate agent behavior or compromise systems." Tool descriptions and return values, it warns, "could be treated as trusted context by agents," which turns any user-generated content on the page into an injection surface.

Two further lines deserve to be read twice by anyone shipping this. On authority: "Agents are able to inherit user identity and authentication context from the browser. When an agent visits a website, it carries the user's logged-in credentials and session state." And on trust: "There is no guarantee that a WebMCP tool's declared intent matches its actual behavior." The document then concedes its own limit, stating that it "cannot define precise mitigation strategies that agents or user agents must provide."

Chrome's guidance for tool authors is more practical and just as blunt. Tools that write "should only be exposed to origins you decide can be trusted." The readOnlyHint flag exists so an agent "can make better decisions about when to ask for user confirmations." And the underlying caveat: "it's impossible to guarantee safety inside of a large language model."

Should you ship WebMCP yet?

It depends on which of three situations you are in, and only one of them calls for real work.

• On Shopify: it is already done. The tools are live on Liquid storefronts with nothing to install. The useful move is to check what the default tools expose and decide whether that matches how the store should behave.
• Building something agent-facing: prototype behind the flag. Two or three read-only tools, registered properly against document.modelContext, cost very little and teach a lot. Treat the write path as a later decision.
• Planning a rewrite around it: not yet. The specification sits in a Community Group with three reviews pending, two engines have said nothing at all after three months, and the API surface moved once already this year.

The idea is durable even if this particular spelling of it is not. Sites will end up declaring their capabilities to agents rather than being scraped by them, because the alternative is worse for both sides. Whether the getter ends up on document is a detail. Writing tools with tight schemas, honest descriptions and a hard line around anything that spends money is the part that survives whatever the name turns out to be.

Frequently asked questions

Sources

• WebMCP specification, Draft Community Group Report, 26 August 2026: the standards-status boilerplate, the security and privacy section including prompt injection, inherited credentials and intent misrepresentation, and the unfinished declarative section.
• webmachinelearning/webmcp repository: the registerTool example and the description of WebMCP as a form-fitting, client-safe solution designed for the web platform.
• Pull request #184, merged 27 May 2026: "Move the modelContext getter to Document", the change that moved the API off navigator.
• W3C Web Machine Learning Community Group: the group that publishes the specification, and the distinction from the Working Group that produces WebNN.
• Chrome Platform Status: WebMCP: origin trial milestones 149 to 156, expected shipping milestone 157, pending TAG, security and privacy reviews, and the no-signal entries for Firefox and Safari.
• Chrome: the WebMCP imperative API and the WebMCP documentation hub: document.modelContext throughout, getTools, executeTool, the toolchange event, and the Chrome 153 unregistration change.
• Chrome: when to use WebMCP and MCP: the statements that WebMCP is not an extension or replacement of MCP, that it is MCP-inspired, and that the two are partners rather than opponents.
• Chrome: securing WebMCP tools: the trusted-origins guidance, the purpose of readOnlyHint, and the statement that safety cannot be guaranteed inside a large language model.
• Google Chrome modern web guidance: the Chromium 146.0.7672.0 minimum and the enable-webmcp-testing flag.
• Microsoft Edge 151 release notes: WebMCP listed under origin trials, with the quoted description.
• Mozilla standards-positions #1412 and WebKit standards-positions #670: both opened 28 May 2026, both still without a stated position.
• Shopify changelog, 5 August 2026 and the Shopify WebMCP tool reference: what shipped, the nothing-to-install line, and the list of exposed tools.
• WordPress AI issue #448: the open, undecided proposal to experiment with WebMCP.

Related reading from Best Answer Hub: what AI agent skills are and what they are for, whether a vibe-coded app is ready to launch, and the free Developer Toolbox. Ready-made packs for coding agents live at AI Agent Skills.