WebMCP: should your website hand tools to AI agents yet?

For two years the answer to "how do AI agents use my website?" has been: badly, by reading the page and guessing which button to press. WebMCP is the proposal that replaces the guessing with a declaration, and in the last eight weeks it moved from a conference demo to something running on every Shopify Liquid storefront. It is also still a draft whose core API has changed twice, which makes the timing question sharper than the technology question.

What WebMCP actually is

WebMCP is a proposed web standard, drafted in the W3C Web Machine Learning Community Group, that lets a web page expose structured tools to an AI agent running in the browser. A tool is a named function with a human-readable description, an input schema and a handler: search_products, add_to_cart, book_appointment, file_support_ticket. The agent reads the list of tools the page has declared and calls the one it needs, with typed arguments, rather than inferring intent from your markup.

The distinction that matters commercially is that the agent operates inside the visitor's own browser session. It inherits their login, their cart, their permissions. It is not a scraper hitting your site from a datacentre, and it is not a separate API you host for third parties. It is the page itself, saying what can be done on it.

As of September 2026 it remains a community group draft rather than a W3C Recommendation. That status is the single most useful fact for planning, and it is the one most coverage skips.

Where the standard actually stands

The dates below are the ones worth putting in a roadmap. Everything after Chrome 156 is a target, not a commitment: an origin trial is how Chrome experiments, and the ship decision comes after the trial closes.

The API has already changed twice. Check any guide against this

This is where most businesses will lose money on WebMCP, and it has nothing to do with strategy. The surface has moved twice inside six months, and a large share of the tutorials, starter repos, plugin snippets and agency proposals now circulating were written against a shape that no longer exists. If someone hands you WebMCP code, this table dates it in about ten seconds.

The reasoning behind the move was sound: tools belong to a specific document, not to the browser as a whole. That is exactly the kind of correction a draft standard makes, and exactly the reason to keep your implementation small enough to rewrite in an afternoon.

What a tool declaration actually contains

You do not need to write this yourself, but you should recognise the parts, because the quality of a WebMCP implementation lives almost entirely in the descriptions and schemas rather than the code.

The practical rule: a tool should do exactly what the equivalent button on your page does, through the same validated path, and its description should read like an instruction to a competent new employee.

Who should do something about this now

Most sites should not build for WebMCP this quarter. A few should have started already. The difference is not company size, it is whether your site's value is a repeatable transaction.

Notice what is absent from that table: any promise of traffic. WebMCP does not make an agent choose your site. That decision happens earlier, in search and in AI answers, which is a different piece of work altogether — the one covered in our guide to optimising for AI search.

WebMCP, llms.txt, schema markup and MCP servers are not competitors

These four get bundled together in vendor decks as "AI readiness". They operate at different layers and substituting one for another is the most common expensive mistake in this area.

If you sell to other businesses through integrations, a hosted MCP server is probably the higher-value project and it does not depend on any browser timeline. If your value is delivered to a consumer on your own site, WebMCP is the relevant one. We covered the llms.txt question separately, including what the evidence actually shows about llms.txt.

Which tools to expose first, and which never to expose

A good first implementation is three to five tools, not thirty. Start with the actions that are high-frequency, low-consequence and annoying to perform by clicking.

1. Search or filter your catalogue. Highest value, lowest risk, and the action agents currently perform worst by reading the page.
2. Check availability, stock or pricing for a specific item. Structured in, structured out, no side effects.
3. Add to cart, or assemble a quote request. Reversible, and it is the step where DOM-driven agents most often fail silently.
4. Look up an order or booking the signed-in user already owns. Scoped by their own session, so authorisation is inherited rather than invented.
5. Start a support ticket with structured fields. Cuts the worst part of your support queue: badly-formed first messages.

And the list to keep off the table until the standard settles and your authorisation model is deliberate: completing payment, cancelling or refunding, deleting anything, sending messages to third parties, changing account credentials or contact details, and anything that commits spend without a human confirming in the interface. "The agent can, but must ask first" is a design decision you have to implement; nothing in the browser does it for you.

The security part people skip

Declaring a tool publishes an interface to whatever software is driving the browser. Three consequences follow, and all three are your responsibility rather than Chrome's.

Server-side validation is not optional. A tool handler is client-side code. Every rule you rely on — price, eligibility, quantity limits, permissions — must be enforced on the server exactly as if the request came from a hostile client, because it might.

Prompt injection now has a path through your own content. If an agent is reading your page and a review, comment or uploaded document contains instructions, the agent may act on them. Sites that accept user-generated content and declare tools need to think about that combination explicitly.

Expensive endpoints need rate limits. Search, quoting, availability checks and message-sending are cheap to call in a loop and not cheap to serve. Existing abuse controls were designed around human click rates and will not hold.

