WebMCP in October 2026: Making a Website Usable by AI Agents, and What the Origin Trial Really Means

WebMCP lets a web page hand an AI agent a short list of things it can do, each with a name, a description and an input schema, instead of leaving the agent to work the page out from screenshots and the DOM. An agent that finds a check_order_status tool can call it with an order number. Without it, the agent has to find the right field and click the right button.

That is the promise. The state of play on 22 October 2026 is narrower than most write-ups suggest. WebMCP is a proposal from a W3C Community Group, not a standard. Chrome runs it as an origin trial, with no decision yet to ship it. One consumer agent calls the tools (the browser built into the ChatGPT desktop app), and that agent ignores the declarative form version which was dropped from the specification on 8 October. Safari's engine team opposes the proposal; Mozilla is neutral.

This article is for developers and product owners deciding whether to add WebMCP now. It covers what the API is, who calls it, how to switch it on for real visitors, how to write tools that do not hand an agent a loaded gun, and what to fix first if you want agents to use your site at all.

What WebMCP Is

The specification defines a JavaScript API on document.modelContext through which a page registers tools: "The WebMCP API enables web applications to provide JavaScript-based tools to AI agents." A tool has a name, a description and an execute callback, and optionally a title, an inputSchema (JSON Schema) and annotations. The page's own code runs when the agent calls the tool, with the user's session.

Three things about it are easy to get wrong:

• It is not a standard. The document is a Draft Community Group Report of the Web Machine Learning Community Group, and says so: "It is not a W3C Standard nor is it on the W3C Standards Track." Chrome's own documentation calls it "a proposed web standard". The report's date has been changing every few days in October; its editors are from Microsoft and Google.
• There is no MCP in it. The spec says pages using it "can be thought of as Model Context Protocol servers that implement tools in client-side script", and then that it "does not prescribe the format in which tools are exposed to the browser agent". Mozilla's review put it bluntly: "The name is misleading ... There is no MCP here." A WebMCP tool does not connect to your backend MCP server, and it does not replace one.
• It does not make you discoverable. Chrome's documentation lists the limitation itself: "Clients and browsers must visit a site directly to know if it has callable tools." WebMCP helps an agent that is already on your page. It does nothing for being found.

The API is limited to secure contexts and gated by a tools Permissions Policy whose default allowlist is 'self', so a cross-origin iframe cannot register tools unless the embedding page allows it.

Where It Stands on 22 October 2026

Chrome 156, the last release in the original trial window, reached the stable channel on 20 October 2026. Chrome 162, the end of the requested extension, is scheduled for stable on 2 February 2027. Whether the extension is live could not be confirmed from the trial console, so plan as if it is likely but not certain.

The extension request explains why Chrome wants more time: "OT feedback has suggested improvements to the API, which we are implementing." In the same thread, Google's Dominic Farolino wrote that the team is "hoping to move to I2S within the extension window", that is, to ask to ship, and that "The imperative API is a lot more popular than the declarative one, so we're investing more into it in response to user needs." He also mentioned a continuation API, a tool stability API and limits on tool size being prototyped. The API you write against today will change.

Who Actually Calls the Tools

Registering tools needs nothing. Using them needs an agent, and the list of agents is short.

Chrome's own test extensions. Chrome's documentation offers two extensions, including the Model Context Tool Inspector, to try tools in demos and your own pages. They need your own model API key, and Chrome notes: "These extensions are separate from Gemini in Chrome." They are developer tools, not customers.

ChatGPT's built-in browser. An OpenAI staff post on its developer forum said on 25 August 2026 that "Site tools are ChatGPT's implementation of the proposed WebMCP standard." Its documentation sets conditions: particular models, the latest desktop app, an admin allowing it in Enterprise workspaces, no Edu workspaces, and "Availability also depends on rollout". It also lists what it does not support: "Declarative API: Tools defined through HTML form attributes aren't available as site tools", and tools registered inside iframes, same-origin ones included. OpenAI's instruction is plain: "Use JavaScript to register tools in the top-level page". The documentation does not say whether a page needs a Chrome origin trial token for ChatGPT to see its tools.

Gemini in Chrome. Google said in May that it "will soon support WebMCP APIs". We found no primary source since then saying it does. Do not build a plan on it yet.

Everyone else falls back. Every agent in every browser still reads pages the old way. Chrome says so in its own risk assessment: "Browser agents in Chrome can continue to actuate sites as before by simulating user behaviors." OpenAI: "If no suitable tool is available, the agent may still be able to use its regular browser capabilities." A site without WebMCP is not invisible to agents. A site with broken buttons and unlabelled fields is hard for all of them.

The Imperative API

This is the version the specification defines, the one ChatGPT supports and the one Chrome says developers prefer. A tool wraps logic the page already has. Here is a read-only lookup for a signed-in customer, following the shape in Chrome's documentation and OpenAI's feature detection:

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

What matters in it:

