WebMCP vs MCP: what agents can use today
WebMCP lets a site owner expose JavaScript tools from a page; a WebMCP-aware browser agent discovers and calls them in that page's context. As checked October 2026, WebMCP is a W3C Community Group draft, and Chrome offers it behind a local flag or Origin Trial rather than as a stable default; ChatGPT's in-app browser supports it out of the box. (WebMCP spec (2026), Chrome's WebMCP guide (2026), OpenAI's WebMCP Challenge (2026))
WebMCP and an MCP server that drives a browser can work together. They put tools in different places and fail for different reasons.
What is WebMCP?
WebMCP is a browser API for page tools. The website registers a named tool with a description and input schema; the browser's agent can discover it and invoke JavaScript on that page. The current draft uses document.modelContext, not the older navigator.modelContext name. A Chromium change dated July 9, 2026, explicitly removed the old property in favor of the document property. (Chrome's imperative API guide (2026), Chromium's July 2026 change)
The WebMCP Community Group draft (2026) says it is not a W3C Standard and is not on the standards track. Chrome's guide, last updated October 1, says to join the Origin Trial from Chrome 149 or enable a flag for local development. Chrome stable was version 154 on October 1, 2026, so stable Chrome users still need the flag or a site enrolled in the trial. (Chrome Releases (2026))
To enable WebMCP in Chrome for local testing, open chrome://flags/#enable-webmcp-testing, enable it, and relaunch. In production, the site must be enrolled in the Origin Trial. The August 25 WebMCP Challenge page also says ChatGPT's in-app browser supports WebMCP out of the box. Those are the support statements I could verify; the draft remains subject to change. (Chrome's WebMCP guide (2026), OpenAI's WebMCP Challenge (2026))
How a site exposes a tool
For a custom action in a JavaScript app, use the imperative API. This is the small WebMCP example in Chrome's current guide; it is a docs-only snippet, not code I ran:
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}`;
}
});
For a normal HTML form, the declarative API can expose the form by adding toolname and tooldescription attributes; its fields become the input schema. Use declarative tools when the task is already a form submission. Use imperative tools when the site needs to run application logic or return a purpose-built result. Chrome documents both: the imperative API (2026) and the declarative API (2026).
The site still owns the action. Keep tools narrow: search_orders or add_item_to_cart gives an agent a defined operation, while a generic run_anything function gives it too much room. Mark a consequential action as such and keep human confirmation in the flow. The spec provides hints such as consequentialHint and untrustedContentHint, but they are signals to clients, not a substitute for server-side authorization or careful agent behavior. (Chrome's imperative API guide (2026))
WebMCP vs MCP
WebMCP is not a new MCP network transport. It is a page-facing browser API whose tools can be represented to an agent however the browser chooses. MCP itself uses JSON-RPC and defines standard stdio and Streamable HTTP transports between a client and a server. (WebMCP spec (2026), MCP transport specification (2025))
The table is checked October 2026. Each cell links to the source behind that comparison; the reliability and token-cost rows describe likely tradeoffs from the documented interfaces, not a controlled benchmark.
| Attribute | WebMCP | Browser-driving MCP server |
|---|---|---|
| Who builds the tools | The site owner registers page-specific JavaScript tools and schemas. (WebMCP spec (2026)) Checked October 2026. | The server author supplies generic browser actions; a site can optionally add its own WebMCP tools. Playwright MCP exposes page tools when present. (Playwright MCP (2026)) Checked October 2026. |
| Which sites work | Only pages that register tools, in a browser and agent that expose WebMCP. (Chrome's WebMCP guide (2026)) Checked October 2026. | Browser actions can navigate and interact with sites the browser can open, including pages with no WebMCP tools. (Playwright MCP (2026), Chrome DevTools MCP (2026)) Checked October 2026. |
| Protocol and transport | Page JavaScript API; the spec does not require a particular format between the browser agent and its model. (WebMCP spec (2026)) Checked October 2026. | MCP client/server JSON-RPC over stdio or Streamable HTTP. (MCP transport specification (2025)) Checked October 2026. |
| Likely failure mode | A site has no registered tool, the current browser lacks WebMCP, or the tool's schema/implementation no longer matches the app. (Chrome's WebMCP guide (2026)) Checked October 2026. | A page snapshot lacks a useful accessible target or its structure changes between observation and action; Playwright MCP uses accessibility snapshots and element references. (Playwright MCP (2026)) Checked October 2026. |
| Login and session | The spec assumes an agent can inherit the browser's logged-in identity and session. WebMCP adds no separate login transport. (WebMCP spec (2026)) Checked October 2026. | Depends on configuration: a server may use a persistent profile, isolated state, or connect to an existing logged-in browser. (Playwright MCP (2026)) Checked October 2026. |
| Security boundary | Page tools execute site-authored code. The draft discusses prompt injection through metadata and results; tools permissions and origin checks constrain exposure but do not make tool output trustworthy. (WebMCP spec (2026), Chrome's WebMCP guide (2026)) Checked October 2026. |
The server can gain access to page content and browser actions. Chrome DevTools MCP warns that its client can inspect and modify browser data; protect its connection and profile. (Chrome DevTools MCP (2026), MCP transport specification (2025)) Checked October 2026. |
| Availability | Chrome 154 stable needs a local flag or a site's Origin Trial enrollment; the Origin Trial began in Chrome 149. ChatGPT's in-app browser supports it out of the box. (Chrome's WebMCP guide (2026), Chrome Releases (2026), OpenAI's WebMCP Challenge (2026)) Checked October 2026. | Playwright MCP and Chrome DevTools MCP are available as MCP servers; they require a configured client and browser setup. (Playwright MCP (2026), Chrome DevTools MCP (2026)) Checked October 2026. |
| Context and token cost | A tool can return task-shaped fields instead of a whole page snapshot, but there is no apples-to-apples public token benchmark. (Chrome's WebMCP guide (2026)) Checked October 2026. | Accessibility snapshots and repeated observations can use context; payload size depends on the page and task. Microsoft's README says its CLI alternative is more token-efficient than the MCP interface. (Playwright MCP (2026)) Checked October 2026. |
The practical difference is coverage versus intent. A browser-driving server can use generic page controls on a site that has never heard of WebMCP. A WebMCP tool gives an agent a site-authored operation with a schema, but only when the page and browser-agent path support it. You can use both: Playwright MCP currently collects page-registered WebMCP tools by default and still has its browser actions for pages without them. (Playwright MCP (2026))
How the security model changes
WebMCP does not make prompt injection go away. Its own security section describes malicious instructions in tool descriptions and returned content, and notes that the section is non-normative. The spec also assumes browser agents may inherit login state and access sensitive context. Treat page output as untrusted input, and require explicit user confirmation for consequential actions. (WebMCP spec (2026))
The draft's tools Permissions Policy defaults to self; cross-origin iframes need permission to register tools, and cross-origin tools need explicit origin exposure. Sites can disable the feature with Permissions-Policy: tools=(). Those controls limit where tools can be registered or seen; they do not vouch for the tool's behavior. (Chrome's WebMCP guide (2026), WebMCP spec (2026)) For the broader issue of prompt injection through page content, see what security research found about prompt injection in AI browsers.
MCP adds a different boundary: the agent talks to a server that can control or inspect a browser. For local Streamable HTTP servers, the MCP spec recommends localhost binding and requires Origin validation. Chrome DevTools MCP says its client can inspect and modify browser data, and that usage statistics are enabled by default. Review the server's permissions and the browser profile it can reach before connecting it. (MCP transport specification (2025), Chrome DevTools MCP (2026))
Which one should you choose?
If you run an agent across unrelated or older sites, start with browser-driving MCP. It can navigate ordinary pages without waiting for each site owner to add tools. If you own a site and have a few high-value workflows—searching inventory, checking an order, filling a complex request—add WebMCP tools for those tasks and keep the regular interface working for other users. If you need both site-specific actions and broad coverage, combine them and let the agent prefer WebMCP where available.
For token cost, measure the same task both ways. Count tool definitions, calls, and input/output tokens. A tool that returns five order fields may be cheaper than repeated page snapshots, but a poorly scoped WebMCP result can still be large; the sources reviewed here do not publish comparable task-level measurements.
I build Octoweb, so weigh that accordingly. Octoweb is one browser-level MCP example: its server starts with the browser at localhost:3434/mcp, exposes 31 tools, and can work on pages the user can open. Page-authored content is returned inside an <untrusted> fence, and the server checks the Origin header; any local process can still reach the loopback server and read page content and history. See the browser MCP server reference.
WebMCP is worth adding now when your own site can define and test the operation, and your target browser-agent path supports it. Keep a browser-driving MCP server for pages that have not opted in. The MCP post on connecting Claude Code to a browser shows that other path.
Octoweb is free and open source, for macOS.
Install it →