What Is WebMCP? Your Website's API for AI Agents

WebMCP (Web Model Context Protocol) is a proposed browser standard that lets a website expose its features to AI agents as structured, callable tools, through the document.modelContext API. Instead of an agent taking a screenshot of your page and guessing where to click, your website hands it a list of the things it can do and the exact parameters each one needs. Authored by engineers from Google and Microsoft through the W3C Web Machine Learning Community Group, first proposed in August 2025 and opened by Chrome as an early preview on February 10, 2026, WebMCP is now in a public origin trial that runs from Chrome 149 to Chrome 162. Shopify and Commerce.com switch WebMCP tools on by default for their stores, and Stripe builds them into its checkout pages, so a store on any of them may already give agents tools its owner never switched on. None of these companies has published how often agents call them.

When I first wrote about Chrome becoming an AI agent, Gemini could already scroll, click, and fill forms autonomously. That was the first half of the agentic-Chrome story: agents getting better at pretending to be human. WebMCP is the second half, and it's the more interesting one, because it stops the pretending entirely.

Updated November 9, 2026: On October 8 the spec dropped the HTML-form way of exposing tools, so registering them in JavaScript is now the only way in the standard. This version removes the form method from the how-to, adds Shopify's checkout tools and Stripe's payment tools, adds how to check whether your website already exposes WebMCP tools, notes that no company has published how often agents call them, and corrects the rename: Chrome 152 removed navigator.modelContext in August.

Updated October 31, 2026: Chrome extended the origin trial from Chrome 156 to Chrome 162. Microsoft Edge has run a WebMCP origin trial since Edge 150 in July, ChatGPT has called WebMCP tools since August, and in October Cloudflare said almost 100,000 Commerce.com domains give agents WebMCP tools. Apple's WebKit team opposes WebMCP and Mozilla is neutral.

Updated August 10, 2026: The tool-registration getter moved from navigator.modelContext to document.modelContext. Chrome 150 deprecated the old name and kept it as an alias, so existing code still runs and the change is easy to miss. Adds a section on the rename, and updates the status section for Shopify and Cloudflare making WebMCP default-on across a large share of commerce in August.

Updated June 9, 2026: WebMCP moved from a Chrome 146 flag preview to a public origin trial running Chrome 149 through 156. Corrected the unverified "Edge ships native WebMCP" claim (it isn't in Microsoft's official Edge 147 release notes), added WebMCP-vs-MCP-vs-llms.txt and browser-support comparison tables, added John Mueller's endorsement of WebMCP over llms.txt, and documented the four-tool WebMCP implementation now running on No Hacks.

Hey, I'm Sani. Get my Saturday email on how AI is changing how we use the internet.

Nobody asked us if we wanted the internet changed. So I check what AI is actually doing to it, and tell you whether it's good, bad or pointless.

Email address

Send it to me

Free, one email a week. Unsubscribe any time.

Contents

• The problem with agents clicking buttons
• What WebMCP actually is
• WebMCP dropped HTML-form tools on October 8, 2026
• Stripe and Shopify make the agent ask before it pays
• Where WebMCP stands now
• Shopify, Commerce.com and Stripe already put WebMCP tools on stores
• The API moved from navigator to document
• WebMCP vs MCP vs llms.txt
• Which browsers support WebMCP?
• Your store's WebMCP tools are worth reading the way an agent reads them

The problem with agents clicking buttons

Current agentic browsing works through visual UI automation. Chrome's auto browse uses Gemini to "see" web pages and interact with them the way a human would. Click this button. Fill this form. Scroll down. Look for the checkout link. Other agentic browsers also do a version of this.

It works. It's also so very fragile.

Every time you redesign your website, change a button label, or rearrange its layout, agents relying on visual cues have to re-learn the interface. It's the same brittleness that plagued web scrapers for two decades (any Beautiful Soup fans here?), now applied to AI. The web UI was designed for human eyes and human hands. Forcing agents to navigate it visually is working against the grain of the medium. It CAN work. Very often, it will not.