None of this is a reason to avoid WebMCP. It is a reason to keep the first implementation small, reversible and reviewed by whoever owns your backend, rather than treating it as a front-end decoration.

What to ask before commissioning the work

If you are briefing an agency or an internal team, four questions separate a considered proposal from a bandwagon one. Which draft date is your implementation written against? Which specific tools are you declaring, and what does each one return? Where is authorisation enforced for each tool? And what happens to this code when the origin trial ends after Chrome 156 — renewal, ship, or removal?

A team that answers those four crisply can build you something genuinely useful in days. A team that answers with "AI-ready website" is selling a slide. The underlying discipline is the same one that makes a site cheap to maintain in every other respect: a small number of well-understood components, one validated path per action, and no orphaned code — the foundation we build on in our website design and development work. That is the same test we would apply to any emerging-standard work, and it sits alongside the broader question of what AI is actually changing about how web development gets bought.

It is also worth separating this from the payments side of agentic commerce, which is moving on its own track: card networks and checkout providers have been building agent-authorised payment rails since mid-2026, and that work is covered in our piece on agentic checkout. WebMCP is how an agent operates your page; those rails are how it is allowed to pay. You can adopt either without the other.

Frequently asked questions

What is WebMCP?

WebMCP is a proposed web standard that lets a page declare named tools, each with a description and an input schema, that an AI agent running in the browser can call directly. Instead of an agent reading your HTML and guessing which button books an appointment, your page tells it: here is a book_appointment tool, here are the fields it needs. It is a draft in the W3C Web Machine Learning Community Group, not a finished W3C Recommendation.

Is WebMCP available in Chrome yet?

It is in an origin trial, not general release. Chrome announced the origin trial with Chrome 149 on 19 May 2026 at Google I/O, and the trial covers Chrome versions through 156, which reaches stable on 20 October 2026. Chrome Status lists Chrome 157 (3 November 2026) as the anticipated shipping milestone, but that is a target rather than a commitment. Microsoft runs a separate Edge origin trial open through 17 November 2026.

Is navigator.modelContext still the correct WebMCP API?

No. The community group's draft moved the getter from Navigator to Document on 27 May 2026, so tools are registered on document.modelContext. Google's guidance marks navigator.modelContext deprecated in Chromium 150, and an earlier provideContext() method was cut in March 2026. Any tutorial, plugin or agency code sample still using navigator.modelContext or provideContext() predates the current draft, which is the fastest way to date a WebMCP guide.

Does WebMCP help my SEO or AI search rankings?

No. WebMCP is about what an agent can do on a page it has already opened, not about whether your page gets found, ranked or cited. Nothing published by Google connects WebMCP tools to Search ranking or to selection in AI Overviews. Schema markup, clean HTML and genuinely useful content still do the discovery work; WebMCP only changes the reliability of the task once an agent is on your site.

Which businesses should implement WebMCP now?

Three groups: stores on a platform that already ships it, where enabling it is configuration rather than a project; sites whose core action is a repeatable transaction such as booking, quoting, reordering or ticket filing; and logged-in products where customers already ask assistants to do the work. A brochure site with a contact form gains close to nothing, because the agent can fill a three-field form by reading the DOM anyway.

What are the risks of exposing tools to AI agents?

A declared tool is an API you have published to whatever is driving the browser, so treat it as one. The main risks are irreversible actions triggered without a human confirming, prompt injection reaching an agent through content on your own page, and automated abuse of expensive endpoints such as search, quoting or messaging. Server-side authorisation, rate limits and a human confirmation step for anything that spends money, cancels, deletes or sends remain your responsibility; the browser does not supply them.

How is WebMCP different from llms.txt or schema markup?

They solve different problems. Schema markup describes what a page is so search engines can understand and display it. llms.txt is an unofficial proposal for a text file describing your site to language models, with no confirmed use by major AI systems. WebMCP describes what an agent can do on the page and lets it call those actions in the browser session, carrying the visitor's own login state. Only WebMCP performs actions; the other two only describe.

The takeaway

WebMCP is the first serious attempt to let websites tell agents what they can do rather than making them guess, and the adoption side moved faster in August 2026 than the specification did. That gap is the whole story: real agents are calling real tools on Shopify storefronts today, while the API those tools are written against has changed twice since May and is not guaranteed to ship until a Chrome release that is currently a target. The right posture for most businesses is neither a rewrite nor a shrug. Find out whether your platform already exposes tools on your behalf, test what an agent actually does with your two or three most valuable actions, keep the implementation small enough to throw away, and put a date in the calendar for the week Chrome 156 lands. If you are on a platform that shipped it for you, that work is verification you should have done six weeks ago.