What is WebMCP?

WebMCP gives a website a typed action surface for browser agents. Instead of forcing an agent to infer every action from pixels, labels or DOM structure, a page can register a tool with a name, description, input schema and execution function. The current WebMCP draft exposes that surface through document.modelContext.

The important status qualifier is proposed. The WebMCP specification published on 10 September 2026 is a Draft Community Group Report from the Web Machine Learning Community Group. It explicitly says it is not yet a W3C Standard and is not on the W3C Standards Track.

WebMCP versus MCP

MCP and WebMCP solve related but different discovery problems. MCP connects an AI host to a remote server that exposes tools and resources. WebMCP exposes tools from the live web page itself, inside the user's browser context. A service can use both: MCP for remote programmatic access and WebMCP for actions tied to the page the user is viewing.

ChatGPT Site Tools make the intent concrete

OpenAI now documents Site Tools in the ChatGPT desktop app. Site Tools use WebMCP so ChatGPT can work with capabilities a webpage exposes instead of relying only on clicking and typing. OpenAI says the feature is available when the account and selected model support it and the current page provides a matching tool; it currently applies to the desktop app's built-in browser, not Chrome.

That turns WebMCP from a purely theoretical publisher signal into a live integration surface for at least one major agent client. It still does not mean every visitor, browser or model can call every WebMCP tool, so builders should treat it as progressive enhancement rather than a replacement for normal web and API access.

What should a machine-economy site expose?

• • Read-only discovery tools that return current products, capabilities or machine-readable service contracts.
• • Quote or preflight tools that reveal price, asset, network, payee, availability and required inputs before a consequential action.
• • Deterministic status tools for order, payment or fulfilment reconciliation.
• • Explicitly named consequential actions whose descriptions make side effects unambiguous.
• • A clean handoff to the provider-owned API or payment policy layer when the action requires credentials, signing or settlement.

For agent commerce, the key design rule is separation of concerns. WebMCP can expose the action a browser agent may request, but a model should not become its own unconstrained wallet policy. Budget, counterparty checks, idempotency and signing authority still belong in deterministic controls outside free-form model reasoning.

Security matters more than tool count

The current WebMCP draft includes security analysis for malicious tool descriptions, malicious tool outputs and ambiguous consequential actions. It also defines tool annotations including read-only, untrusted-content and consequential hints. Those signals help an agent or browser reason about risk, but they are not a substitute for precise semantics and server-side authorization.

A tool called finalizeCart should not secretly perform an irreversible purchase. A payment or procurement tool should say exactly what it does, what authority it uses and which state transition it creates. An agent-ready site is easier for machines to operate because its contracts are clearer, not because it has more hidden automation.

The practical publisher stack

WebMCP should sit beside, not replace, the rest of a machine-readable surface. A strong publisher can expose a normal human page, a remote API with OpenAPI, MCP for tool clients, stable machine-readable metadata such as llms.txt or agent cards, and WebMCP for supported browser agents. Each surface should point to the same truthful product terms.