ChatGPT supports WebMCP now

What was announced

On the evening of 25 August 2026, OpenAI's developer account said it is adding WebMCP support to the ChatGPT desktop app's built-in browser and to ChatGPT Sites, so that visiting a compatible website lets ChatGPT or Codex use that site to complete a task. The suggested demo is to ask Codex to build a WebMCP-enabled app and deploy it to Sites.

Two things are worth separating, because the announcement and the documentation do not say quite the same thing. The announcement names the desktop browser and Sites. The developer documentation lists the supported surfaces as the ChatGPT desktop app built-in browser, ChatGPT Work, and Codex, and adds two limits people will hit: site tools are unavailable in Enterprise and Edu workspaces, and they require the GPT-5.6 Sol or Terra models. If you test this and see nothing, check the model before you check your code.

What WebMCP actually is

WebMCP lets a web page hand an AI agent a set of callable functions instead of making it guess at your interface. The page registers tools; an agent driving the browser discovers them and calls them directly. It is the same idea as an MCP server, except the tools are implemented in client-side JavaScript and live only as long as the agent is on the page.

The API is document.modelContext, and registering a tool looks like this:

if (typeof document.modelContext?.registerTool === "function") {
  await document.modelContext.registerTool({
    name: "get_page_title",
    description: "Read the title of the current page.",
    inputSchema: { type: "object", properties: {}, additionalProperties: false },
    annotations: { readOnlyHint: true },
    execute: async () => ({ title: document.title }),
  });
}

Five parts: a name, a description an agent reads to decide whether to call it, a JSON Schema for the inputs, annotations describing what the tool does to the world, and an async function that does the work. The feature-detect matters, because in a browser without the API the whole thing should be a no-op rather than an error.

The detail that matters: no token

The headline is not that another client can call tools. It is that OpenAI's documentation says no origin trial token or registration is required.

Until now, shipping WebMCP to real visitors has meant Chrome's origin trial: you request a token for your origin, embed it in a header or a meta tag, and it expires on a date Google picks. That is a perfectly reasonable way to run an experiment, and it is also a leash. It caps who can adopt the API, it does not survive a customer putting your page on their own domain, and every origin has a countdown attached.

A second independent implementation, with no gatekeeping, changes what the API is. One vendor shipping something behind a trial is an experiment. Two vendors shipping the same interface, one of them without a token, is a thing you can build against. That is the actual news, and it is why the shape of the announcement matters more than the demo in it.

Annotations decide whether you interrupt the user

Here is the part that will bite people, and it bit us. We have had WebMCP tools on this site since June, registered against Chrome's origin trial. Reading OpenAI's documentation, the tools were missing annotations, so we added them the same day.

It matters because of how the client treats a call. Each invocation gets a safety review before it runs, and the browser asks the user to confirm anything consequential: sending a message, making a purchase, deleting data, changing permissions. Annotations are how a tool declares which kind it is. Mark a genuine read with readOnlyHint: true and it can run without stopping to ask. Leave it undeclared and a harmless lookup gets the same treatment as a delete, which means your agent integration works but nags.

The vocabulary is the same one MCP servers use, and the discipline is the same: describe the side effects honestly, keep inputs narrow, and let your existing authentication and validation do their job rather than building a tool that steps around them. It is worth reading tool definitions and their results as untrusted content, because that is exactly how the client treats them. A tool named get_weather does not prove anything about what the function does.

Tools in a page are not tools on a server

If you already run a remote MCP server, WebMCP is not a replacement for it, and the two want different tools.

A remote server is added once and follows the user everywhere. It is the right home for the durable verbs of your product, and it can hold credentials, rate limits, and audit trails on your infrastructure. A page's tools are ambient and temporary: they exist while the agent is on that page, they can see what is on screen, and they vanish on navigation. The right tools for a page are the things that only make sense there. Filling in the form in front of you. Acting on the record being displayed. Publishing the thing you just generated.

Ours are on both. The remote server at api.stacktr.ee/mcp exposes the product. The tools on this site exist so a browsing agent can publish a page without leaving the page it is on, and the same catalog drives the command palette for humans, so the two cannot drift apart.

The part about publishing

Full disclosure: we build Stacktree, so treat this as us describing where we sit rather than neutral advice.

The demo in the announcement is "build a WebMCP app and deploy it to Sites", and it is a good demo. It is also worth noticing what deploying to a vendor's own surface does and does not give you. It renders for the people who can reach that surface. It is a different question from whether the page has an address you can send to a client, whether the link keeps working when you revise the page, and who is allowed to open it.

That gap is the one we care about. An agent that can build a page should be able to give it a real URL, private by default, that a person outside the tool can open with no account. That is what publishing over MCP does, and what the WebMCP tool on this site does from inside the browser. The interesting version of today's news is not that agents can drive apps. It is that the pages you hand to other people can start carrying their own verbs: ask for the current version, leave a comment, export it. A page on a link can do that anywhere it lands.

What to watch

This is hours old at the time of writing, so hold it loosely. Three things would change the picture:

1. Whether the model gate loosens. Site tools currently require GPT-5.6 Sol or Terra and are off in Enterprise and Edu workspaces. That is a large slice of exactly the audience that builds internal tools.
2. Whether it escapes the built-in browser. Support in the desktop app's own browser is not the same as support wherever the user browses. Chrome's extension route and OpenAI's in-app browser reaching parity would matter more than the initial launch.
3. How the injection surface is handled. A page that can offer tools to an agent is a page that can try to steer one. The client treating tool definitions as untrusted is the right instinct; the interesting question is what happens the first time a site abuses it.

The short version: WebMCP now has two implementations and one of them needs no permission slip. If you have been waiting to see whether this API was real before spending an afternoon on it, that wait is over.