WebMCP: What It Is and Whether a Software Vendor Should Ship It

WebMCP is a proposed browser API that lets a web page give AI agents named tools. Instead of reading a demo form and guessing which box is which, an agent calls a tool such as request_demo with the buyer’s details. This guide reads the draft specification, Chrome’s and Microsoft’s documentation, OpenAI’s developer page and the browser makers’ standards positions, as they stood on 2026-11-03.

It covers what WebMCP is, how it differs from MCP, who supports it and what a property-ops software vendor would expose. It ends with a recommendation. The page-level groundwork comes first, and the agent legibility guide covers it.

What is WebMCP?

WebMCP is a JavaScript API, plus a set of HTML form attributes, that turns parts of a page into tools an agent can call. The draft specification says “The WebMCP API enables web applications to provide JavaScript-based tools to AI agents.” Each tool has a name, a description, an input schema and a function that runs in the page.

The draft describes pages that use WebMCP as something that “can be thought of as Model Context Protocol” servers whose tools run in client-side script rather than on a backend. The browser sits in the middle and passes the tool list to whichever agent is working in the tab.

Who writes it, and how settled is it?

The draft is a Community Group report from the W3C Web Machine Learning Community Group, edited by two engineers from Microsoft and two from Google. The version of 2 November 2026 says “It is not a W3C Standard nor is it on the W3C Standards Track.”

Chrome’s documentation calls WebMCP “a proposed web standard to help you build and expose structured tools for AI agents,” which can be added as a progressive enhancement. The API’s name has already moved once. The current draft hangs it on document.modelContext; earlier examples used navigator.modelContext.

How is WebMCP different from MCP?

MCP connects an AI application to a service from outside the browser; WebMCP lives inside one open page. The Model Context Protocol site calls MCP “an open-source standard for connecting AI applications to external systems.” Chrome’s comparison page says “WebMCP is not an extension or a replacement of MCP.”

	MCP server	WebMCP tools
Where the tools run	On a server you host	In your page’s own script
When they exist	Whenever the server is up	Per Chrome, “only while the user is on your page”
Whose login	The server’s own credentials	The user’s current browser session
Who calls them	Any MCP client you allow	The agent working in that browser tab
Typical vendor use	An integration for customers’ AI tools	A demo request or pricing lookup for a buyer’s agent

Chrome’s page sums it up as “WebMCP tools are ephemeral.” For a vendor that matters: a tool helps only an agent that is already on your page, so being found still comes first.

Which browsers and agents support WebMCP today?

Two browsers run trials, one agent uses it in production, and two browser engines have not signed on. The table reflects documents read on 2026-11-03.

Who	Status	Source
Chrome	Origin trial, versions 149 to 156; extension to 162 requested	Chrome’s intent to experiment and intent to extend on blink-dev
Microsoft Edge	Origin trial; Microsoft’s trial page gives an expiry of 30 March 2027	Microsoft Edge origin trials page
Firefox (Mozilla)	Standards position: neutral	mozilla/standards-positions issue 1412
Safari (WebKit)	Standards position: opposed	WebKit/standards-positions issue 670
ChatGPT desktop app	Calls WebMCP tools in its built-in browser	OpenAI developer documentation
Gemini in Chrome	Announced as coming	Chrome’s Google I/O 2026 post

OpenAI’s developer page says “Site tools are ChatGPT’s implementation of the proposed WebMCP standard.” It adds that “Site tools currently run only in the ChatGPT desktop app’s built-in browser.”

Chrome’s Google I/O 2026 post says “Gemini in Chrome will soon support WebMCP APIs.” No later Google page we read confirms it has shipped.

Why Mozilla and WebKit hold back

WebKit’s position thread says “WebKit is opposed to this proposal.” Its reasoning: “When a site’s actions are hard for an agent to use, that is a gap in the page’s own semantics,” which WebKit would fix in HTML and ARIA. Mozilla proposed a neutral position and would “come back to revisit it once there is more evidence of how it will be used by sites.”

How much it is used

Chrome’s request to extend the trial reported trial registration on “approximately 0.51% of all Chrome page loads,” with actual tool calls “orders of magnitude lower than the page registration rate.” The same thread says “The imperative API is a lot more popular than the declarative one.”

How do you turn a demo form into a WebMCP tool?

Add two attributes to the form and, optionally, one to each field. Chrome documents this declarative route as toolname, tooldescription and toolparamdescription. The spec itself covers only the JavaScript API; the README says the declarative form is explored separately.

<form action="/demo/" method="post"
      toolname="request_demo"
      tooldescription="Sends a demo request to the sales team for a property management company.">
  <label for="name">Name</label>
  <input id="name" name="name" required>

  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>

  <label for="doors">Doors managed</label>
  <input id="doors" name="doors" type="number" min="1">

  <label for="pms">Property management system</label>
  <select id="pms" name="pms"
          toolparamdescription="The PMS the company runs today, used to route the demo.">
    <option>AppFolio</option><option>Buildium</option><option>Entrata</option>
    <option>RealPage</option><option>Rent Manager</option><option>Yardi</option>
  </select>

  <button type="submit">Request a demo</button>