• Name, description and schema are what the model reads. Chrome recommends at most 500 characters per tool description, 150 per parameter description, 30 per tool and parameter name, and 1.5K characters per tool output, and notes that "These recommendations are subject to change". The spec's explainer warns that "Exposing too many tools (e.g., dozens or hundreds) can severely degrade agent performance": register what the current page state needs, and remove the rest with the AbortController signal.
• The second argument to execute carries an AbortSignal, so a cancelled call can stop a request in flight.
• Annotations are hints. readOnlyHint marks a lookup. consequentialHint marks anything that books, buys, sends, deletes or transfers, and Chrome's documentation says it "allows agents and browsers to enforce mandatory user confirmation prompts". untrustedContentHint marks output that carries reviews, user content or third-party data. A debugging annotation exists from Chrome 156.
• Page code can list and run tools too, with document.modelContext.getTools() and executeTool(), and a toolchange event fires when the list changes. JSON-stringified arguments to executeTool() are deprecated from Chrome 155.

React, Angular and Vue each have experimental helpers, and the webmcp-types npm package provides TypeScript typings. Older tutorials that call navigator.modelContext are out of date: the specification moved the API to document on 27 May 2026.

The Declarative API: in Chrome's Trial, out of the Specification

The declarative version turns an existing HTML form into a tool with two attributes. It is attractive for old, form-heavy sites, because nothing else has to change:

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

In Chrome's trial, "When an agent calls toolname, the browser brings the form into focus and populates its field. The form remains visible to the user." The browser builds the parameters from the controls: their names, their <label>s, required and the options of a <select>. Unless the form carries toolautosubmit, "The user must manually click Submit to complete the task", which is what you want on anything that places an order or sends a lead. SubmitEvent.agentInvoked tells your handler an agent filled the form, and respondWith(), after preventDefault(), returns the outcome to the agent. Listen for the toolactivated and toolcancel events on document.modelContext with addEventListener: window.ontoolactivated and window.ontoolcancel are not supported from Chrome 156.

The catch is its status. The explainer's most recent change, on 8 October 2026, is titled "Remove declarative API from the spec for now", and now reads that a declarative counterpart "is being explored separately ... but it is not part of the specification at this time." ChatGPT does not support it. Chrome still documents it in the trial, and Google's Farolino argued in Mozilla's thread that "we see value in the declarative proposal simply for legacy websites, especially form-based". Treat it as a Chrome experiment inside an experiment: fine to try, unwise as your only route.

Turning It On for Real Visitors