WebMCP takes a different approach entirely. Instead of making agents better at pretending to be humans, it lets websites speak to agents in their native language: structured data with defined schemas.

What WebMCP actually is

WebMCP is MCP for the browser tab.

If you've been following along with my coverage of the Model Context Protocol, you know MCP is the universal adapter that connects AI agents to tools and data sources. MCP servers run on backend infrastructure, exposing tools that AI systems can call.

WebMCP brings that same model to client-side JavaScript. Your website becomes the MCP server. Tools are defined and executed right in the browser, with no separate MCP server to run.

The proposal comes from the W3C Web Machine Learning Community Group, authored by engineers from Microsoft and Google. It was first proposed in August 2025, and Chrome opened an early preview on February 10, 2026. It's being developed as an open web standard, not a Chrome-exclusive feature. The spec doesn't tie it to one AI model, so any agent could call the tools. As of November 2026, the mainstream one that does is the browser built into the ChatGPT desktop app.

Today the agent has to figure out what your website can do. With WebMCP, your website tells the agent what it can do. A website registers tools using the document.modelContext API, with each tool's inputs and outputs described by a JSON Schema. (If you have seen navigator.modelContext in older write-ups, including earlier versions of this one, see the rename below.)

document.modelContext.registerTool({
  name: 'searchFlights',
  description: 'Search available flights by route and date',
  inputSchema: {
    type: 'object',
    properties: {
      origin: { type: 'string', description: 'Departure airport code' },
      destination: { type: 'string', description: 'Arrival airport code' },
      date: { type: 'string', description: 'Travel date' }
    },
    required: ['origin', 'destination', 'date']
  },
  execute: async (params) => {
    const results = await searchFlightsAPI(params)
    return { content: [{ type: 'text', text: JSON.stringify(results) }] }
  }
})

An AI agent visiting this page doesn't need to find the search form, figure out which fields to fill, or guess at the submit button. It discovers the searchFlights tool, reads the JSON Schema, calls the function with the right parameters, and gets structured data back. Where the website has the tool, the agent makes one call instead of reading the page and clicking through it.

WebMCP dropped HTML-form tools on October 8, 2026

Since October 8, 2026, the WebMCP spec has one way for a website to offer tools: register them in JavaScript with registerTool(), as in the example above. The pull request that changed it says: "The spec now focuses on the imperative registerTool() API."

Earlier versions of this article, and most WebMCP write-ups from the first half of 2026, also describe a second way: adding attributes such as toolname to an existing HTML form, so the form doubles as a tool with no JavaScript. That version is out of the spec. The pull request says it is "still being explored" in a separate explainer, and Chrome's WebMCP guide, last updated the day before the change, still describes it. It may come back, but you shouldn't build on it today. I liked it, because it was the route a website with good, well-labelled forms could take almost for free. For now, a website that wants WebMCP tools needs someone to write the JavaScript, or a platform that does it for them.

Since November 2, 2026 a tool can also describe what it returns, with an outputSchema, the same name MCP uses, so the agent knows the shape of the answer before it asks.

Stripe and Shopify make the agent ask before it pays

The WebMCP spec lets a website mark a tool with consequentialHint, and Stripe tells agent builders to get the person's confirmation before calling one. Shopify asks for the same before its final checkout step. Tool calls go through the browser, not directly from agent to page. The hint is one of several labels a website can put on a tool, and the one that matters for a store. The spec uses it for a tool whose result is "significant, real-world, or non-reversible, ex: booking a flight, transferring money."

The hint is only a label. The spec says "a malicious site can omit or misrepresent those hints," and that keeping an agent from being manipulated is "primarily the responsibility of the agent's own security model." So the payment companies write the rule into their documentation. Stripe sets the hint on its payment-submission tools and tells agent builders: "Before calling a tool with this hint, get the user's confirmation. Don't interpret the hint itself as confirmation." Shopify's checkout tools say the same in their own words: "Before you call complete_checkout, show the buyer the current order and total, and get their permission to place it."

