WebMCP in ChatGPT and Codex: what changed in August 2026

WebMCP lets a website register tools for an agent visiting its live page. ChatGPT Work and Codex can use these site tools in the desktop app's built-in browser, where support depends on the model and workspace settings. The 25 August 2026 changelog records the initial rollout.

On 12 August we updated our scanner to treat navigator.modelContext as a legacy signal and document.modelContext as the current one. Published markup can show implementation clues, but checking which tools register at runtime requires a compatible browser session.

What OpenAI actually turned on

OpenAI's documentation describes site tools as ChatGPT's implementation of the proposed WebMCP standard. A page must provide tools before an agent can discover them.

The launch supported GPT-5.6 Sol and Terra, with Enterprise and Edu excluded. Availability has changed since then. As checked on 6 October 2026, the site-tools documentation lists GPT-5.6 Sol and GPT-6 Sol. Site tools are disabled for GPT-5.6 Luna. Enterprise requires an administrator to allow site tools; Edu remains unavailable. Rollout and the current page's tools also affect access.

The built-in browser supports JavaScript-registered tools in the top-level page; tools defined through form attributes or registered inside iframes are unavailable as site tools. Agents may still interact with forms using regular browser capabilities.

In a supported session, the "Site tools" entry lets users inspect tool definitions and the call log. Tool calls receive a safety review, and sensitive actions still follow the application's confirmation rules.

Two details stand out. First, the docs state plainly that "website-provided tool definitions and results are untrusted content", which is the right posture for other agent vendors to copy. Second, OpenAI uses WebMCP on its own site: 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.

The phrase "built-in browser" has some history. 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 Shopify's rollout came three weeks earlier and reaches more sites. 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 callable by agents overnight.

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 way to reach many sites at once, it works.

The spec moved at the same time. 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.

The February version of my WebMCP post got the order wrong (I have since rewritten it). Its timeline ran through the browsers, with Chrome maybe enabling WebMCP by default late this year, Safari around the same time and Firefox in 2027. It did not anticipate that a platform with millions of storefronts and an agent vendor with hundreds of millions of users would decide an origin trial was good enough. Neither needed the browsers to agree first.

What this changes for shoppers and shops

From the shopper's side the protocol is invisible. 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. It learns what your shop can do from short tool descriptions, not from whatever it can parse off the homepage. The tools only do what you exposed, so the result is more predictable for you.

It also adds three things to watch. 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 the February version of my WebMCP 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 shows a careful pattern. 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, which suits 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 scotch-soda.com, 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 decides how agents find sites with tools. Nobody has solved it yet.

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 see whether agents use tools on your site before you spend engineering time on your own.

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 has already changed once this year, while early adopters were building on it. 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)