A flag (chrome://flags/#enable-webmcp-testing) turns WebMCP on in your own browser for testing. It does nothing for visitors. For them, the page needs an origin trial token.

1. Register the origin at Chrome's WebMCP trial page. Origin trials "are public and open to all developers", and a token "enable[s] a feature for all users on your origin".
2. Serve the token on every page that should expose tools, as <meta http-equiv="origin-trial" content="..."> in the <head> or as an Origin-Trial: response header. A token can also be injected from script. One token covers one origin; a page can carry several.
3. Renew it. When a trial is extended, Chrome asks registrants to "provide a new token for each origin enrolled in the trial", and "Chrome ignores invalid or expired tokens". An expired token fails silently: the tools simply stop appearing.
4. For Edge, register separately on Edge's trial page. Its terms ask that "Where possible, you agree to apply feature detection / graceful degradation".

Lighthouse's WebMCP audits also need the trial registration, so a site testing them without a token will see them fail.

Writing Tools That Are Safe to Call

The specification's security section is non-normative, and it is candid about where the burden lies: preventing an agent from being manipulated "is primarily the responsibility of the agent's own security model rather than something this specification can normatively enforce." Your tools still decide how much damage a manipulated agent can do.

• Hints can lie, so agents will not trust them. The spec: "a malicious site can omit or misrepresent those hints." OpenAI: "A tool's name or claim that it only reads data isn't proof of what it does", and every call in its browser gets a safety review, with confirmation still required for purchases and similar actions. Annotate honestly anyway. It is what a careful agent uses to decide when to ask the user.
• Describe effects exactly. The spec's own bad example is a tool described as "Finalizes the current shopping cart" that "actually triggers a purchase. The user didn't intend to buy anything." If a tool charges a card, the description says so, and consequentialHint is true.
• Authorise on the server, every time. The tool runs with the user's session: the spec notes that "Agents are able to inherit user identity and authentication context from the browser." A tool call is a request from that user and gets the same checks. The explainer's advice holds: "Validate strictly in code, loosely in schema", because strict schema failures can make agents stall.
• Plan for prompt injection. The spec lists it first, in three forms: instructions hidden in tool metadata, in tool output, and attacks that use tools as targets. Output that carries text written by other people (reviews, messages, product questions) belongs under untrustedContentHint, and should be returned as data rather than prose an agent might take as instructions.
• Opt pages out deliberately. A Permissions-Policy: tools=() header makes the API unavailable to a document and everything it embeds. Account settings, payment pages and admin screens are candidates.

One caution on Chrome's documentation: its security page says the draft includes a requestUserInteraction() method for asking the user mid-tool. The 20 October 2026 draft of the specification has no such method, and the explainer still lists user confirmation as an open question. Do not design around it.

What Safari's and Firefox's Engineers Object To

The objections are worth reading even if you only build for Chrome, because they describe how WebMCP can go wrong in practice.

WebKit's position, posted on 3 June 2026, argues that hard-to-use pages should be fixed in HTML and ARIA, "where the user, assistive technology, and agents all benefit", and that with tools "the brittleness just moves from the DOM into the tool descriptions." It treats an agent as assistive technology that should not be singled out: "WebMCP does the opposite, making "an agent is driving" an observable fact." And it notes that the proposal "has no consent or reversibility model for consequential actions".

Mozilla settled on neutral in August: WebMCP "introduces a potentially valuable abstraction", but "opens a surface whose real-world dynamics leave too many open questions to wholeheartedly endorse". It warns that sites could "provide tools that do not match the experience of a user on the page", for example to "provide prompt injection that is invisible to typical users". Individual Mozilla engineers have shown interest in an imperative function-calling primitive; that is not a Mozilla endorsement.

Chrome itself rates the risk of other engines not adopting WebMCP as low for users. The other side of that is that a site gains nothing in Safari or Firefox from adding tools today.

What Works for Every Agent Today

Every browser agent reads screenshots, HTML and the accessibility tree. Google's web.dev guidance on agent-friendly sites says agents "use the DOM and accessibility tree to get a clean, structured list of interactive elements, and then cross-reference that with a visual rendering". Its practical list is short:

• Use real <button> and <a> elements, not clickable <div>s and <span>s.
• Link every <label> to its input with for.
• No transparent overlays over interactive elements, and nothing interactive smaller than 8 square pixels.
• A stable layout that does not shift while the agent is about to click.

Its conclusion: "Everything we suggest to make a site "agent-ready" also makes sites better for humans." This is also, nearly word for word, what WebKit asks for instead of WebMCP. If your checkout fails an accessibility audit, fix that before writing a single tool.

Lighthouse has had an Agentic Browsing category since version 13.2.0 (1 May 2026), available in Chrome from version 150, and enabled for the PageSpeed Insights API in Lighthouse 13.4.1 (20 July 2026). It checks the subset of accessibility audits that matter to machines, layout stability, registered WebMCP tools and forms without them, schema validity, and the presence of an llms.txt file. Chrome calls it "informational and unbenchmarked": there is no 0 to 100 score. On llms.txt, Google Search's own guidance is that it ignores such files: adding one "will neither harm nor help your site's visibility or rankings in Google Search". Lighthouse checking for the file does not change that.

Should You Add WebMCP Now?

On Shopify with a Liquid theme: no work. Shopify's storefront, cart and checkout tools are already live, "There's nothing to install or configure", with Shopify's own caveat that "agent support is currently limited to Chromium-based browsers through an origin trial". Headless storefronts are covered only on the Hydrogen developer preview. We found no other commerce platform, payment provider or CDN that turns WebMCP on for its customers.

On a custom, headless or legacy site: it depends on who your users are.

• If your customers or staff use the ChatGPT desktop app's browser, imperative tools in the top-level page are the only kind that reach them. Start with two or three read-only tools around your most common task (order status, availability, a quote), behind feature detection, with an origin trial token, and measure whether anyone calls them.
• If you want to experiment cheaply in Chrome, declarative attributes on existing forms are a few hours of work. Do not stop there: ChatGPT will not see them, and the specification no longer contains them.
• If you have no evidence that agents visit you, fix semantics, labels and layout first. That work helps every agent and every person using assistive technology, and nothing about it will be thrown away when the API changes.

In every case, keep the normal interface complete. OpenAI's advice: "Preserve the normal interface for people and browsers that don't support WebMCP."

What Could Change

• An Intent to Ship. Chrome's team hopes to ask within the extension window, which ends with Chrome 162 (2 February 2027) if the extension stands. Shipping would remove the need for tokens in Chrome.
• API shape. A continuation API (results that land on the next page after a navigation), a tool stability API and size limits are being prototyped. Recent releases already removed window.ontoolactivated and stringified arguments.
• The declarative API's fate. Out of the specification "for now", still in Chrome's trial.
• Callers. Gemini in Chrome support has been announced but not shipped. The specification's implementation status page lists WebMCP for web apps on Meta's Ray-Ban Display glasses as coming soon, and experimental support in Brave's Leo assistant.

If you add tools now, keep them in one module, behind feature detection, so the next change is one edit.

Where to Get Help

We build the parts of a website and its backend that agents touch: tools that wrap existing order, booking and account logic, authorisation that treats an agent's call like any other request from that user, and the semantic and accessibility fixes that make a site usable before any tool exists. Our AI agent development and MCP integration service covers WebMCP tools as well as backend MCP servers, which are a different thing despite the name.

If you want to know what an agent sees on your site today, and whether tools would change anything for your customers, write to office@c9group.dev.