How is WebMCP different from A2UI or MCP Apps?

Direction. A2UI and MCP Apps are agent-to-UI: the agent emits an interface (a JSON component tree, or an HTML widget) that a host renders. WebMCP is page-to-agent: the page exposes actions/tools the agent can call. One renders UI for the user; the other gives the agent verbs to act with. A WebMCP-enabled checkout page might expose an apply_coupon tool; an A2UI agent might render the coupon form.

Which browsers support WebMCP?

As of mid-2026, only Chrome Canary, behind a flag, ships an experimental navigator.modelContext. The spec is being developed at the W3C with Google, Microsoft, Mozilla, and Apple participating, and the API (exposed in secure/HTTPS contexts) is still changing. Real-world adoption is effectively zero — code should feature-detect and no-op where the API is absent.

What is WebMCP? In-browser tools for AI agents

What is WebMCP?

WebMCP (“Web Model Context Protocol”) is a browser API that lets a website expose its features as structured, callable tools. Through navigator.modelContext.provideContext(), a page registers tools with the browser; an in-page AI agent can then discover and invoke them directly — instead of taking a screenshot, guessing where to click, and hoping the DOM didn’t move.

It is being developed at the W3C Web Machine Learning Community Group by engineers from Google and Microsoft, with Mozilla and Apple also at the table. Each tool is a { name, description, inputSchema, execute } descriptor: the inputSchema is JSON Schema, and execute does the work and returns { content: [{ type: 'text', text }] }.

WebMCP vs MCP: page tools vs server tools

MCP connects an agent to an external serverover the network — a remote tool or data provider the agent calls directly. WebMCP connects an agent to the page the user is already on: the website registers tools with the browser, and the browser mediates between those in-page tools and the agent.

The practical difference is context. WebMCP tools run inside the live browser session, with the user’s existing login and page state — no separate auth, no second copy of your API. MCP is agent-to-server; WebMCP is agent-to-page. They’re complementary: a site can ship both.

WebMCP vs A2UI: verbs vs views

A2UI and MCP Apps are agent-to-UI: the agent emits an interface (a declarative JSON component tree, or an HTML widget) that a host renders for the user. WebMCP is page-to-agent: the page exposes actions the agent can take. One gives the user a view; the other gives the agent verbs. A checkout page might expose an apply_coupon WebMCP tool, while an A2UI agent renders the coupon form — different layers of the same agentic web.

How do agents discover the tools?

At runtime, through the browser — not through a file a crawler fetches. Tools are registered imperatively in JavaScript via provideContext(); there is no static manifest or /.well-known/ artifact today. A declarative, app-manifest form is discussed as a future iteration but is not implemented. Because registration happens in page script and is mediated by the browser, the tools are invisible to a server-side scanner that doesn’t execute the page — which is exactly why agent-readability scanners (this one included) can advertise a WebMCP surface but can’t yet statically verify one on an arbitrary site.

Browser support and maturity

WebMCP is early. As of mid-2026, only Chrome Canary, behind a flag, ships an experimental navigator.modelContext, and the API (exposed only in secure HTTPS contexts) is still changing. Real-world adoption is effectively zero. That makes shipping a WebMCP surface today a forward-looking, leadership move rather than a feature users can rely on — so any implementation must feature-detect and degrade to a clean no-op everywhere else.

How do I make my site WebMCP-ready?

Three moves:

Feature-detect. Check "modelContext" in navigator and do nothing when it’s absent — that’s almost every browser today.
Register your key actions as tools. Call navigator.modelContext.provideContext({ tools }) with one tool per meaningful action, each a { name, description, inputSchema, execute }.
Keep it safe.Make handlers idempotent, gate sensitive actions behind the user’s existing session, and validate inputs — an agent can call these as readily as a user can.

Agent Ready ships this surface itself: every page registers scan_site and get_scan via navigator.modelContext, so an in-browser agent can run an agent-readability scan without touching the form. WebMCP sits alongside the other agent-readiness signals — NLWeb, llms.txt, AGENTS.md, and protocol manifests. To see where your site stands, run a full agent-readability scan.

Frequently asked questions

What is WebMCP?: WebMCP (Web Model Context Protocol) is a browser API, proposed at the W3C Web Machine Learning Community Group by engineers from Google and Microsoft, that lets a web page expose its features as callable tools. Through navigator.modelContext.provideContext(), a page registers tools — each with a name, description, JSON Schema input, and an execute handler — and an in-page AI agent can discover and invoke them directly instead of guessing where to click.
How is WebMCP different from MCP?: MCP (Model Context Protocol) connects an agent to an external server over the network — a remote tool/data provider the agent talks to directly. WebMCP connects an agent to the page the user is already on: the website registers tools with the browser, and the browser mediates between those in-page tools and the agent. MCP is agent-to-server; WebMCP is agent-to-page, running in the existing browser session with the user's logged-in state. They're complementary, not competing.
How is WebMCP different from A2UI or MCP Apps?: Direction. A2UI and MCP Apps are agent-to-UI: the agent emits an interface (a JSON component tree, or an HTML widget) that a host renders. WebMCP is page-to-agent: the page exposes actions/tools the agent can call. One renders UI for the user; the other gives the agent verbs to act with. A WebMCP-enabled checkout page might expose an apply_coupon tool; an A2UI agent might render the coupon form.
How do agents discover a page's WebMCP tools?: At runtime, through the browser. Tools are registered imperatively in JavaScript via navigator.modelContext.provideContext(); there is no static manifest or /.well-known/ file today (a declarative app-manifest form is discussed as a future iteration but is not implemented). Because registration happens in page script and is mediated by the browser, a server-side crawler can't see the tools without executing the page — discovery is in-browser, not a fetchable artifact.
Which browsers support WebMCP?: As of mid-2026, only Chrome Canary, behind a flag, ships an experimental navigator.modelContext. The spec is being developed at the W3C with Google, Microsoft, Mozilla, and Apple participating, and the API (exposed in secure/HTTPS contexts) is still changing. Real-world adoption is effectively zero — code should feature-detect and no-op where the API is absent.
How do I make my site WebMCP-ready?: Feature-detect 'modelContext' in navigator, then call navigator.modelContext.provideContext({ tools }) with one tool per meaningful page action — each a { name, description, inputSchema, execute } where execute does the work and returns { content: [{ type: 'text', text }] }. Keep handlers safe and idempotent, gate anything sensitive behind the user's existing session, and no-op cleanly when the API is unsupported. Agent Ready does exactly this: every page registers scan_site and get_scan.