What is WebMCP?

WebMCP is a proposed web API that lets a web page expose its own JavaScript functions as “tools” that AI agents can call. Each tool has a name, a plain-language description and an input schema, so an agent can search a catalog or book a table by calling a function instead of clicking through the page. A page registers tools with document.modelContext.registerTool(). WebMCP is not a W3C Standard: the current text is a Draft Community Group Report from the Web Machine Learning Community Group, dated 20 October 2026. Its editors are Brandon Walderman and Samuel Dallstream (Microsoft) and Khushal Sagar and Dominic Farolino (Google). In Chrome, WebMCP has been a DevTrial since Chrome 146, an origin trial runs from Chrome 149 to 156, and shipping is planned for Chrome 157. WebMCP tools run in a browser tab, while MCP tools usually run on a server.

Why does WebMCP exist?

WebMCP exists so a site can tell an AI agent what it can do, instead of the agent having to read the page and act like a person.

Without it, an agent has to find the search box, type, click, wait and read the result. That is slow and breaks easily when the layout changes.

WebMCP gives the site a way to say what it can do. The site writes a tool, describes it in plain words, and states which inputs it needs. The agent reads that list and calls the tool directly. The browser carries the messages between the page and the agent.

Two points matter for site owners:

• Tools run inside the page. They use the live session, cookies and the DOM (the page’s document structure), just like your own scripts.
• Agents find tools by visiting. There is no remote discovery. A browser or agent learns about a site’s tools only when it loads the site.

Chrome describes WebMCP as “primarily designed for local browser workflows with a human in the loop”. Headless use (an agent running a browser with no visible window) is also in scope in the explainer.

Who makes WebMCP, and is it a W3C standard?

WebMCP is published by the Web Machine Learning Community Group, edited by people at Microsoft and Google, and it is not a W3C standard.

It lives in the webmachinelearning/webmcp repository. The spec is a “Draft Community Group Report” published by the Web Machine Learning Community Group. The latest draft is dated 20 October 2026.

A Community Group (CG) report is not a standard. The spec says plainly: “It is not a W3C Standard nor is it on the W3C Standards Track.”

The editors, as of 20 October 2026, are:

Editor	Company
Brandon Walderman	Microsoft
Khushal Sagar	Google
Dominic Farolino	Google
Samuel Dallstream	Microsoft

The README credits early authors from both Microsoft and Google, and says the explainer was first published on 13 August 2025.

The repository holds several documents. Together they make up the WebMCP documentation:

• The spec: the formal API definition.
• README: the main explainer.
• declarative-api-explainer.md: the HTML form version of the API.
• continuations-explainer.md: added on 2 October 2026.
• docs/service-workers.md and implementation-status.md.

The W3C Technical Architecture Group (TAG) has an open review, labelled “CG early review”. It was opened alongside a charter proposal to adopt WebMCP as a tentative deliverable of the WebML Working Group. That adoption is a proposal, not a done deal.

TypeScript typings are published on npm as webmcp-types.

How WebMCP works: the imperative API

The “imperative” API is the JavaScript version. You call one method per tool.

The entry point is document.modelContext

The API hangs off the page’s document:

document.modelContext

It only exists in a secure context (HTTPS or localhost).

