WebMCP has spent 2026 moving from a Google I/O announcement to an origin trial to something Chrome expects to ship in version 157, projected for early November. It lets your website hand structured tools to an AI agent instead of making the agent guess which button submits the form. The interesting question is not what it is. It is whether a business that is not Expedia should spend anything on it yet.
WebMCP is a proposed web standard that lets a page register typed tools an in-browser AI agent can call directly, through a navigator.modelContext JavaScript API. It is in origin trial in Chrome 149 to 156 with shipping anticipated in Chrome 157, Edge runs its own trial, ChatGPT's desktop browser already calls these tools, and WebKit opposes the design as it stands. For most businesses the right move today is the prerequisite work, not the implementation.
What WebMCP actually is
WebMCP lets a web page declare a set of tools, named functions with a described purpose and a typed input schema, that an AI agent running in the browser can call. Instead of an agent reading a screenshot, inferring that the third button is "search" and typing into a field it hopes is the right one, it calls search_products with a validated query parameter and receives structured data back.
In the current Chrome trial that looks roughly like this:
navigator.modelContext.registerTool({
name: "check_availability",
description: "Check whether a date is available to book",
inputSchema: {
type: "object",
properties: {
date: { type: "string" },
service: { type: "string" }
}
},
execute: async ({ date, service }) => {
const slots = await bookings.lookup(date, service);
return { available: slots.length > 0, slots };
}
});The shape of that API has already changed during the trial, so treat any implementation written today as provisional rather than permanent. The concept is stable; the method names are not.
Two things it is not. It is not a replacement for a public API, the tools run inside the user's own browser session, with the user's own login, on the page they are already on. And it is not a document format like a sitemap or llms.txt: nothing about registering a tool tells a search engine or an assistant that your page exists.
Where it actually stands, as of late September 2026
Most coverage of WebMCP is written as though it were already a standard. It is not. Here is the honest state of play.
| Surface | Status | What that means for you |
|---|---|---|
| Chrome | Origin trial, Chrome 149 to 156. Shipping anticipated in Chrome 157 (projected early November 2026) | You can run it on production traffic today by registering for the trial. "Anticipated" is a target, not a commitment |
| Microsoft Edge | Its own origin trial, open through 17 November 2026 | A second engine experimenting is a meaningful signal; it is still an experiment |
| Safari / WebKit | Opposed to the proposal in its present form | Assume no iPhone or iPad Safari support for the foreseeable future |
| Firefox / Mozilla | Neutral | Neither a blocker nor a commitment |
| ChatGPT desktop | Shipped as "Site tools" in its built-in browser, August 2026 | The largest real-world consumer of these tools today is not a browser vendor |
| W3C | A Web Machine Learning Community Group draft, not a Recommendation | The spec can still change materially |
Google has named Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart and Target among those experimenting. Read that list carefully, because it is the clearest guidance available: every one of them is a site where the user's core job is a structured transaction with parameters, a date, a route, a filter, a form with real consequences. None of them is a brochure site.
The thing most explainers get wrong: this is not SEO
The most common misreading is that WebMCP is the next lever for AI visibility, in the same bucket as structured data or llms.txt. It is not, and getting this straight saves you from spending an SEO budget on an engineering problem.
There are three separate layers, and they fail independently:
| Layer | Question it answers | What you do about it |
|---|---|---|
| Findable | Can an engine or assistant discover the page at all? | Crawlability, internal links, indexing, HTML-first content |
| Citable | Will an AI answer use this page as a source? | Direct answers, primary evidence, clear entities, answer and generative engine optimisation |
| Operable | Once an agent is on the page, can it actually do the thing? | WebMCP, clean semantic forms, stable identifiers |
WebMCP only addresses the third. It does nothing for the first two. An agent that never arrives cannot call your tools, which is why "add WebMCP" is never the first move for a site that is not already being found and cited. The reverse is also true and more uncomfortable: if agents are arriving and failing to complete tasks, no amount of content work fixes that, because the failure is mechanical.
That third layer is also where the money is. Being cited earns a mention; being operable is what turns an agent session into a booking. The same split showed up in agentic checkout, where AI-referred traffic converted well while in-assistant checkout converted badly, the demand was real, the mechanics were not.
Should your site do this? Five questions
Score one point for each yes. This is the framework we would apply before quoting anyone for the work.
- Does your site have a task with parameters, not just pages to read? Booking a slot, checking stock in a size, filtering by spec, getting a quote, looking up an order. If the answer is "people read about us and then call", score zero and stop here.
- Do you already see meaningful assistant-referred traffic? Check your analytics for referrals from AI assistants over the last quarter. If it is a rounding error, the ceiling on this work is a rounding error too.
- Is the task painful for an agent to do by clicking? Multi-step flows, dynamic filters, anything behind JavaScript state. A single-field search box is already easy to operate without WebMCP.
- Do you control your front-end code? A custom build or a theme you can extend, yes. A locked SaaS site template where you cannot add scripts, no.
- Can you afford to maintain a provisional API? The spec is still moving. If nobody will own a small rewrite in six months, the tools will silently rot.
| Score | Verdict | What to actually do |
|---|---|---|
| 0 to 1 | No | Ignore WebMCP entirely. Your wins are at the findable and citable layers |
| 2 to 3 | Not yet | Do the prerequisite work below. Revisit when Chrome ships it and your assistant traffic is measurable |
| 4 | Pilot | One tool, one flow, behind the origin trial, measured. Not a project |
| 5 | Yes | Build it properly now, with a named owner and a review date |
What to expose first, and what to never expose
The instinct is to expose everything the site can do. That is the wrong instinct, because every tool you register is a function a model decides when to call, on behalf of a user who may not have read the parameters.
| Site type | Expose first | Never expose |
|---|---|---|
| Lead generation / services | Check availability; look up pricing for a configuration; submit an enquiry with explicit confirmation | Anything that books a paid slot or sends a contract without a human confirming |
| E-commerce | Search the catalogue; check stock and size; check delivery options for a postcode | Placing the order, applying store credit, changing a saved address or payment method |
| SaaS or logged-in product | Read-only lookups: order status, usage, plan details | Anything that deletes data, changes billing, invites users or alters permissions |
| Content or media | Structured search and filtering across your archive | Subscription changes, cancellations, anything touching a payment relationship |
The rule that survives contact with reality: read freely, write narrowly, never spend. A tool that costs money, deletes something or changes an account should either not exist or should return a confirmation step to the user rather than completing the action. That is not paranoia about AI, it is the same principle that stops you exposing a destructive endpoint to any client you do not control.
If you score 4 or 5, ship exactly one read-only tool on your highest-intent flow, behind the origin trial, and instrument it: how often it is called, by what, and what happens next in the session. One measured tool tells you more about whether this matters to your business than a full implementation built on a guess.
The prerequisite work is the actual recommendation
Here is why "not yet" is a useful answer rather than a cop-out. Everything that makes a site easy to expose through WebMCP is work that pays off regardless of whether the standard ships, sticks, or gets replaced by something with a different name in 2027.
- Real forms with real semantics. Labelled inputs, correct types, meaningful names, working validation, a submit that works without JavaScript gymnastics. Agents read these. So do screen readers, autofill and browsers.
- A genuine search or filter endpoint. If your product search is a front-end filter over a fully loaded list, you have nothing to expose. Fixing that helps page speed as much as it helps agents.
- Stable identifiers. Product, location and service IDs that do not change when marketing rewrites a page title. This is also what stops your feeds and analytics breaking.
- Accurate structured data. Same
schema.orgmarkup that earns rich results, describing the same entities your tools would return. - A front end you can actually modify. The most common blocker we see is not technical difficulty. It is a site nobody can safely change.
Do those five and the WebMCP implementation itself is a few days of work whenever you decide it is worth doing. Skip them and it is a rebuild wearing a new acronym. That is the same order of operations we argue for in the SEO and web design playbook: structural quality first, surface features second.
What this means if you are commissioning a build right now
Do not accept "WebMCP-ready" as a line item on a proposal in 2026. There is nothing to certify against, the spec is a community group draft, one major engine opposes it, and the shipping version may differ from what is in the trial today. A vendor charging for readiness against a moving draft is charging you for their own learning.
What is reasonable to ask for, and worth paying for: semantic forms, a real search endpoint, stable IDs, accurate structured data, and a front end your team can extend without a rebuild. Ask a prospective web development partner how they would expose a single booking or stock-check tool on the site they are proposing. You are not buying the tool. You are finding out whether the architecture they are selling you could support one at all, which is a good proxy for how it will handle the next four things nobody has announced yet.
Frequently asked questions
What is WebMCP in plain terms?
WebMCP is a proposed web standard that lets a page register named tools with typed inputs that an AI agent running in the browser can call directly. Instead of an agent reading the screen and guessing which button submits a form, it calls a function such as check_availability with validated parameters and gets structured data back. Tools are registered in JavaScript through a navigator.modelContext API and run in the user's own browser session, with their own login.
When does WebMCP ship in Chrome?
It is in origin trial in Chrome versions 149 to 156, with shipping anticipated in Chrome 157, projected for early November 2026. Anticipated is a target rather than a commitment: an origin trial is how Chrome tests a feature on production traffic, and the decision to ship comes after the trial concludes. Microsoft Edge is running its own origin trial, open through 17 November 2026.
Is WebMCP a search ranking factor or an AI visibility tactic?
No. WebMCP addresses whether an agent that is already on your page can operate it. It does nothing for whether search engines or AI assistants discover your page, and nothing for whether an AI answer cites you. Those are separate layers, solved by crawlability and indexing, and by the answer quality and evidence that make a page worth citing. Registering tools on a page nobody finds achieves nothing.
Do I need WebMCP if I already have a public API?
They do different jobs. A public API is called by a server you have authorised, with its own credentials. WebMCP tools are called inside the end user's browser, in their existing logged-in session, on the page they are already on. An agent helping a customer check their own order status through your site is not a use case a public API covers, and an existing API does not remove the need for the browser-side tools if that is the interaction you want to support.
Is it safe to let an AI agent operate my website?
It depends entirely on what you expose. The workable rule is: read freely, write narrowly, never spend. Search, lookups and availability checks are safe to expose. Anything that places an order, changes billing, alters an account or deletes data should either not be exposed at all, or should return a confirmation step for the user rather than completing the action. Every tool you register is a function a model decides when to call.
Which browsers and AI assistants support WebMCP today?
Chrome via origin trial, with shipping anticipated in Chrome 157. Microsoft Edge via its own origin trial through 17 November 2026. ChatGPT's desktop app calls WebMCP tools in its built-in browser, shipped as Site tools in August 2026, and Brave Leo has experimental support. WebKit opposes the proposal in its present form, so Safari support should not be assumed, and Mozilla is neutral. The spec remains a W3C community group draft rather than a Recommendation.
The takeaway
WebMCP is real, it is close, and it is being oversold. It solves a narrow problem, an agent that has already reached your page cannot reliably operate it, and it solves that problem well. It does nothing to help an agent find or cite you, one major engine opposes the current design, and the API has already changed mid-trial. If your site has a genuine parameterised task and measurable assistant traffic, run one read-only tool and measure it. If it does not, spend the same money on semantic forms, a real search endpoint and stable identifiers, and you will be ready for this and for whatever replaces it.