WebMCP Is Live in ChatGPT and Codex: What Changed in August 2026

On 12 August we updated our scanner so that navigator.modelContext counts as a legacy signal and document.modelContext as the current one, because the W3C draft had moved the getter back in May. A week earlier, on 5 August, Shopify had switched WebMCP on for every Liquid storefront, in a developer changelog entry rather than a launch post. Two weeks later OpenAI turned it on in the ChatGPT desktop browser and Codex. In one month WebMCP went from origin trial to something an agent on your customer's laptop will actually call.

But look at any of those pages from outside a WebMCP-capable browser and you will find no trace of the tools. The HTML holds a small loader waiting for a browser that supports the API, and that is all. That gap is the more interesting half of this story.

What OpenAI actually turned on

On 25 August OpenAI's developer account posted that WebMCP support was coming to "the ChatGPT desktop app's built-in browser and ChatGPT Sites", with the line that matters for site owners: "When you visit a compatible website, ChatGPT or Codex can automatically use it to complete your task." The documentation calls the feature "site tools" and describes it as ChatGPT's implementation of the proposed WebMCP standard. In other words, OpenAI is the first mainstream agent that consumes WebMCP tools in production, ahead of Gemini in Chrome, which Google has only promised.

The rollout is narrower than the tweet suggests. Site tools work in the built-in browser of the desktop app, for ChatGPT Work and Codex, and only with the GPT-5.6 Sol and Terra models (Luna has it disabled). Enterprise and Edu workspaces are excluded for now. When a page registers tools, a "Site tools" entry appears in the address bar where users can inspect each tool definition and review a log of what was called. Every invocation gets a safety review before it runs, and the usual confirmation rules for purchases, messages, deletions and permission changes still apply.

Two details stand out. First, the docs state plainly that "website-provided tool definitions and results are untrusted content", which is the right posture and one I hope every other agent vendor copies. Second, OpenAI eats its own cooking: learn.chatgpt.com registers five tools of its own, including search_openai_docs and lookup_page, so Codex can search the documentation without scraping it.

There is a bit of history in the word "built-in browser", too. ChatGPT Atlas, the standalone browser OpenAI launched for macOS in October 2025, stopped working on 9 August. The browser now lives inside the desktop app next to Codex, which is exactly where WebMCP landed sixteen days later. Alongside the launch OpenAI opened a ten-day WebMCP Challenge with Google Chrome, Cloudflare, Shopify, Vercel, Render and Netlify as partners, submissions closing 3 September and winners on 23 September.

The month before: platforms moved first

OpenAI's announcement got the attention, but the bigger adoption event happened three weeks earlier, and Shopify gave it a changelog entry instead of a launch post. On 5 August Shopify's developer changelog noted that WebMCP tools are live on every Liquid storefront and on the Hydrogen developer preview, with "nothing to install or configure". Ten tools, from search_catalog and get_product through update_cart to proceed_to_checkout, all running in the shopper's own signed-in session. Every merchant on a stock Shopify theme became agent-callable overnight, and most of them will never know.

A day later Cloudflare published "Give any website a WebMCP interface" : a developer preview where a dashboard toggle makes Cloudflare's edge inject a bridge script into your HTML, and that bridge registers tool packs on document.modelContext without touching your origin. Whether generic, edge-generated tools are useful to an agent is a fair question. As a distribution mechanism it is hard to beat.

The spec kept pace. The pull request that moved the modelContext getter from Navigator to Document merged on 27 May, getTools() was specced in July, executeTool() and AbortSignal support followed in mid August, and on 12 August the repository gained an implementation-status page . As of this week that page lists Chrome (origin trial from Chrome 149), Edge (origin trial in Edge 150), Brave (experimental support in Leo) and, added on 26 August, ChatGPT Desktop. Firefox and Safari have open standards-position issues and no implementation.

My March post got the order wrong. Its timeline ran through the browsers: Chrome maybe enabling WebMCP by default late this year, Safari around the same time, Firefox in 2027. Nothing in it anticipated a platform with millions of storefronts and an agent vendor with hundreds of millions of users deciding that an origin trial was good enough. Neither of them needed the browsers to agree first.

What this changes for shoppers and shops

Strip the protocol away and the shopper's side is simple. Someone on ChatGPT Work or Codex opens your store in the desktop app and asks for "this jacket in a medium under 150 euros, in my basket". On a Shopify Liquid store the assistant searches the catalog, picks the variant and updates the basket through Shopify's tools, inside that shopper's own logged-in session, with their account and their existing basket. It can also answer questions from your shipping and returns policy, because search_shop_policies_and_faqs is one of the ten tools. Paying still ends in a confirmation prompt, because OpenAI treats purchases as consequential actions regardless of what the site declares.

For the shop, the gain is an assistant that completes the task instead of guessing its way through menus and filters, and that learns what your shop can do from short tool descriptions rather than from whatever it can parse off the homepage. That is a better experience for the customer and a more predictable one for you, since the tools only do what you exposed.

It also moves three things onto your watch list. The tool descriptions are what the assistant believes about your shop, so read them; on Shopify they were written by Shopify, and order management is among the tools switched on for you. Every tool runs in the customer's session with the customer's cookies, so a tool that skips a check your buttons enforce is a hole in your shop, whoever wrote it. And being callable does not bring the assistant to your door: it only finds your tools once it is on your page, which means search visibility and citations still decide who gets visited. Shops that are not on Shopify or Cloudflare get none of this yet, and to an assistant they remain a set of buttons to guess through while a competitor on a stock Shopify theme gets called directly.