The agent can find the product, fill in the address and pick the payment method, and Stripe's and Shopify's documentation says a person approves the total. Whether each agent actually asks is up to the agent, and neither company has published how often agents do, which is why the security side of WebMCP is worth reading before you trust it with a card.

Where WebMCP stands now

WebMCP has graduated from a behind-a-flag prototype into a public origin trial that runs from Chrome 149 through Chrome 162. The Chromium "Intent to Experiment" was filed on May 15, 2026 and approved three days later, for Chrome 149 through 156. In September 2026, Google asked to extend the trial to Chrome 162, citing developer feedback that suggested improvements to the API, and Chrome's status page now lists the trial running to Chrome 162. An origin trial means you can register your origin and run WebMCP on real users in production, not just on your own machine behind chrome://flags. On the infrastructure side, Cloudflare's Browser Run added WebMCP support on April 15, 2026, the first large-scale agent-infrastructure vendor to run against the API, through an experimental pool of browsers running Chrome beta.

Microsoft co-authored the spec alongside Google through the W3C, and with Edge 150 in July 2026 it opened a WebMCP origin trial in Edge, the second browser to do so. Microsoft's trial page lists March 30, 2027 as the end date. Secondary write-ups had claimed native support as early as Edge 147, but Microsoft's own Edge 147 web-platform release notes (April 9, 2026) did not list WebMCP, while the other on-device AI APIs of the moment (Prompt, Writer, Rewriter, Proofreader, WebNN) were there. The other two browser makers have said where they stand: Apple's WebKit team opposes WebMCP, and Mozilla's position is neutral.

In a Reddit thread reported on June 2, 2026, Google's John Mueller called the rival llms.txt file "purely speculative for now," noting that the file has existed for years and none of the AI systems use it, and said he likes "the WebMCP approach, as well as the commerce integrations" because "they have clear goals & processes" (reported by Search Engine Journal).

On August 5, Shopify switched WebMCP on for every Liquid storefront and the Hydrogen developer preview: catalog search, cart management, checkout and policy lookup, exposed as callable tools, with nothing to install and no merchant asked. A day later, Cloudflare made it available, as a developer preview, to any website behind Cloudflare with no code change and no origin change. Shopify alone took every one of those storefronts from "a website could expose tools" to "this website already does."

Later in August, OpenAI added WebMCP to ChatGPT: ChatGPT Work and Codex can discover and use a website's tools in the browser built into the ChatGPT desktop app, and people see them under "Site tools" in the address bar. The spec's implementation list has carried "WebMCP is supported in ChatGPT Desktop" since August 26. In an October 21, 2026 post, Cloudflare said almost 100,000 Commerce.com domains give agents WebMCP shopping tools, on by default with an opt-out for each merchant.

It is still early in the ways that matter. Community Group draft status, a narrow set of consuming agents, an API name that moved in May and a form method that left the spec in October are all real constraints. But "on by default in Shopify and Commerce.com stores, in an origin trial you can run on live users" is a very different place than "a proposal behind a flag," which is where this was six months ago.

The number that would settle whether any of this matters is how often agents call these tools. Shopify, Commerce.com, Stripe, Cloudflare, Google and OpenAI have each said where the tools are switched on, and none of them has said how many times an agent used one to search a catalog, fill a cart or pay. Until someone does, read every adoption claim, including the ones in this article, as a count of stores that have the tools, not of shoppers whose agents used them.

Shopify, Commerce.com and Stripe already put WebMCP tools on stores

Shopify Liquid storefronts, Commerce.com storefronts and Stripe's payment pages expose WebMCP tools by default, so a store on any of them may have tools its owner never switched on:

Shopify adds one condition that matters for anyone building an agent: "Shopify uses WBA to identify your agent. Without it, bot detection might deprioritize or block your requests." WBA is Web Bot Auth, a way for an agent to sign its requests so a website can tell who sent it. So the tools are open, and the agents that can't say who they are may still be turned away.

