What is WebMCP?
I build websites for the agentic web, and people ask me about WebMCP. My view: it’s too early to build for.
The short answer
I haven’t adopted it, few sites have, and I don’t think it will take off the way it was proposed. AI agents are getting better at using ordinary, well-built pages, so a separate tool layer may never be needed. Here is what it is, where it stands and what I’d do instead.
WebMCP lets a page register named tools in JavaScript, each with a description and an input schema, that a browser-based AI agent can discover and call. The specification is a Draft Community Group Report in the W3C Web Machine Learning Community Group, edited by people from Microsoft and Google, and it is not on the W3C Standards Track. Chrome runs an origin trial from Chrome 149, and the ChatGPT desktop app’s built-in browser supports a subset as “site tools”. Chrome says it is “under active discussion and subject to change”. It is an idea under test, not something your website needs.
Should you build for WebMCP now?
No. Few sites have adopted it, support is limited to trials and a subset of one app, and the specification is still changing. I haven’t adopted it on my own site or my team’s client work. My bet is that agents will keep getting better at using ordinary pages, which would make a separate tool layer unnecessary. A clear, accessible form helps every agent and every person today. A WebMCP tool helps only the few agents that support it, and only while the proposal survives. Watch it, and experiment only if you have the time to throw the work away.
How does WebMCP work?
WebMCP works by moving the agent from guessing to asking. Without it, a browser agent reads the screen and simulates clicks and typing. With it, the page registers tools through document.modelContext.registerTool(): a name, a plain-language description, an input schema, and an execute function that does the work in the page.
Chrome’s own example registers a tool like this (abridged from the Chrome for Developers Imperative API page):
await document.modelContext.registerTool({
name: 'toggle_layer',
description: 'Control pizza layers (sauce, cheese). Use "add", "remove", or "toggle".',
inputSchema: {
type: 'object',
properties: {
layer: { type: 'string', enum: ['sauce-layer', 'cheese-layer'] },
action: { type: 'string', enum: ['add', 'remove', 'toggle'] },
},
required: ['layer'],
},
execute: async ({ layer, action }) => {
await toggleLayer(layer, action);
return `Performed ${action || 'toggle'} on layer: ${layer}`;
},
});This is an API illustration, not a complete plugin: toggleLayer is application code omitted from the example. Feature-detect document.modelContext before registering, keep the ordinary interface, and validate inputs and permissions in the application.
To remove a tool, pass an AbortSignal when registering it and abort it later. Access is controlled by a tools permissions policy, which is off in cross-origin iframes unless the parent page allows it.
01
Register
The page declares a tool, for example book_call, with the inputs it needs.
02
Discover
An agent in the browser lists the tools the page offers.
03
Call
The agent supplies structured inputs. The application checks permissions and inputs, performs the allowed action and returns a result the person can verify. Consequential actions still need appropriate confirmation.
Could WebMCP matter for marketing teams?
If it took off, WebMCP would matter because the most valuable thing on a marketing site is an action, a booking, a quote request or a purchase, and today an agent has to guess its way through those forms. A registered tool removes the guessing. Chrome lists the benefits as higher accuracy for agent task completion, more reliability than simulated clicks, and keeping the brand’s own interface intact.
For a marketing team, that means the conversion path can work for a buyer’s agent as well as the buyer. It’s post-click value for a visitor that isn’t a person.
The honest caveat: I do not have a measured conversion result from a WebMCP deployment to offer here. Vendor demos and task benchmarks are not proof of extra revenue on your site. Start with one action and log attempts, errors, authorised completions and the business outcome.
Where does WebMCP work today?
Status (checked 26 October 2026)
- Specification Draft Community Group Report, 20 October 2026, W3C Web Machine Learning Community Group. “Not a W3C Standard nor is it on the W3C Standards Track”
- Google Chrome Origin trial from Chrome 149; local testing behind
chrome://flags/#enable-webmcp-testing. From Chrome 153 a tool can be removed without breaking a call already running - ChatGPT desktop app “Site tools” in the built-in browser, rollout dependent. Enterprise admins must allow it by workspace policy; not available in Edu workspaces
- Edge and Brave The project’s implementation record lists an Edge 150 origin trial and experimental support in Brave’s Leo
What it supports
- Specification JavaScript-registered tools via
document.modelContext - Google Chrome Imperative (JavaScript) and declarative (annotated HTML forms) APIs
- ChatGPT desktop app JavaScript tools in the top-level page only. Not HTML form attributes, not iframes
- Edge and Brave Experimental status does not establish that every built-in assistant can use every tool
Chrome exposing an API is different from an assistant using it. For ChatGPT, check the currently supported model, desktop version and workspace policy in OpenAI’s live documentation. The current Community Group draft covers JavaScript tools; Chrome still documents a form-attribute API that ChatGPT does not support.
Caption: WebMCP support by platform. Sources: W3C draft, Chrome for Developers and its Imperative API page (Chrome 153 change), OpenAI ChatGPT docs, all checked 26 October 2026.
WebMCP vs MCP: what’s the difference?
WebMCP and MCP (the Model Context Protocol) both offer tools to an AI client, but connect differently. MCP can connect to a local or remote server independently of an open page. WebMCP exposes tools in the page the person and browser agent are using, sharing that page’s session. A site may support both.
MCP server
- Where the tools live A server the AI client connects to
- Who calls them AI apps such as Claude or ChatGPT, with configured access
- Login and session Depends on the transport and service; for example remote OAuth or a local process
- Typical use Admin and data tasks: content, reporting, integrations
- Status, Oct 2026 Widely supported in AI clients
WebMCP
- Where the tools live The web page, in JavaScript
- Who calls them An agent in the browser, on the page the person is viewing
- Login and session Uses the page’s session; server-side authorisation still applies
- Typical use Front-of-site tasks: book, filter, apply, check out
- Status, Oct 2026 Proposed standard, origin trial
Caption: MCP and WebMCP compared.
The boundary matters more than the label. Expose a small set of actions, keep the application’s permission checks, and state what each action can change. A tool named “save draft” should not quietly publish; a booking call should not charge or create a second reservation on retry. My approach to permissions, review and recovery is on AI website security.
Common misconceptions about WebMCP
“WebMCP is a W3C standard.” Not yet. It’s a Draft Community Group Report, and the document itself says it isn’t on the Standards Track.
“It’s the same as running an MCP server.” MCP connects an AI application to a local or remote server. WebMCP exposes page tools in the browser session. Neither removes the need for access control.
“Add HTML attributes to your forms and every agent will use them.” Chrome documents a declarative HTML form API, but ChatGPT’s site tools ignore tools defined through form attributes. Register tools in JavaScript if you want both.
“WebMCP replaces accessibility.” People and browser agents still need a usable interface. Labels, keyboard access and clear states remain important; keep them when you add callable tools.
“It’s like llms.txt.” llms.txt is a guide to content; WebMCP exposes actions a compatible agent can call. One can help navigation without proving the other works. Read does llms.txt work? for the evidence.
What should you do next?
- Get the basics right first. Make the main form agent-ready: labels, appropriate autocomplete, real controls, clear errors and a safe handoff for abuse challenges.
- Don’t build it for production yet. Agents are getting better at using normal pages, and a working form helps all of them. If you still want to experiment, the steps below keep it safe.
- Pick one action. The one with the most value per completion, usually “book a call” or “request a quote”.
- Prototype it locally with
chrome://flags/#enable-webmcp-testing, registering the tool in JavaScript in the top-level page, not in an iframe. - Feature-detect and keep the form. Only register when
document.modelContextexists. People still use the normal form. - Enforce the boundary. Keep server-side permissions and validation. Require appropriate human confirmation before a commitment; a tool description or read-only hint does not enforce it.
- Test failures and retries. Prevent duplicate bookings, expose errors, log a verifiable result and define how to recover. Do not assume cancelling a browser call undoes work already committed.
- Join the origin trial only for a controlled experiment, and re-check the docs each month. The API is still changing.
If you want your forms and booking path working for people and agents today, book a free call. You’ll talk with me or my team, and my team at WP Creative does the work.
What should a first pilot prove?
Start read-only, such as finding an available appointment, then test a permitted write in a safe environment. Record the agent, browser, account, inputs, expected confirmation, result and final record. Try invalid inputs, expired sessions, double submissions and a timeout after submission. Keep a human path when the tool is unavailable. Success means the intended task completed once, under the intended permissions, with a result you can check. It does not mean the site is now more citable.
Questions about WebMCP
Who is behind WebMCP?
WebMCP is incubated in the W3C Web Machine Learning Community Group. The draft lists four editors: Brandon Walderman and Samuel Dallstream from Microsoft, and Khushal Sagar and Dominic Farolino from Google. Chrome documents it and runs the origin trial, and OpenAI supports a subset in the ChatGPT desktop app.
Is WebMCP safe to use?
WebMCP does not make a website trustworthy. The draft discusses prompt injection and privacy risks, and OpenAI treats website tool definitions and results as untrusted. Keep authentication, server-side permission checks and input validation. A read-only annotation is a hint, not enforcement. Confirmation must match what will actually happen.
Does WebMCP work with WordPress?
A WordPress theme or plugin can register page tools with JavaScript. A concrete example is WordPress Playground’s September 2026 integration: its outer page advertises tools from the embedded WordPress site through a proxy. That does not add WebMCP to every WordPress installation. The WordPress MCP Adapter and Abilities API remain separate connection paths.
Does WebMCP help SEO or AI citations?
The primary sources reviewed here do not establish an SEO or AI citation lift. WebMCP exposes actions a compatible agent can call. Test task completion and the resulting business outcome separately; do not add it expecting more traffic.
Which AI agents support WebMCP?
As of 26 October 2026, the project implementation record lists Chrome and Edge origin trials, ChatGPT Desktop support and experimental support in Brave’s Leo. These are different kinds of support. Check the assistant, model, account policy and exact API before building; a browser trial alone does not mean its assistant will call your tools.