</form>

That is our example, written to Chrome’s attribute names. Chrome’s guide says “When an agent calls toolname, the browser brings the form into focus and populates its field. The form remains visible to the user.”

It also says “The user must manually click Submit to complete the task” unless the form carries toolautosubmit. For a demo request, leave that off so the buyer confirms what is sent.

The labels do double duty

Chrome’s guide says that without toolparamdescription, “the browser uses the content within the associated <label>” to describe the field. So a form with real <label for> elements is already most of a WebMCP tool. A form labeled only by placeholder text is not, for WebMCP or for any other agent.

How do you register a tool in JavaScript?

Call registerTool on document.modelContext, after checking it exists. This example is copied from OpenAI’s developer documentation; it registers a read-only tool that returns the page title.

if (typeof document.modelContext?.registerTool === "function") {
  await document.modelContext.registerTool({
    name: "get_page_title",
    description: "Read the title of the current page.",
    inputSchema: {
      type: "object",
      properties: {},
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    execute: async () => ({ title: document.title }),
  });
}

The check means browsers without WebMCP skip the block, so the page keeps working for everyone else. OpenAI’s guidance is to “Keep inputs narrow, describe side effects, and return enough information to verify the result.” It also says to “Preserve the normal interface for people and browsers that don’t support WebMCP.”

The annotations tell the agent what kind of tool it is calling. The read-only hint marks a tool that changes nothing. The consequential hint marks one where “executing the tool will result in consequential actions that are significant, real-world, or non-reversible,” per the draft.

What tools should a property-ops software vendor expose?

Three at most, each doing one job a buyer’s agent is sent to do. Chrome’s best-practices page says “Each tool should consist of a single function.” Its use-case guidance says WebMCP can “help an agent more quickly navigate to the right form and fill in fields with user-provided information.”

1. request_demo. The demo form, annotated as above. Not read-only; leave submission to the buyer.
2. get_pricing. Read-only. Takes doors or units and returns the price model and starting price you already publish, in text.
3. check_integration. Read-only. Takes a PMS name and returns whether you integrate with it and how deeply.

Each one returns facts the page should already state as text. A tool that returns a price the page hides gives an agent something a person cannot check, which is a reason not to trust it. Chrome’s best practices also say “Validate strictly in code, loosely in schema.”

What are the risks?

The draft names them plainly. Its security section lists “No verification mechanism”: agents cannot verify that a tool does what its description says. It also warns that “a malicious site can omit or misrepresent those hints.”

That cuts both ways for a vendor. Agents have reason to treat your tools with suspicion, so a vague or overreaching tool is likely to be ignored. Chrome’s guidance to agent builders says “Assume WebMCP tools mutate state, unless the tool description or annotations (readOnlyHint) clearly state otherwise.”

The draft adds that “By default, WebMCP enforces strict same origin isolation.” A demo form embedded from a marketing platform in a cross-origin iframe is a separate origin, so it needs explicit permission before its tool reaches the agent on your page.

Should you ship WebMCP now?

Ship the HTML first, then add WebMCP attributes to the demo form if your web team has an afternoon. Today one production agent calls these tools, and only inside one desktop app. Every agent, and every buyer, reads a labeled form.

The cost of the declarative attributes is small and they degrade to nothing in browsers that ignore them. The cost of a JavaScript tool layer is a second interface to keep in step with the first. Hold that until Gemini in Chrome or another major agent ships support.

Our working assumption is that WebMCP will help most the vendors whose pages were already legible, since the tool and the page share the same facts.

What the Index shows

The Index does not measure WebMCP. It captures search-grounded answers from ChatGPT and Claude, the step before any agent opens a vendor’s site. The Index methodology explains what each edition captures.

Limits

This page is documentation, read on one day. Every quoted sentence comes from a page named in the sentence, and those pages change often: the API’s name moved from navigator to document in May 2026. We have not tested a WebMCP tool against any agent for this page.

OpenAI’s help-center article on site tools could not be read on 2026-11-03, so this page relies on its developer documentation. Chrome’s pages and the spec disagree in places. Chrome documents the declarative form attributes; the spec does not include them yet.

What changes month to month?

Watch the trial dates. Chrome’s trial ends at version 156 unless the extension to 162 is granted, and Edge’s trial page gives 30 March 2027. A trial that ends without a shipping decision turns the attributes off.

Then agent support. Gemini in Chrome is announced, not shipped. Anthropic, Perplexity and Microsoft had published nothing on WebMCP use by their agents on 2026-11-03.

Related guides

The agent legibility guide covers what browser agents read on a page without WebMCP. The structured data guide covers the markup the same facts belong in, and the AI crawlers and robots.txt guide covers which bots reach the page at all. The agentic commerce guide covers agents that pay as well as browse.

The pillar on getting named by AI assistants puts these in order.

Changelog

• 2026-11-03: Published at this address, which returned 410 Gone after the September 2026 rebuild. Documentation read on 2026-11-03.