WebMCP origin trial: what it is and why a small busines...

A visitor asks the AI assistant in their browser: "What does a weekly room cost here, and can you start the booking for Friday?" Today the assistant usually reads your page the way a person skimming on a phone would. It hunts for a price, guesses which number is current, and maybe gives up on the form.

WebMCP changes that. It lets your site hand the assistant a short list of real tools: "get the rates", "check what's open", "fill in the request form". The assistant calls the tool, gets your exact answer, and leaves the form filled in for the person to check and send.

Chrome is testing WebMCP right now in what Google calls an origin trial. Your tools only switch on in ordinary Chrome if your site carries a small signed token from Google. The token is free and takes about five minutes to get. I registered thirty sites in one evening and checked every token's signature before shipping. This post explains the whole thing in plain English: what the trial is, how the token works, what it gets a small business, how to label your forms so an assistant understands them, and how to get an MCP server ready for the Claude directory. It ends with the honest limits.

What WebMCP lets an assistant do on your site

WebMCP is a draft web standard from a W3C Community Group, with engineers from Google and Microsoft among its editors. Your page runs a few lines of JavaScript that register "tools". Each tool has a name, a sentence saying what it does, the inputs it takes, and the code that answers. An assistant built into the browser sees the list and can call a tool instead of guessing from the page.

For a small business the useful tools are boring, and that is the point:

Read tools. Current rates, deposits, hours, service area, what's in stock or available this week. The answer comes from the same data the page shows, so the assistant quotes your number, not a stale one it found elsewhere.
Fill tools. "Prepare a service request", "start a reservation", "draft a question for the owner". The tool fills in your existing form and stops. The person reviews it and presses Send.

That second rule matters more than anything else in this post. The assistant fills, the person sends. I wrote about why in the fill, never send article, and the same rule shapes every example below.

The origin trial and the token

An origin trial is how Chrome lets real websites use a feature before it's final. Google opens the feature to sites that sign up, watches how it gets used, and changes the design based on what it learns. "Origin" just means your site's address: the scheme, the host name and the port, like https://example.com.

Registering takes five minutes.

Sign in at the Chrome Origin Trials console with a Google account.
Find WebMCP in the list of active trials and press Register.
Type your origin, for example https://example.com. If visitors land on www.example.com, either register that exact address or tick "I need a token to match all subdomains of the origin" so one token covers both.
Pick an expected usage (most small sites are in the lowest band) and tick the four acknowledgements. They say the feature is experimental, may change, may be switched off if it's used on more than a small share of all Chrome page loads, and that your site should still work without it.
Press Register. The console shows your token.

The token is a signed note from Google. It is a long string of letters and digits. Inside it is a short piece of text naming your origin, the feature (WebMCP) and an expiry date, plus a digital signature that Chrome checks with Google's public key. Nobody can edit the origin or the date without breaking the signature, which is why a token copied from another site does nothing on yours. The token is public by design. It sits in your page for anyone to read, and that's fine.

You put it in one of two places. Either send it as a response header on your pages:

Origin-Trial: PASTE-YOUR-TOKEN-HERE

On Netlify that's two lines in a _headers file:

/*
  Origin-Trial: PASTE-YOUR-TOKEN-HERE

Or add a meta tag inside the <head> of every page:

<meta http-equiv="origin-trial" content="PASTE-YOUR-TOKEN-HERE">

The meta tag has to be in the head. Chrome ignores one placed in the body, and nothing warns you. The header avoids that trap, so I use it wherever the host allows custom headers.

How long it lasts. The WebMCP trial runs from Chrome 149 to Chrome 162, and the console lists its end date as March 29, 2027. Tokens issued now carry that expiry. If Google extends the trial again you'll need a fresh token, and the console emails a reminder.

What happens without one. Your registration code still runs, but ordinary Chrome doesn't expose the API, so no assistant ever sees your tools. When I surveyed thirty of my own sites that already shipped WebMCP tools, not one sent a token. Every tool on every one of them had been inert for regular visitors.

What a small business actually gets

Concrete examples, all of them fill-only or read-only:

A motel or short-stay rental. "What's the weekly rate, is tax included, and is there a room this Friday?" The read tool returns the posted rates and rules. The fill tool opens the reservation form with the dates and party size filled in. The guest confirms.
A self-storage facility. Unit sizes, monthly prices, refundable deposits and gate hours come straight from the rates table. A tenant's maintenance or move-out request gets filled for them to send.
A handyman, cleaner or contractor. "Do you serve my town, and how do I book?" The tool returns the service area and opens the request form with the job described in the customer's words.
A shop or café. Hours, holiday closures, the current menu or what's in stock, without the assistant guessing from a photo of a chalkboard.

The payoff is accuracy. An assistant that calls your tool quotes your price and your rules, and the person still makes the final call. The cost is one token and a few lines of code you may already have.

Label your forms so an assistant understands them

You don't need JavaScript to make a form agent-ready. Chrome reads a few extra HTML attributes on a normal form (this is the "declarative" half of WebMCP) and turns the form into a tool by itself:

<form action="/request" method="post"
      toolname="request_service"
      tooldescription="Prepare a repair request. The person reviews it and presses Send.">
  <label>Name
    <input name="name" required toolparamdescription="Full name of the person asking">
  </label>
  <label>Phone
    <input name="phone" type="tel" toolparamdescription="Callback number, digits only">
  </label>
  <label>What needs fixing
    <textarea name="details" toolparamdescription="The problem and where it is, in a sentence or two"></textarea>
  </label>
  <button>Send request</button>
</form>

Three rules make it work:

toolname and tooldescription both go on the <form>. Chrome skips a form that has only one of them.
Each visible field gets a toolparamdescription. The field's name becomes the parameter name, and the description tells the assistant what belongs there. Skip hidden fields and spam traps.
Leave out toolautosubmit on anything that sends a request, books, buys or shares personal details. Without it, Chrome fills the form, moves focus to your Send button and lets the person press it. With it, the assistant can send the form on its own. Chrome's documentation presents it as a choice; for a small business, keep the person in charge.

Two honest notes. The declarative attributes were taken out of the WebMCP draft specification on October 8, 2026 while the editors rework them, yet Chrome still ships them under the same origin trial, so they work today and may be renamed later. And Lighthouse, the audit built into Chrome DevTools, now has an experimental Agentic browsing category with a "WebMCP form coverage" audit that counts these forms. Google calls the category informational and unbenchmarked, so treat it as a checklist, not a score to chase.

If you run an MCP server: get ready for the Claude directory

WebMCP lives in the browser. Some businesses also run a small MCP server, a web address that any assistant (Claude, ChatGPT, a coding tool) can connect to directly. Anthropic lists approved servers in the Claude Connectors Directory, and its submission page sets a clear bar: every tool needs a title and a readOnlyHint or destructiveHint annotation, and the portal flags tools that lack them. Tool names must be 64 characters or fewer.

A tool definition that passes looks like this:

{
  "name": "get_rates",
  "title": "Get room rates",
  "description": "Nightly and weekly rates as the site publishes them, and whether tax is included.",
  "inputSchema": { "type": "object", "properties": {}, "additionalProperties": false },
  "annotations": {
    "title": "Get room rates",
    "readOnlyHint": true,
    "destructiveHint": false,
    "openWorldHint": false
  }
}

I set the title in both places, at the top level and inside annotations. The MCP specification shows the top-level title first, while Anthropic's checklist just says "title" without saying which, and setting both costs nothing. The hints aren't decoration either: Claude uses them to decide what it may run without asking the person.

The listing itself also needs a paid Claude plan to submit, a privacy policy URL, a documentation URL, a support contact and an icon. The server must run over https using the Streamable HTTP transport, and it needs OAuth only if its tools act on a customer's account. A server that only reads public information can go without sign-in.

Safari, Firefox and Edge

WebMCP is not everywhere, and it may never be. Here's where each browser stands as of October 2026, and what that means for a small site.

Chrome. The origin trial described above, Chrome 149 to 162. Your Chrome token turns the tools on.
Microsoft Edge. Edge 150 runs its own WebMCP origin trial, listed through March 2027, with its own console (you sign in with GitHub) and its own token. A Chrome token does nothing in Edge. Edge tokens are shorter lived: the ones issued in October 2026 expire on November 30, 2026, and you renew them in Edge's console. Register in both consoles and put both tokens on the page; Chrome and Edge each use the one meant for them and ignore the other. Microsoft engineers co-edit the WebMCP draft, and Microsoft's Edge team says its implementation "is ready for testing."
The ChatGPT desktop app. Its built-in browser calls WebMCP tools "site tools". It reads tools registered in JavaScript on document.modelContext and, per OpenAI's documentation, ignores the declarative form attributes. So if ChatGPT matters to you, register your key tools in code as well as labelling your forms.
Safari. No WebMCP. Apple's WebKit team formally opposed the proposal in June 2026, arguing that what agents need belongs in plain HTML and accessibility markup. Safari 27 does ship an MCP server, but it's a developer tool for testing your own pages. It's off until you switch it on in Safari's settings, and it gives coding assistants a way to drive Safari. It doesn't let websites offer tools.
Firefox. Mozilla's position is neutral. A prototype exists in Firefox's code behind a setting that is off by default, and it uses the older navigator.modelContext name. Mozilla's own developer MCP server is, again, a testing tool.

What this means in practice:

Write the code so it's harmless where WebMCP is missing. Check for the API before using it, prefer document.modelContext and fall back to navigator.modelContext. That covers Chrome 152 and later, Edge, ChatGPT, Chrome 149 to 151 and Firefox's prototype, and it does nothing at all in Safari:

const mc = document.modelContext || navigator.modelContext;
if (mc && typeof mc.registerTool === 'function') {
  mc.registerTool({
    name: 'get_rates',
    title: 'Get room rates',
    description: 'Nightly and weekly rates as the site publishes them, and whether tax is included.',
    inputSchema: { type: 'object', properties: {}, additionalProperties: false },
    annotations: { readOnlyHint: true },
    execute: () => ({ nightly: 79, weekly: 329, tax_included: false })
  });
}

Make the page itself easy to read. Safari, Firefox and most assistants that don't use WebMCP work from your HTML: real <label> elements on form fields, clear headings, prices in text rather than images. WebKit's objection boils down to "do this well first," and it's good advice in every browser.
Offer a server-side door if you can. An MCP server at your own address (the previous section) works for assistants regardless of browser.

The Mega Analyzer reports all of this in one row, "Agent paths by browser", and a second row checks that your WebMCP code is guarded and uses the current API first.

The honest limits

It's a trial. Google says plainly that the feature may change or be withdrawn, and the API already has. It moved from navigator.modelContext to document.modelContext, an older provideContext() call was removed, and the declarative attributes left the draft for rework. Expect to touch this code again.
Assistants that use it are still arriving. Google said at I/O in May 2026 that Gemini in Chrome "will soon support WebMCP APIs." Its current documentation describes WebMCP testing tools as separate from Gemini in Chrome. Registering now means your tools are ready when the assistants are, not that every visitor's assistant uses them today.
One token per origin. example.com and www.example.com are different origins unless you ask for subdomain matching. A staging copy on another host needs its own token.
It expires. Put each token's date in your calendar: March 29, 2027 for the Chrome tokens issued now, November 30, 2026 for Edge's.
Your page still has to work without it. Every tool should be a shortcut to something a person can already do on the page. If the API is missing, nothing breaks.

How to check your own site

The free Mega Analyzer on this site now checks all three things. It decodes any origin-trial token your page sends and verifies its signature, origin, feature and expiry. It lists every form missing the declarative labels. If you run an MCP server it checks that each tool has a title and a behavior hint. The WebMCP Readiness Checker runs the token check on its own, and the Agent Endpoint Inspector covers the MCP server side.

Each finding links to a step-by-step fix guide you can work through yourself or hand to an AI coding assistant: the WebMCP fix guide. If you look after more than one site, the portfolio playbook covers how I surveyed, registered, rolled out and verified thirty sites in one pass, including the two small scripts I used.

If you'd rather market your own business with inexpensive AI tools than pay a monthly agency retainer, that's what The $20 Dollar Agency is about.

Fact-check notes and sources

Trial window and end date: Chrome Origin Trials console, WebMCP trial page, read October 16, 2026: "Chrome 149 to 162", end date March 29, 2027. developer.chrome.com/origintrials
Trial and feature status: Chrome Platform Status, WebMCP and the Chrome blog post announcing the trial (June 9, 2026).
Header or meta tag; the meta tag must be in the head: Get started with origin trials and Chromium's http_equiv.cc, which only handles the origin-trial meta tag inside the head.
Token format and signature: Chromium trial_token.cc. The signature covers the version, length and payload. I verified the signature on all thirty tokens I was issued against Chrome's public key before deploying them.
document.modelContext and registerTool: the WebMCP specification draft and its repository (spec commit "Move the modelContext getter to Document", May 27, 2026). Chrome's imperative API guide uses document.modelContext.
Declarative attributes and toolautosubmit: the declarative API explainer and Chrome's declarative API guide. Removal from the draft: spec commit "Remove declarative API from the spec for now" (October 8, 2026).
Lighthouse Agentic browsing: Lighthouse docs and the agent-ready toolkit post ("informational and unbenchmarked").
Gemini in Chrome: Chrome at I/O 2026, May 19, 2026, and the WebMCP overview.
Claude directory requirements: Anthropic's connector submission guide, review criteria and the directory policy.
Tool titles and annotations: MCP specification 2026-07-28, Tools.
Draft editors and status: the WebMCP specification, a Draft Community Group Report of the Web Machine Learning Community Group, edited by engineers from Microsoft and Google; "not a W3C Standard nor is it on the W3C Standards Track."
Edge's own trial, and Chrome tokens in other browsers: Microsoft Edge Origin Trials, WebMCP (expiry shown as March 29, 2027, read October 16, 2026), Edge's origin trial guide, and Chrome's origin trial troubleshooting: Chrome tokens "won't enable features in other browsers". The WebMCP implementation status notes the trial is live in Edge 150. Microsoft's Edge developer blog, September 21, 2026.
ChatGPT site tools: OpenAI's WebMCP page: reads document.modelContext; "Tools defined through HTML form attributes aren't available as site tools."
Safari: WebKit standards position on WebMCP (oppose, June 2026) and Introducing the Safari MCP server for web developers (July 1, 2026; needs "Allow remote automation and external agents").
Firefox: Mozilla standards position (neutral), the prototype tracked in bug 2018306 behind the off-by-default dom.modelcontext.enabled setting, and Firefox DevTools MCP.

Let AI assistants use your website: the WebMCP origin trial explained for small businesses