WebMCP lets AI agents operate your website. Should you build for it yet?

Every few months a new standard arrives promising to make your website legible to AI. Most deserve the shrug they get. WebMCP is more interesting than that, because it is not another way of describing your content — it hands agents a set of buttons to press. That is also why the decision about whether to adopt it is not the same decision as adding schema markup.

What WebMCP actually is

WebMCP is a proposed web standard that lets a page hand AI agents a list of things it can do, instead of making the agent guess by reading pixels or scraping the DOM. A page registers named tools — search products, check availability, add to cart — each with a description and a typed input schema, and a browser-based agent can call them directly. It is the difference between an agent hunting for your date picker and an agent calling checkAvailability(date) and getting a clean answer back.

The proposal was co-developed by Google and Microsoft, submitted to the W3C Web Machine Learning Community Group in August 2025, and accepted by that group the following month. That matters for how you read it: a Community Group report is not a ratified W3C standard, and it does not commit any browser other than Chrome to ship anything.

Where the standard actually stands in September 2026

Most write-ups either describe WebMCP as already shipped or dismiss it as a demo. Neither is right. Here is the documented sequence.

One wrinkle nobody has flagged: that trial window is shorter in calendar time than it looks. Chrome moved to a two-week stable release cycle from Chrome 153 on 8 September 2026, so the versions between here and 157 arrive fortnightly rather than monthly. If you were mentally budgeting "a few Chrome versions" as half a year of runway to decide, it is closer to a couple of months. Treat any date you project from version numbers as a planning anchor, not an official milestone.

The rename that will break early implementations

If you or your developer built against WebMCP earlier this year, check this before anything else. The API originally exposed the registration surface at navigator.modelContext. A draft revision dated 27 May 2026 moved it to document.modelContext, and that is what shipped in Chrome 150. Chrome 150 keeps navigator.modelContext working as a deprecated alias that logs a one-time console warning, so an early implementation does not fail loudly — it keeps working while quietly sitting on a deprecated path.

That is the worst failure mode for a small team: nothing visibly breaks, so nothing gets fixed, until the alias is eventually removed. If your site registered tools during the Chrome 149 window, the fix is a one-line change and a console check.

WebMCP is not llms.txt, schema markup, or an API

These four get conflated constantly, and the confusion leads people to do the wrong one. They answer different questions.

The fourth row is the genuinely new thing. Schema and llms.txt are both ways of describing yourself to a reader. WebMCP hands over a control surface. That is why the security section below is not boilerplate.

Should you build for it? A decision matrix

The honest answer for most businesses reading this is no, not yet — but "not yet" is doing real work in that sentence, and the trigger that should change your mind differs by site type.

The read/write split is the whole risk story

If you take one structural idea from WebMCP, take this one. Tools divide cleanly into ones that only read state and ones that change it, and the correct posture toward each is completely different.

Chrome's own guidance is blunt about why the last two rows matter: registered tools execute in the page's JavaScript context, using the signed-in user's session. A tool is not a sandbox. Anything the user can do, a tool you expose can do, at the speed an agent chooses to call it.

What WebMCP does not do

Five limitations that the enthusiastic coverage tends to skip, and that should shape your timing.

• It is not a discovery mechanism. An agent has to be on your page to learn that tools exist. There is no crawlable registry, so WebMCP does not bring you agent traffic — it improves what happens once traffic arrives.
• It is Chrome-first. An origin trial in one browser engine is not cross-browser support. Building for it today is building for a subset of a subset.
• It assumes a human is present. The design targets local, in-browser workflows with a person in the loop, and is weaker in headless or fully autonomous scenarios — which is where a lot of the commercial agent activity actually happens.
• Rate limiting is not standardised. The specification names it as a consideration without defining a mechanism, so throttling is your problem to solve in application code.
• Your tool schemas are public. Names, descriptions and input types describe your internal architecture and business logic to anyone who looks. Published security research has already demonstrated manipulation attacks that exploit tool names and metadata to steer an agent's behaviour.

The prep work that pays off either way

Here is the part worth acting on this quarter, because none of it is a bet on WebMCP. Every item below improves your site for search, for accessibility and for ordinary users, and happens to be exactly what makes a site cheap to make agent-ready later.

