What is WebMCP, and does your website need it yet?

On 25 August 2026, OpenAI's changelog carried a line most website owners never saw: in the ChatGPT desktop browser, ChatGPT Work and Codex "can use tools provided by a website to work with the page." So what is WebMCP? It is a draft web standard that lets a page register named actions, such as book_appointment, with a description and a typed list of inputs, so an AI agent calls them instead of guessing which button to press.

WebMCP does not help anyone find your website. It helps an agent that has already arrived get the job done without breaking something.

In short:

• A page publishes named actions with typed inputs; the agent calls your code instead of clicking around.
• It is a draft: a Chrome origin trial ending at Chrome 156, plus early Edge, Brave and ChatGPT support.
• It brings no visitors. Try it first on a booking form.

What is WebMCP, in plain terms?

Think of the intercom panel by the door of a block of flats. Nobody has to try every button: each one has a printed label, and pressing it rings exactly one flat. WebMCP gives a web page that panel for agents.

Today an agent using your site works the way a stranger would. It reads the page, works out which box is the date field, clicks, waits, reads again, and hopes the calendar widget behaves. Chrome's documentation calls this actuation: the agent "simulating manual mouse clicks and text input, as though it were the human user". Every step is open to interpretation, and a booking form with a custom date picker gives it plenty to interpret.

With WebMCP, the page says instead: here is a tool called check_availability, it takes a date in YYYY-MM-DD form, and it returns free times. Here is another called book_appointment, it takes a name, a phone number, a date, a time and one of three services, and it creates a real booking. The agent picks the tool, fills the inputs, and your own JavaScript does the work, in the page the person is looking at.

The specification describes a page that does this as, in effect, a Model Context Protocol server "that implement[s] tools in client-side script instead of on the backend". It is published by the W3C's Web Machine Learning Community Group, edited by engineers from Microsoft and Google, and its status section is blunt: "It is not a W3C Standard nor is it on the W3C Standards Track." The latest draft is dated 2 October 2026. This is a proposal still being argued over in public, not settled plumbing.

How is WebMCP different from MCP and from an API?

MCP, the Model Context Protocol, connects an AI app to a server. Your tools live on the back end and work whether or not anyone has your website open. WebMCP tools live in the page itself and only exist while that page is open.

OpenAI's own site tools page draws the line clearly. MCP suits work that is independent of a page, like searching records through an API. WebMCP suits moments "when you and the agent need to see the same thing, such as when editing a canvas or exploring a dashboard." The explainer on GitHub adds the practical reason a small team should care: a back-end integration means rebuilding the user's login, state and context on a separate server, while WebMCP reuses the session, the validation and the code the site already has.

Three consequences follow, and they are worth stating plainly:

• The tool runs as the signed-in user. No new API keys, no separate auth. That is the attraction and also the reason to be careful.
• The person watches it happen. Chrome's guidance is that tools "execute on your webpage visibly". When our test booking went through, the page updated in front of us.
• Agents still have to visit. Chrome lists this as a limitation: "Clients and browsers must visit a site directly to know if it has callable tools." There is no directory. WebMCP is not a ranking signal, and it will not put you in an AI answer. For that side of the problem, see what makes ChatGPT cite a website.

What does a WebMCP tool look like in code?

Here is the booking example above as a real module. It follows the API in Chrome's imperative guide and the current spec, where tools hang off document.modelContext. (Early tutorials used navigator.modelContext; the spec moved the getter to document on 27 May 2026, and in Chrome 154 the old name is gone.)

// booking-tools.js: expose a small booking flow to AI agents with WebMCP.
// Runs where document.modelContext exists (Chrome 149+ origin trial, or the
// chrome://flags/#enable-webmcp-testing flag). Elsewhere it does nothing.

const SLOTS = { "2026-10-09": ["10:00", "11:30", "15:00"] }; // stand-in for your API

async function checkAvailability({ date }) {
  return { date, slots: SLOTS[date] ?? [] };
}

async function bookAppointment({ name, phone, date, time, service }) {
  if (!(SLOTS[date] ?? []).includes(time)) {
    return { ok: false, error: `No free slot at ${time} on ${date}. Call check_availability first.` };
  }
  SLOTS[date] = SLOTS[date].filter((t) => t !== time);
  // Update the visible page too, so the person watching sees what the agent did.
  document.querySelector("#status").textContent = `Booked: ${service} for ${name}, ${date} at ${time}`;
  return { ok: true, reference: `BK-${date.replaceAll("-", "")}-${time.replace(":", "")}`, name, phone, date, time, service };
}

