WebMCP Lets AI Agents Use Your Website, Not Just Read It

On August 21, 2026, Shopify switched on WebMCP tools across every Liquid storefront. Twelve tools per shop: search_catalog, browse_store, get_product, get_cart, update_cart, proceed_to_checkout, manage_orders, and a handful more. No merchant installed anything. No merchant approved anything. One morning their store simply started offering AI agents a set of buttons to press.

Four days later, on August 25, OpenAI turned on the other side of that handshake in the ChatGPT desktop app's built-in browser, and ran a ten day hackathon with Chrome, Cloudflare, Shopify, Vercel, Render and Netlify to get developers building against it.

So we have gone from "AI reads your website" to "AI operates your website" in about eighteen months. That is the part worth paying attention to. Almost everything else being written about WebMCP right now is a future-proofing panic pitch, and I want to be straight with you: I have not shipped this for a client. I have read the spec, run the inspector, and formed an opinion about who should care. That opinion is mostly "not you, not yet, and here is the one thing to do anyway."

What WebMCP Actually Is

WebMCP is a proposed browser API that lets a web page register callable tools directly from JavaScript, so an AI agent in the browser can invoke a function on your site instead of guessing which button to click.

The current shape looks like this. You call document.modelContext.registerTool() and hand it a name, a plain-English description, a JSON Schema for the inputs, and an execute function that actually does the thing. The agent asks the page what tools exist, reads your descriptions, and calls the one that matches what the user asked for. There is also a declarative flavour that annotates ordinary HTML forms, though it is thinner and less supported.

The status matters more than the syntax. As of September 4, 2026, the spec is a Draft Community Group Report from the W3C Web Machine Learning Community Group. That is not a W3C standard. It is not even on the standards track. A Community Group is closer to a public workshop than a specification body: anyone can join, output carries no formal endorsement, and nothing is binding on anyone. The authors are engineers from Microsoft and Google, which tells you the browser vendors are interested. It does not tell you the thing is finished.

If you read a post that calls WebMCP "the new W3C standard," that post is wrong, and it is wrong in the direction that sells you services.

How It Differs From MCP, llms.txt, and Schema Markup

The single sentence version: llms.txt is about being read, schema markup is about being understood, and WebMCP is about being used.

I wrote about Model Context Protocol when it was the new thing, and MCP is genuinely the parent here. But MCP is a server protocol. You stand up an MCP server, an agent connects to it over a transport, and it runs somewhere with its own auth, its own hosting, its own deploy. WebMCP moves that idea into the page itself. The tools run in client-side script, inside the user's already-authenticated browser session, on your origin. The spec's own framing is that a WebMCP page can be thought of as an MCP server whose tools are implemented in the page instead of on a backend.

That difference is the whole point. If a customer is logged into your booking system in their browser, an in-page tool can book them an appointment using the session they already have. No API keys, no OAuth dance, no separate service to run. That is a real advantage over "just build a good API," and it is the reason this proposal exists rather than everyone shipping REST endpoints.

Schema.org structured data and llms.txt do something categorically different. They describe. They say "this page is a dentist practice in Augsburg with these opening hours." They cannot book anything. If your goal is getting mentioned in AI answers, that is still the citation game I broke down after the 1.4 million prompt study, and it has nothing to do with WebMCP. Different problem, different fix, and being clear on which one you are solving saves a lot of wasted budget.

Who Actually Supports It Today

Chrome moved WebMCP from a Canary flag to a public origin trial in Chrome 149, announced June 9, 2026. Origin trial means you register a token, ship it on production traffic, and Google collects feedback with an explicit expectation that the API will change. Locally you can enable it with chrome://flags/#enable-webmcp-testing. Edge added a flag-gated preview in version 147 back in March 2026. There is a Model Context Tool Inspector extension for testing your tools against Gemini by hand.

On the agent side the picture is thinner than the headlines suggest. ChatGPT supports site tools in its desktop browser for ChatGPT Work and Codex, on specific models, and not in Enterprise or Edu workspaces. Declarative form tools are not supported. Tools inside iframes are not discovered. Only a subset of the API works.

Claude in Chrome does not consume WebMCP tools. There is an open feature request for it. Anthropic invented MCP and has said nothing public about WebMCP. Gemini and Perplexity still read pages the old way, through the DOM and screenshots.

So: two browsers behind flags or trials, one agent product with a list of caveats, and one very large commerce platform that shipped tools to millions of storefronts that mostly nothing is calling yet. Shopify's own docs say it plainly: the tools are live, agent support is limited to Chromium browsers. Everybody is building the socket before the plug exists.

The API Renamed Itself Under Everybody

Here is my favourite detail, because it is the one that decides whether you should spend a sprint on this.

An earlier draft had a provideContext() method. It was removed in March 2026. The API is also migrating from navigator.modelContext to document.modelContext. Not a deprecation with a polyfill and an eighteen month runway. A rename, in a draft, because the shape was wrong the first time.

