Every few months something arrives that is described as the end of the website as we know it. Most of the time the right response is to carry on. WebMCP is more interesting than that, because for the first time there is a concrete, shipping-track browser API that changes what a website is to an AI agent: not a page to be read and clicked, but a set of declared actions it can call. It is also still an origin trial, which means the correct amount of work to do about it today is real but small, and knowing which is which saves you a rebuild.
WebMCP is a proposed browser API that lets a site declare its actions — search, filter, add to cart, book a slot, submit an enquiry — as structured tools an AI agent can call directly, instead of the agent guessing at your interface. It is in a Chrome origin trial, not shipped, with Chrome 157 (3 November 2026) currently pencilled as the target milestone. For most business sites the right move now is the declarative tier: a few HTML attributes on your highest-value forms, measured in hours.
What WebMCP actually is
WebMCP (Web Model Context Protocol) is a W3C Community Group proposal that gives a page a way to publish its own capabilities to an AI agent running in the browser. Instead of the agent taking a screenshot, reasoning about what the pixels mean, hunting for a selector and clicking, the page hands it a typed list: here is searchProducts, it takes a query string and an optional category, here is what it returns.
The distinction that matters commercially is between WebMCP and a conventional MCP server. An MCP server is infrastructure you stand up and maintain separately, with its own authentication, its own hosting and its own permissions model. WebMCP tools run inside the page, in the user's existing browser session, under the permissions they already have. There is no second copy of your business logic to keep in sync and no API key to issue, because the user is already signed in. That is the whole argument for it.
Where it actually is in the pipeline
This is the part most coverage skips, and it is the part that determines whether you should spend anything on it. The dates below are what the decision should be made against.
| Date | Milestone | What it meant |
|---|---|---|
| 10 February 2026 | Shipped behind a flag in Chrome 146 Canary | Prototype only; usable by developers who turned it on deliberately |
| March 2026 | Spec revision removes provideContext() and clearContext() | The API broke once already; registerTool() / unregisterTool() are now the surface |
| 18 May 2026 | Chrome for Developers documentation published; origin trial opens with Chrome 149 | First point at which a production site could enable it for real users |
| 20 October 2026 | Chrome 156 ships — the last release the current origin trial covers | The date your trial token stops being useful unless the trial is extended |
| 3 November 2026 | Chrome 157, listed on Chrome Status as the anticipated shipping milestone | A target, not a commitment. Origin trials exist precisely so this can slip |
Two things follow from that table. First, nothing you build against WebMCP today is guaranteed to survive, because the spec has already changed once in a way that broke working code. Second, the window in which you can test it against real users with a trial token closes on 20 October 2026, which is before the Q4 trading period most businesses would want to test it in anyway. That combination argues for doing the cheap tier and waiting on the expensive one.
The two ways a site exposes tools
There are two routes, and the cost difference between them is the single most important thing to understand before anyone quotes you for this work.
| Declarative | Imperative | |
|---|---|---|
| How you write it | HTML attributes on an existing <form>: toolname, tooldescription, tool-param-description | JavaScript: navigator.modelContext.registerTool() with an explicit JSON Schema |
| What the browser does | Reads your form's inputs, types and constraints and builds the schema for you | Uses the schema you supply and calls your handler function |
| Good for | Anything that is genuinely one form: enquiry, search, newsletter, quote request, booking request | Multi-step flows, filtered search, anything with state between steps |
| Realistic effort | Hours, on forms that already exist | One to two engineering weeks for a first real implementation |
| Risk if the spec moves | Near zero — the attributes are inert in browsers that do not understand them | Meaningful — this is the layer that broke in March 2026 |
The declarative route is close to free because it annotates markup you already ship. If WebMCP never ships, you are left with a handful of unrecognised attributes and no behavioural change. That asymmetry is the reason the recommendation below is not "wait and see" for everybody.
Before anyone writes a tool, check whether your highest-value action is actually a real <form> element with labelled inputs. On a surprising number of modern sites it is a pile of divs with click handlers, which no agent, crawler or screen reader can use. Fixing that is worth doing whether or not WebMCP ever exists.
Should your site do anything about it? A verdict by site type
The answer is not the same for a brochure site and a logged-in SaaS product, and most of the writing on WebMCP is aimed at developers building demos rather than at businesses deciding where the money goes.
| Site type | What an agent would want to do | Verdict today | Why |
|---|---|---|---|
| Lead-gen or service site | Submit an enquiry, request a quote, check availability | Do the declarative tier | One or two forms carry the entire commercial value of the site. Annotating them is an afternoon |
| SaaS with a logged-in interface | Perform the task the customer already pays for | Strongest case — build properly | Tools run in the user's own session with their own permissions, which removes the auth problem that makes a separate API expensive |
| Custom-built ecommerce or marketplace | Search, filter, check stock, add to basket | Build if you already see agent referrals | You own the code path, so the trial is the cheapest time to learn the API on something that matters |
| Store on a hosted platform | The same, but your cart is not your code | Wait for the platform | Bolting tools onto a theme creates a fork you maintain forever against a spec that is still moving |
| Booking-led local business | Check slots, book, reschedule | Do the declarative tier | High-value action, small surface, and the confirmation step keeps a mistaken booking from happening silently |
| Content site or publisher | Search the archive, retrieve an article | Skip it | Agents can already read well-structured HTML. A tool adds almost nothing that clean markup does not |
The four-tier ladder, and where to stop
Treat agent-readiness as a ladder rather than a project. Each rung is independently useful, and the useful part of the ladder is lower down than the demos suggest.
| Tier | What you do | Effort | Value if WebMCP never ships |
|---|---|---|---|
| 0 — Fundamentals | Server-rendered content, real <form> elements, labelled inputs, stable URLs, meaningful headings | Days, usually as part of work you already owe | Full. This is what every agent, crawler and assistive technology uses today |
| 1 — Declarative tools | Add toolname, tooldescription and tool-param-description to your two or three highest-value forms. Leave autosubmit off | Hours | Near-total, because the cost was near zero |
| 2 — Imperative tools | registerTool() for actions that are not one form, behind an origin trial token | 1–2 engineering weeks | Code discarded; the understanding of your own flows is kept |
| 3 — Agent operations | Confirmation UI, rate limits, audit logging, exposedTo allowlists, abuse monitoring | Ongoing | High — every one of these is needed for any automation surface you expose |
Most businesses reading this should complete tier 0, do tier 1 on the forms that matter, and stop. Tier 2 earns its cost when an agent completing the action is itself the product, which in practice means SaaS and complex commerce rather than a services website.
The security questions to answer before you expose anything
An agent-callable tool is an automation endpoint with your brand on it. The defaults are sensible, but the defaults are not the whole job.
- Is it same-origin only? By default other sites and cross-origin iframes cannot see or call your tools. If you widen that with
exposedTo, do it to a named list of secure origins, never a wildcard. - Does anything irreversible happen without a human? Omitting autosubmit forces the user to confirm before an agent can submit. Payments, cancellations, deletions and anything that sends an email should sit behind that confirmation regardless of how convenient it is not to.
- What does the tool description say? The description is a prompt. Write it as a precise instruction for a capable but literal reader, and assume an adversarial page may try to talk your agent into misusing it.
- Is the tool doing its own authorisation? Running in the user's session means the tool inherits their permissions — which is the benefit, and also the risk if your server trusts the client more than it should. Server-side checks do not become optional because the caller is an agent.
- Can you see it in your logs? If agent-originated actions are indistinguishable from human ones in your analytics, you will not be able to answer whether any of this worked.
What would make this a waste of time
An honest assessment, because the enthusiasm around the agentic web is running well ahead of the deployment reality.
- Origin trials do not always ship. Chrome 157 is an anticipated milestone on Chrome Status, not a commitment, and the trial covering only to Chrome 156 means the timeline has at least one natural decision point in it.
- It is Chrome-only today. No other engine has shipped it. A capability that exists in one browser is a capability you cannot build a business process on.
- There is no discovery mechanism. Nothing tells an agent which sites expose tools before it visits them. Until a directory or a search surface fills that gap, the agent has to arrive at your page first — which means your ordinary organic and paid acquisition still does all the work.
- The spec has broken once.
provideContext()was removed in March 2026. Anything you write at tier 2 is written against a moving target.
None of that argues against tier 0 or tier 1, because neither depends on WebMCP shipping. It argues strongly against a rebuild.
How this fits with the AI search work you are probably already doing
WebMCP is about action; answer engine optimisation is about citation. They are separate problems with one shared dependency: clean, server-rendered, well-structured HTML. A page an AI answer engine can quote accurately is usually a page an agent can operate, and the reverse is rarely true of a JavaScript-heavy interface that renders nothing useful in the initial response.
If you are choosing where to put a limited budget this quarter, the AEO and GEO work has a measurable return now and WebMCP has a speculative one later. Do them in that order. The agentic checkout flows already live in 2026 are the closest thing to a real-money example of what happens when agents can transact, and they are worth reading before committing engineering time here. For the underlying build quality that both depend on, that is ordinary website design and development work, not an AI project.
Frequently asked questions
What is WebMCP in plain English?
WebMCP is a proposed browser API that lets a website publish a list of the actions it can perform — search, filter, add to cart, book, submit an enquiry — as structured tools an AI agent can call directly. Instead of the agent reading the screen and guessing which button to click, it calls a named function with typed parameters. It is a W3C Community Group proposal currently running as a Chrome origin trial.
Is WebMCP available in Chrome now?
Not as a shipped feature. It first appeared behind a flag in Chrome 146 Canary on 10 February 2026 and opened as an origin trial with Chrome 149, documented on 18 May 2026. The current trial covers Chrome releases up to Chrome 156, due 20 October 2026. Chrome Status lists Chrome 157, scheduled for 3 November 2026, as the anticipated shipping milestone, but that is a target rather than a commitment.
Is WebMCP the same as running an MCP server?
No. An MCP server is separate infrastructure you host, authenticate and maintain alongside your site. WebMCP tools run inside the page itself, in the user’s existing browser session and under the permissions they already hold. That removes the duplicate business logic and the separate credential problem, which is the main practical argument for it.
Do I need WebMCP for ChatGPT or Gemini to cite my site?
No. Citation in AI answers depends on crawlable, well-structured content, not on WebMCP. WebMCP is about letting an agent take an action on your site once it is there. If your goal is being surfaced and quoted by AI answer engines, answer engine optimisation is the relevant work and it pays off today.
What does it cost to make a website agent-ready?
It depends entirely on which tier you stop at. Annotating two or three existing forms with the declarative attributes is a few hours. Building imperative tools with registerTool() for multi-step flows is realistically one to two engineering weeks for a first implementation. The foundational work — server-rendered content, real form elements, labelled inputs, stable URLs — is ordinary build quality and pays off regardless.
What are the main risks of implementing WebMCP now?
Four. The origin trial may not lead to a shipped feature; no browser engine other than Chrome has shipped it; there is no mechanism for an agent to discover which sites expose tools before visiting them; and the spec has already changed once, when provideContext() and clearContext() were removed in a March 2026 revision. Work at the declarative tier carries almost none of this risk because it costs almost nothing.
Which kinds of business should actually build this in 2026?
SaaS products with a logged-in interface have the strongest case, because tools inherit the signed-in user’s permissions and remove the need for a separate authenticated API. Custom-built ecommerce and marketplaces are next, if they already see agent-originated traffic. Lead-generation and booking sites should do the cheap declarative tier only. Stores on hosted platforms should wait for the platform, and content sites can skip it.
The takeaway
WebMCP is the first serious attempt to let a website tell an AI agent what it can do rather than make the agent guess, and the case for it is real on sites where an agent completing a task is the point. It is also an origin trial covering Chrome releases only up to 20 October 2026, with a shipping milestone that is a target rather than a promise, and a spec that has already broken once. The right response is asymmetric: do tier 0 and tier 1, which cost hours and pay off whether or not the standard survives, and hold tier 2 until the ship call is made. If the only thing you do after reading this is make sure your most valuable action is a real form with labelled inputs, you will have captured most of the available value already.
Sources & further reading
- Chrome for Developers, “WebMCP” documentation
- Chrome for Developers, “Join the WebMCP origin trial”
- Chrome for Developers, “WebMCP tool security”
- InfoQ, “WebMCP Standard Proposal for Agentic Web Actuation Now Available in Chrome (Origin Trials)”
- The Drop Times, “Google Details WebMCP Origin Trial for Chrome 149 With DevTools Support”
- DataCamp, “WebMCP Tutorial: Building Agent-Ready Websites With Chrome’s New Standard”