How to check your website. Open it in Chrome 150 or later, open the developer console, and type document.modelContext. If it says undefined, WebMCP is not switched on for that page in your browser. If it returns an object, run await document.modelContext.getTools(). An empty list means the page registers no tools, and anything else is the list an agent reads, with each tool's name and description.

I ran it on November 9, 2026. On a Shopify store, getTools() returned 12 tools, each with a description written for an agent: search the catalog, get product details, browse collections, ask the store a question, create, read, set and empty the cart, get the store's Universal Commerce profile, go to the customer's orders, and proceed to checkout. Nobody at the store had to write any of them. On nohacks.co the same line threw an error, because document.modelContext doesn't exist there.

The API moved from navigator to document

WebMCP's tool-registration getter moved from navigator.modelContext to document.modelContext. Chrome 150 deprecated the old name, and Chrome 152, stable since August 25, 2026, removed it. Anyone who learned this API in the first half of 2026 learned a name that no longer exists in current Chrome, and code that still uses it registers no tools.

The Web Machine Learning Community Group moved the getter from Navigator to Document in the May 27, 2026 spec draft, on the reasoning that tools belong to a specific page rather than to the browser.

I found out the way most people will. Testing WebMCP on a Shopify store on August 6, 2026, I called the API using navigator.modelContext, the name from the original draft, and Chrome answered with a deprecation warning pointing at document.modelContext instead. Nothing failed. The call worked, and the only signal that anything had changed was a warning I would have missed if I had not been reading the console. Since Chrome 152 even the warning is gone: the old name returns nothing, and a page that only uses it registers no tools at all.

The short history, because the name has moved twice:

If your code also has to run in Chrome 149 to 151, feature-detect rather than picking one:

const modelContext = document.modelContext || navigator.modelContext

On document.modelContext today: registerTool() to add a tool, getTools() to list what a page has registered, executeTool() to run one.

WebMCP vs MCP vs llms.txt

Three agent-facing standards get confused constantly because the acronyms look alike. They answer different questions:

The short version: MCP connects agents to your back end, llms.txt describes your identity to agents, and WebMCP exposes your capabilities to agents in the browser. WebMCP and llms.txt are the two competing bets on the agentic web, identity versus capability, and that split is worth its own article.

Which browsers support WebMCP?

Your store's WebMCP tools are worth reading the way an agent reads them

Websites now have, or can have, two interfaces: a visual one for humans and a set of tools for agents. If you sell on Shopify, Commerce.com or through Stripe's checkout, the second one was built for you, and the useful thing to do is look at it: check what your store tells an agent with getTools(), and read the tool names and descriptions the way an agent would. If you run your own website, there is no shortcut left in the spec. Adding tools means writing JavaScript.

I implemented WebMCP on No Hacks itself, the JavaScript-API way. When a WebMCP-capable browser loads the website, it registers six read-only tools through document.modelContext.registerTool. Two cover the glossary: list_terms to discover every term, and define_term to return a definition with its source URL. Four cover the publication: search_articles and search_episodes, which use the same search as the No Hacks MCP server, and get_article and get_episode, which return a short summary and the link to the page. Each tool reads from the same data as the human-facing pages, so an agent and a reader never get different answers, and every call is counted, so I'll know whether any agent ever uses them. Running it on a live website found the roughest edge on my own website. The tools registered in Chrome with the testing flag on, but normal Chrome needs an origin-trial token, and for months No Hacks didn't serve one. Nothing fails when the token is missing. There is no error and no warning, and the tools never exist for anyone in normal Chrome. I added the token on November 9, 2026, and the same getTools() line that threw an error that morning now lists all six.

No platform or agent maker has published evidence that agents prefer stores with WebMCP tools, so whether the tools change which store an agent picks is still open. A website with tools gives an agent a direct path, and a website without them makes it guess at the buttons. It sounds like the agent should prefer the direct path, and it may, but nobody has shown that it does. Meanwhile, tool names, schemas and descriptions are now something a store has, often without knowing, and it's worth reading yours the way you'd read your meta descriptions.