Every tutorial written before spring 2026 is now teaching code that does not run. Every agency that shipped a "WebMCP-ready" package in Q1 gets to do it again. That is completely normal for a Community Group draft. It is also exactly why "future-proof your site with WebMCP now" is backwards advice: there is no future to proof against yet, only a draft that will keep moving. If you do build against it, feature-detect, keep it in one isolated module, and assume you rewrite it.

The Security Questions Are the Serious Part

The spec's own Security and Privacy Considerations section is more honest than most of the marketing written about it, and it is where I would start if a client asked me to implement this.

It names three injection vectors. Metadata poisoning, where malicious instructions hide in a tool's description and steer the agent's reasoning. Output injection, where what your tool returns contains instructions that influence what the agent does next. And tool implementation targeting, where exposing valuable functionality just makes it a bigger target. The spec also admits a trust gap it cannot close: there is no guarantee that a tool's declared intent matches its actual behaviour. The agent reads your English sentence and decides. It cannot verify.

Then there is over-parameterization, which is the quiet one. A sloppy input schema on your booking tool becomes an exfiltration channel for whatever else the agent knows about the user, including browsing context and personal data. You wrote a form field. You shipped a data pipe.

The access control story is reasonable as far as it goes. Tools are gated by a tools permissions policy defaulting to self, origin isolation is required, and cross-origin exposure needs an explicit opt-in list. But on the question everyone actually cares about, whether the user consented before an agent spent their money, the spec has no normative mechanism. There is a consequentialHint annotation you can set, which is a suggestion, not a gate. OpenAI layers its own safety review on top of each invocation. That is a vendor policy, not a guarantee, and it varies by vendor.

None of this is theoretical. Brave documented indirect prompt injection against Perplexity's Comet, including an attack that used a calendar invite to make the browser act against its own user, and a variant that took over a password manager the user was already signed into. A June 2026 University of Washington study found that four of seven popular agentic browsers let a malicious page bypass the same-origin policy, with a working data-theft proof of concept against ChatGPT Atlas. The recurring finding is that prompt injection is not fully patchable, because the property that makes these browsers useful is the same property that makes them exploitable.

This is the same failure mode I wrote about with AI coding assistants installing packages they cannot verify. A system that reads instructions from untrusted content and then takes real action cannot reliably tell the difference between input and command. WebMCP does not fix that. It gives the agent cleaner, more powerful verbs to use once something has hijacked it.

Does a 20-Page Service Business Site Need This?

No. Not this year, and I would be lying if I told you otherwise to sell you an implementation.

Think about who benefits from WebMCP first. You need real transactional surface area, enough traffic that a fraction of agent-driven sessions is meaningful, and workflows tedious enough that a human would happily delegate them. Commerce catalogs with thousands of SKUs. Booking systems with complex availability. SaaS dashboards where the tedious multi-step task is the product. That is why Shopify shipped it across five point six million storefronts on day one and why nobody has shipped it for a plumber in Ohio.

A twenty page service site has one meaningful action: get in touch. An agent can already do that. It reads the page, finds the form, fills it in. WebMCP would make it slightly more reliable and save some tokens. That is a real gain of roughly nothing against a draft spec you will have to rewrite.

I have made this argument before in a different shape. The websites that win are not the ones that adopted every new thing fastest, they are the ones that stayed specific enough not to look like everything else. Chasing a Community Group draft is a way of being busy, not a way of being different.

The Small Thing Worth Doing Today

Here is what actually transfers, whether WebMCP ships as written, ships renamed, or quietly dies in committee.

Every agent that has ever tried to use a website, from the crudest DOM scraper to whatever comes next, fails on the same things. Forms with no labels. Buttons that are divs. Multi-step flows that depend on hover state. Confirmation pages that say "Thank you" without saying what happened. Error messages rendered as red text nowhere near the field. Availability, prices, and stock that only exist inside a JavaScript render that never settles.

Fixing those is not agent optimization. It is accessibility and clear form design, which you owed your human users anyway, and every hour spent there pays off regardless of which protocol wins. A screen reader and an AI agent fail on almost exactly the same page. That overlap is not a coincidence, and it is the only WebMCP preparation I would currently bill anyone for.

Then set a reminder for spring 2027. The things worth watching are narrow: does the spec leave Community Group status and enter an actual working group, does Chrome ship it unflagged past the origin trial, does a second agent vendor besides OpenAI consume tools, and does anyone solve the consent problem in a way that is not "trust our vendor policy." If three of those four happen, it is time to build. If they do not, you saved a quarter.

I could be wrong about the timing. Shopify moving five point six million storefronts in one afternoon is not nothing, and defaults have a way of becoming standards regardless of what the spec says. But being early to a draft that renamed its core method six months ago is not a strategy, it is a bet. Make sure you know you are placing one.

If you would rather spend that budget on a site that works properly for both people and machines, that is the work I do.