export async function registerBookingTools(signal) {
  const mc = document.modelContext;
  if (typeof mc?.registerTool !== "function") return false; // no WebMCP: the normal form still works

  await mc.registerTool({
    name: "check_availability",
    description: "List free appointment times on a given date. Call this before booking.",
    inputSchema: {
      type: "object",
      properties: { date: { type: "string", format: "date", description: "Date as YYYY-MM-DD" } },
      required: ["date"],
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    execute: checkAvailability,
  }, { signal });

  await mc.registerTool({
    name: "book_appointment",
    description: "Book one appointment in a free slot returned by check_availability. Creates a real booking.",
    inputSchema: {
      type: "object",
      properties: {
        name: { type: "string", description: "Customer's full name" },
        phone: { type: "string", description: "Mobile number with country code" },
        date: { type: "string", format: "date", description: "YYYY-MM-DD" },
        time: { type: "string", pattern: "^\\d{2}:\\d{2}$", description: "24-hour HH:MM from check_availability" },
        service: { type: "string", enum: ["Haircut", "Colour", "Consultation"] },
      },
      required: ["name", "phone", "date", "time", "service"],
      additionalProperties: false,
    },
    annotations: { consequentialHint: true },
    execute: bookAppointment,
  }, { signal });

  return true;
}

A few details in there are doing real work. readOnlyHint tells the agent that checking slots changes nothing. consequentialHint marks the booking as a real-world, hard-to-undo action, which Chrome's guide says lets "agents and browsers enforce mandatory user confirmation prompts". The additionalProperties: false line is in OpenAI's own example, so keep it. And the error message on a taken slot tells the model what to do next, because an agent reads your error text as instructions.

We ran this in Chrome 154 with the testing flag on, then called the tools from the page with getTools() and executeTool(), which is how an in-page agent sees them. This is the real output:

Two things surprised us. Registering a second tool with the same name fails with an InvalidStateError, exactly as the spec says, so a framework that re-mounts a component needs the signal to unregister first. And Chrome 154's executeTool() rejected a plain object with "Failed to parse input arguments" and only accepted a JSON string. The spec and Chrome's guide say an object, and the guide notes string arguments are deprecated from Chrome 155. That is what an origin trial looks like from the inside: the browser and the paper are a version apart.

For a plain HTML form there is also a declarative route: add toolname and tooldescription attributes to the form and the browser builds the schema from its fields and labels. Be aware that OpenAI's documentation says the ChatGPT browser does not support declarative tools, or tools inside iframes, so today the JavaScript version reaches more agents.

Does WebMCP actually make agents better?

The strongest evidence is early and indirect. The best measurement we found is a 2025 arXiv preprint by D. Perera, webMCP: Efficient AI-Native Client-Side Interaction for Agent-Ready Web Design. Note the lower case: it tests an earlier, independent proposal that embeds action metadata in the page, not the W3C API above. But it asks the same question. If you hand the agent a list of actions instead of the page's HTML, what changes?

Screenshot: D. Perera, webMCP: Efficient AI-Native Client-Side Interaction for Agent-Ready Web Design (arXiv 2508.09171), courtesy of arXiv.

Across 1,890 real API calls on seven models from OpenAI and Anthropic, in shopping, login and dynamic-content tasks, token use fell by 67.6% on average, with answer quality at 97.9% against 98.8% for the HTML baseline.

Read the fine print before you quote it. Speed was mixed: the shopping flow got 13.1% faster, but login got 19.8% slower. It is a single-author preprint with three scenarios, and the author lists the gaps: authoring overhead, single-page apps that change under the metadata, and a security review that was "design review rather than comprehensive penetration testing". What it supports is the modest claim at the heart of WebMCP. A described action is cheaper for a model to use than a page it has to read, and about as reliable.

Which browsers and AI agents support WebMCP today?

Fewer than the noise suggests, and all of them are early. Here is where things stood on 4 October 2026, from each vendor's own pages:

That last highlighted dot matters. An origin trial is time-limited by design. When it ends at Chrome 156, the feature ships, changes shape or stops, and the history so far (a renamed entry point, argument formats changing between versions) says to expect change. Some coverage this autumn has claimed millions of storefronts are already enabled; we could not confirm that at any primary source, so we leave it out.

Screenshot: Join the WebMCP origin trial, courtesy of Chrome for Developers, captured 4 Oct 2026.

Should a small business add WebMCP now?

For most small sites, not yet as a priority. For a few, it is a cheap experiment worth running. The test is whether you have a task that people already complete on your site, that an agent could fumble, and that your code already handles.

Whatever you build, a short checklist keeps it safe:

• Feature-detect document.modelContext and leave the normal interface untouched for everyone else.
• Keep inputs narrow: enums for services, a pattern for times, additionalProperties: false.
• Reuse your existing validation and permissions. OpenAI's docs say it outright: tool definitions and results are untrusted, and a tool's claim that it only reads data "isn't proof of what it does."
• Mark user-written content you return with untrustedContentHint, since reviews and messages are where prompt injection hides.
• Return results the agent can check, like a booking reference, and errors that say what to do next.
• Test with Chrome's Model Context Tool Inspector extension first.

If you run a booking business, the more useful first step is often the one our chatbot vs live chat comparison covers: deciding what your own site's assistant should handle. WebMCP is how you expose the same actions to outside agents later. If any of these terms are new, our glossary has short definitions.

Where this studio stands

We think WebMCP is the most sensible idea in the "agent-ready website" conversation, because it asks the site to describe what it already does rather than to perform for a crawler. We also think it is early. It is a community draft, one browser's trial with an end date, one AI vendor's desktop browser, and an evidence base that is one preprint deep.

So for clients we treat it as a progressive enhancement on top of a site that already works: forms with proper labels, real error messages, a booking flow that does not need a custom widget to survive. When a client's site has a task worth exposing, our AI website assistant work builds the tools on the same functions the page uses, marks anything consequential, and keeps the person in charge of the final click.

A question to ask your developer this week: if an agent had to book one appointment on our site, which three functions would it need, and do we already have them? If the answer is yes, WebMCP is about fifty lines away. If the answer is "it would have to click around", the trouble starts before WebMCP does.