1. Write down your site's actual verbs. Not pages — actions. "Request a quote", "check delivery area", "book a consultation". Most teams have never listed these, and the list is the input to every agent decision you will make for the next three years.
2. Give every one of those actions a stable, semantic form. Real labels, real input types, real validation messages, working without JavaScript where possible. Agents and screen readers fail on the same things.
3. Make state readable from markup. If availability, price or stock only exists inside a JavaScript variable after three renders, nothing external can read it reliably — agent, crawler or otherwise.
4. Keep the irreversible actions behind a deliberate confirmation. Good practice for humans, and it is the exact control WebMCP's risky tier will require.
5. Instrument for non-human traffic now. You cannot evaluate the "revisit when" triggers in the matrix above if your analytics cannot distinguish an agent session from a person. This is the same measurement problem that already quietly corrupts A/B test results.

Do those five and the eventual WebMCP implementation is a short piece of work rather than a rebuild. Skip them and it will not matter which standard wins, because your site will be hard for anything automated to use.

What this changes about commissioning web work

The practical shift is in what you ask for, not what you buy. A brief that specifies pages and a design produces a site that describes itself well. A brief that specifies actions — what a user can do, what each action needs, what confirms it succeeded — produces a site that can be operated, by a person, a screen reader or an agent. That framing costs nothing extra at build time and is expensive to retrofit.

It is worth asking a prospective developer how they would expose your three most valuable actions as callable tools. You are not commissioning that work. You are finding out whether they think about your site as a set of documents or a set of capabilities, which is the same distinction that separates a website from a web app and increasingly decides which one you actually needed. The same build discipline that keeps a site fast and accessible is what makes it agent-ready, and none of it requires betting on a standard that is still in trial.

Frequently asked questions

What is WebMCP in simple terms?

WebMCP is a proposed web standard that lets a website tell AI agents what actions it can perform, as a list of named tools with typed inputs, rather than making the agent work it out by reading the screen. A page registers tools such as search products or check availability, and a browser-based agent calls them directly. It was co-developed by Google and Microsoft and submitted to the W3C Web Machine Learning Community Group in August 2025.

Is WebMCP an official W3C standard yet?

No. It was published as a Draft Community Group Report on 10 February 2026, which is an early stage of the standards process and not a W3C Recommendation. A Community Group report does not commit any browser vendor to ship it. Chrome is running it as an origin trial; other browser engines have not shipped support.

Should a small business website implement WebMCP now?

For most brochure and lead-generation sites, no. Your highest-value action is usually a form, which agents can already complete, and WebMCP does not bring agent traffic to you because there is no crawlable registry of tools. The work worth doing now is the preparation that pays off regardless: listing your site's real actions, giving them stable semantic forms, making state readable from markup, and instrumenting analytics to identify agent sessions.

Which Chrome versions support the WebMCP origin trial?

The origin trial opened in Chrome 149 and is scheduled to run through Chrome 156 across desktop, Android and WebView, with desktop shipping targeted at Chrome 157. Because Chrome moved to a two-week release cadence from Chrome 153 on 8 September 2026, those versions arrive faster in calendar terms than the version numbers suggest.

Why did navigator.modelContext stop being the right API?

A draft revision dated 27 May 2026 moved the registration surface from navigator.modelContext to document.modelContext, and that change shipped in Chrome 150. Chrome 150 keeps navigator.modelContext as a deprecated alias that logs a one-time console warning, so early implementations continue to work without any visible failure while sitting on a deprecated path. If you built during the Chrome 149 window, update the reference and check the console.

What are the security risks of exposing WebMCP tools?

Registered tools run in the page's JavaScript context using the signed-in user's session, so a tool can do anything that user can do. Tool names, descriptions and input schemas are visible and describe your internal logic, and published research has demonstrated attacks that manipulate tool metadata to steer an agent's behaviour. The specification names rate limiting as a consideration but does not define a standard mechanism, so throttling is left to your application code. The practical control is to expose read-only tools freely and keep irreversible actions behind human confirmation.

Does WebMCP replace schema markup or llms.txt?

No, they solve different problems. Schema markup and llms.txt describe what your content is and which pages matter, and are consumed by crawlers and answer engines. WebMCP exposes what a page can do as callable actions, consumed by an AI agent inside the user's browser session. Implementing one does not reduce the need for the others.

The takeaway

WebMCP is worth understanding now and implementing later, for almost everyone. The standard is real, the backing is serious and the direction is clear, but a single-engine origin trial with an unratified spec and no discovery mechanism is not where a small business should spend its development budget this quarter. What is worth spending now is the two days it takes to list your site's actual actions, give each one a stable semantic form, make your state readable from markup and start telling agent sessions apart from human ones in analytics. That work makes your site better for people today and makes the WebMCP decision cheap whenever you finally have to make it. The businesses that will struggle are the ones whose sites cannot be operated by anything that is not a human with a mouse — and they were already struggling with accessibility and search for the same reason.