The code you should write today

If you registered tools on navigator.modelContext after my March post, you are on the deprecated path. Chrome 150 deprecates the old location but keeps it as an alias, and OpenAI's browser exposes document.modelContext. OpenAI's documentation example fits in a dozen lines. Here it is in the same shape, with a real search tool filled in:

if (typeof document.modelContext?.registerTool === "function") {
  await document.modelContext.registerTool({
    name: "search_products",
    description: "Search the catalog by keyword. Returns up to 10 matches.",
    inputSchema: {
      type: "object",
      properties: {
        query: { type: "string", description: "Free-text search query" },
      },
      required: ["query"],
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    execute: async ({ query }) => {
      const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`);
      return { results: await res.json() };
    },
  });
}

The feature check at the top is mandatory, because in every browser except a handful of trials document.modelContext is undefined and the call throws. The readOnlyHint annotation tells the agent the tool changes nothing, so it belongs only on tools where that is true; consequential actions go through confirmation regardless of what you annotate. Then there is execute, which runs with the user's cookies, in the user's tab, so it should call the same endpoints with the same authorization your buttons already use. WebMCP is a second front door to logic you already have, and it should never become a side entrance around it.

Shopify's adapter is a nice example of how careful production code looks. The inline loader checks typeof (document.modelContext || navigator?.modelContext)?.registerTool === "function" and only then fetches a 65 KB module from cdn.shopify.com/storefront/webmcp/webmcp-0.1.1.js. Browsers without WebMCP never download it. That is the right trade-off for a script that runs on millions of pages.

What the tools look like from the outside

Open the page source of a stock Shopify Liquid store, say tonyschocolonely.com, patta.nl or mudjeans.eu, or of learn.chatgpt.com itself. All of them register tools, and the HTML shows almost nothing of it. Shopify's loader from the previous section is the entire footprint: a feature check and a CDN URL, with the ten tool definitions arriving only after a capable browser passes the check. On learn.chatgpt.com the registration sits in a minified Astro module, the tenth of eleven script tags, written as document?.modelContext ?? navigator?.modelContext. Where Cloudflare's bridge is switched on, the tools are whatever the edge decides at runtime.

None of these sites publish a /.well-known/webmcp.json, because the spec still has no site-level discovery mechanism. Our scanner has recognised the Shopify adapter and the feature-detect pattern since this week, but that is fingerprinting deployments we already know, and it says nothing about a site we have not seen before.

Call it the invisible tool problem: WebMCP tools exist only inside a browser that already supports the API, after your scripts have run. Nothing outside that running page can see them, and that includes an agent that has never opened your site, which therefore cannot plan around your tools or decide to visit you because of them. Fingerprinting known adapters, which is what we do now, scales exactly as far as the list of adapters someone maintains by hand. The Model Context Tool Inspector extension can list the tools on the page you are looking at, and that is currently the state of the art in discovery.

This is why I think the Cloudflare approach deserves more credit than "generic tools" suggests. The tools it generates may be crude, but Cloudflare sits in front of the page before it loads and could, in principle, answer the discovery question at the edge. Whether they do that is a product decision I cannot predict. Whoever solves discovery will shape which sites agents choose to visit, and right now nobody has.

What this means for you

If you run a stock Shopify Liquid theme, you already have WebMCP. Open your store in the ChatGPT desktop browser (on ChatGPT Work or Codex) and click "Site tools" in the address bar to see what an agent sees. The tool descriptions Shopify wrote are what ChatGPT reads to decide whether to search your catalog. Cloudflare customers get something similar with one toggle in the developer preview, which is a cheap way to find out whether agents even try to use tools on your site before you spend engineering time on proper ones.

Everyone else can register two or three tools on document.modelContext, behind the feature check, as thin wrappers around endpoints you already trust. Search and "get details for X" are the obvious first candidates because they are read-only. Test in the ChatGPT desktop app, or in Chrome with chrome://flags/#enable-webmcp-testing and the Model Context Tool Inspector extension. Then treat every call as untrusted input, the way you would treat a form post from a browser you do not control, because that is what it is.

Nobody can promise you that WebMCP is the standard that sticks. The spec is still a Community Group draft that neither Firefox nor Safari has committed to. Its API surface also changed under early adopters once already this year. What August did settle is that agents from OpenAI will call these tools on real pages starting now, and that a large slice of e-commerce already answers. That part is on the vendors. What your tools say when an agent calls them is still on you.

Sources

• Site tools, ChatGPT documentation (OpenAI, August 2026)
• OpenAI Developers on X, 25 August 2026
• ChatGPT and Codex changelog, entry of 25 August 2026
• Build agent-ready websites with ChatGPT (OpenAI Developer Community, 25 August 2026)
• The WebMCP Challenge (OpenAI, submissions close 3 September 2026)
• WebMCP support for Liquid and Hydrogen storefronts (Shopify developer changelog, 5 August 2026)
• Give any website a WebMCP interface (Cloudflare, 6 August 2026)
• Move the modelContext getter to Document (W3C Web Machine Learning CG, merged 27 May 2026)
• WebMCP implementation status (W3C Web Machine Learning CG, updated 26 August 2026)
• Join the WebMCP origin trial (Chrome for Developers, 9 June 2026)
• WebMCP developer guide (Chrome for Developers, updated 7 August 2026)
• Evolving Atlas into ChatGPT for browser-based agentic work (OpenAI Help Center)