You may still see navigator.modelContext in older posts and demos. That is the old name. On 19 May 2026 the spec moved the API from navigator to Document (PR #177). The change followed a W3C TAG question: tools belong to one page, but navigator survives navigations. Chrome’s current docs use only document.modelContext.

Registering a tool

Here is a minimal tool. It checks that the API exists first, so the code does nothing in browsers without WebMCP.

if (document.modelContext?.registerTool) {
  const controller = new AbortController();

  document.modelContext.registerTool(
    {
      name: 'search_products',
      title: 'Search products',
      description: 'Search the product catalog by keyword. Returns matching product names and links.',
      inputSchema: {
        type: 'object',
        properties: {
          query: { type: 'string', description: 'Words to search for' },
        },
        required: ['query'],
      },
      annotations: { readOnlyHint: true },
      async execute({ query }) {
        const res = await fetch('/api/search?q=' + encodeURIComponent(query));
        return res.json();
      },
    },
    { signal: controller.signal }
  ).catch((err) => console.warn('Tool not registered:', err));

  // Later, to remove the tool:
  // controller.abort();
}

registerTool() returns a Promise. It rejects when something is wrong, so catch it.

Tool fields

Field	Required	What it is
name	Yes	The tool’s ID. 1 to 128 characters: ASCII letters, digits, _, - and . only.
title	No	A human-readable label. It sits on the tool itself, not inside annotations.
description	Yes	Plain-language text the agent reads to decide when to call the tool. Must not be empty.
inputSchema	No	An object describing the inputs the tool accepts.
execute	Yes	The function that runs. It gets the input object and an options object with a signal.
annotations	No	Hints about the tool’s behaviour (see below).

Annotations

Annotations are hints. They all default to false.

• readOnlyHint: the tool only reads data.
• untrustedContentHint: the output contains untrusted data, such as user content or content from other websites.
• consequentialHint: the action is significant or cannot be undone, so the agent may ask the user to confirm first.
• debugging: the tool is for inspection and developer tooling. Chrome supports it from Chrome 156.

When registerTool rejects

The spec lists these cases:

• An invalid name: InvalidStateError.
• An empty description: InvalidStateError.
• A name already used in the same document: InvalidStateError.
• The document lacks the tools permission: NotAllowedError.
• The signal is already aborted: the Promise rejects.

Removing a tool: the abort signal

There is no unregisterTool(). To remove a tool, pass an AbortSignal in the second argument and call abort() on its controller. This is the same pattern many browser APIs use for cleanup, such as removing event listeners.

Since Chrome 153, removing a tool no longer cancels calls to it that are already running.

Methods that were removed

Early versions of the proposal had more methods. They are gone from the current spec:

Removed	When	Why or what replaced it
provideContext() and clearContext()	5 March 2026 (PR #132)	They could overwrite tools registered by other scripts.
unregisterTool()	27 March 2026 (PR #156)	Use the abort signal instead.

If a tutorial uses any of these, it was written for an older draft.

Sharing tools with other origins

Tools are hidden from other origins by default. An origin is the scheme, host and port of a site, such as https://example.com.

A tool becomes visible across origins only when both sides opt in:

• The page that registers the tool lists the caller’s origin in exposedTo, in the second argument to registerTool(tool, { signal, exposedTo }).
• The caller lists the tool’s origin in fromOrigins when it calls getTools().

Both lists accept only secure origins. A bad exposedTo origin throws SecurityError.

Reading and calling tools from the page

The ModelContext interface also has:

• getTools(): returns registered tools. Chrome returns them in alphabetical order.
• executeTool(tool, input): runs a tool with an input object. Chrome returns null if the call causes a navigation.
• Events: toolchange, toolactivated and toolcancel.

Since Chrome 156, listen for toolactivated and toolcancel on document.modelContext, not on window.

The declarative API: HTML forms as tools

The “declarative” API turns an existing HTML form into a tool by adding attributes. No JavaScript is needed for the basic case.

Chrome documents four attributes:

Attribute	Goes on	What it does
toolname	<form>	The tool’s name.
tooldescription	<form>	The tool’s description. Removing this or toolname unregisters the tool.
toolparamdescription	Form controls	Describes one input. If missing, Chrome falls back to the <label>, then aria-description.
toolautosubmit	<form>	When the agent calls the tool, the form submits. Without it, the user must press submit.

<form toolname="book_table"
      tooldescription="Book a table at the restaurant for a date and party size."
      toolautosubmit>
  <label for="date">Date</label>
  <input id="date" name="date" type="date" required
         toolparamdescription="The reservation date">
  <label for="guests">Guests</label>
  <input id="guests" name="guests" type="number" required
         toolparamdescription="Number of people, including the person booking">
  <button type="submit">Book</button>
</form>

Some other things Chrome documents for forms:

• SubmitEvent.agentInvoked is true when an agent submitted the form.
• SubmitEvent.respondWith() returns a result to the agent. Call preventDefault() first.
• The CSS pseudo-classes :tool-form-active and :tool-submit-active let you style a form while an agent uses it.

Important status note: on 8 October 2026 the declarative API was removed from the spec “for now” (PR #338). It now lives in the declarative API explainer and in Chrome’s implementation. Chrome still documents it. Treat it as less settled than the JavaScript API.

Which browsers support WebMCP?

Chrome supports WebMCP through a flag and an origin trial, and Edge has an origin trial; Mozilla’s position is neutral and WebKit’s position is oppose.

Browser support as of 24 October 2026.

Browser or agent	Status
Chrome	Flag for local testing; origin trial from Chrome 149 to 156; shipping planned for Chrome 157
Edge	Origin trial
Firefox	Mozilla position: neutral
Safari	WebKit position: oppose
Brave	Experimental support in Leo AI chat
ChatGPT Desktop	Listed as supported

An origin trial lets a site turn on an experimental feature for real visitors for a limited time. For the full details, flags and tools, see the WebMCP in Chrome guide.

Mozilla raised concerns about adversarial use and prompt injection, and called the “MCP” name “a strange and unnecessary branding decision”. As of 9 October 2026 a refreshed Mozilla position was pending. WebKit argues the gaps should be fixed in HTML and ARIA instead, and says an agent acting for a user “is, in effect, assistive technology”.

Security: what the spec warns about

The spec has a security section. It is non-normative, which means it gives guidance rather than rules. It names these risks:

• Prompt injection. Text in a tool’s description or output can try to steer the agent.
• Misrepresentation of intent. A tool called finalizeCart might actually buy. Agents cannot check what a tool does before calling it.
• Privacy leakage. Tools that ask for too many parameters can build a “personalization-to-fingerprinting pipeline”.

Mitigations in the spec include:

• Turn WebMCP off for a page with the header Permissions-Policy: tools=(). The feature is "tools" and defaults to 'self'. A cross-origin iframe needs allow="tools".
• Use untrustedContentHint and consequentialHint honestly.
• Agents should not trust a site’s descriptions or annotations on their own.

Chrome’s security guidance adds: “Only expose your tools to origins that you trust”. It also says it is “impossible to guarantee safety inside of a large language model”.

Who has announced WebMCP support

Only a few public, sourced announcements exist:

• Shopify (5 August 2026): tools are “live on every Liquid storefront” and in the Hydrogen developer preview, with “nothing to install or configure”. The tools include search_catalog, get_product, get_cart, update_cart and proceed_to_checkout, among others.
• Google I/O (19 May 2026): a logo wall showed several large brands. Google’s post says global consumer brands “are already experimenting”. A logo wall is not a statement that each brand has shipped.
• WordPress: the AI plugin has an open “Add WebMCP experiment” issue and a draft pull request. Nothing has shipped in core.

Is WebMCP the same as MCP?

No. WebMCP borrows the idea of tools from the Model Context Protocol (MCP), but it is a separate web API. MCP-B is a third name you may also see.

Name	What it is	Where it runs
WebMCP	A proposed web API that lets a page register JavaScript functions as tools for AI agents	In a browser tab; tools disappear when the tab closes
MCP (Model Context Protocol)	A protocol that gives AI agents tools, often over JSON-RPC	Usually on a server that keeps running
MCP-B	The name used by the WebMCP-org project, which publishes community npm packages such as @mcp-b/webmcp-polyfill and @mcp-b/webmcp-local-relay. They are not Chrome features and not part of either spec	Community code you add yourself; the local relay forwards a site’s tools to desktop MCP clients

Chrome recommends using both WebMCP and MCP. The WebMCP vs MCP guide compares them side by side.

A short WebMCP timeline

Date	Event
13 August 2025	Explainer first published
10 February 2026	Chrome: “WebMCP is available for early preview”
5 March 2026	provideContext() and clearContext() removed
27 March 2026	unregisterTool() removed
19 May 2026	API moves to document.modelContext; Google I/O announces the Chrome 149 origin trial
5 August 2026	Shopify turns on WebMCP for Liquid storefronts
8 October 2026	Declarative API removed from the spec for now
20 October 2026	New draft; fourth editor added

The spec tracker follows changes as they land.

What to do next

If you run a site, start by finding out what you already expose. Some platforms, such as Shopify, register tools for you. You can check your site for free to see which form tools your pages declare. Script tools need a browser to find. To build your own, read how to add WebMCP and browse the examples.

Questions people ask

What is WebMCP in simple terms?

WebMCP is a proposed web API that lets a web page offer JavaScript functions to AI agents as tools. Each tool has a name, a plain-language description and an input schema, so an agent can call it instead of guessing which buttons to click.

Is WebMCP a W3C standard?

No. The current text is a Draft Community Group Report from the Web Machine Learning Community Group, dated 20 October 2026. The spec itself says it is not a W3C Standard and is not on the W3C Standards Track.

Is it navigator.modelContext or document.modelContext?

It is document.modelContext. The API moved from navigator to Document on 19 May 2026, and Chrome's docs now use only document.modelContext.

How do I remove a WebMCP tool?

Pass an AbortSignal in the options of registerTool and call abort() on its controller when the tool should go away. The spec has no unregisterTool method any more.

Which browsers support WebMCP?

As of 24 October 2026, Chrome has a developer flag and an origin trial from Chrome 149 to 156, with shipping planned for Chrome 157. Edge has an origin trial. Mozilla's position is neutral and WebKit's position is oppose.

Sources

1. WebMCP, Draft Community Group Report (20 October 2026) (read 2026-10-23)
2. webmachinelearning/webmcp repository (README) (read 2026-10-23)
3. WebMCP implementation status (read 2026-10-23)
4. WebMCP declarative API explainer (read 2026-10-23)
5. WebMCP commit history (read 2026-10-23)
6. PR #132: remove provideContext and clearContext (read 2026-10-24)
7. Chrome for Developers: WebMCP (read 2026-10-23)
8. Chrome for Developers: WebMCP imperative API (read 2026-10-23)
9. Chrome for Developers: WebMCP declarative API (read 2026-10-23)
10. Chrome for Developers: Build secure WebMCP tools (read 2026-10-24)
11. Mozilla standards position on WebMCP (#1412) (read 2026-10-24)
12. WebKit standards position on WebMCP (#670) (read 2026-10-24)
13. Shopify changelog: WebMCP support for Liquid and Hydrogen storefronts (read 2026-10-24)
14. Chrome at I/O 2026 (read 2026-10-24)
15. WordPress AI plugin: Add WebMCP experiment (#448) (read 2026-10-24)