--- title: "What is WebMCP? In-browser tools for AI agents" description: WebMCP is a W3C proposal that lets a web page register tools with the browser via navigator.modelContext, so an in-page AI agent can act on the page instead of screen-scraping it. How it works, how it differs from MCP, and how to make your site WebMCP-ready. last_updated: 2026-06-08 canonical_url: https://agent-ready.dev/what-is-webmcp --- # What is WebMCP? > A browser API that lets a web page hand an in-page AI agent real tools via `navigator.modelContext` — so agents act on your site instead of screen-scraping it. ## 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](https://webmachinelearning.github.io/webmcp/) 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](https://agent-ready.dev/mcp) connects an agent to an **external server** over 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](https://agent-ready.dev/what-is-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](https://agent-ready.dev/what-is-nlweb), llms.txt, AGENTS.md, and protocol manifests. To see where your site stands, run a full [agent-readability scan](https://agent-ready.dev/agent-readability-score). ## 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. --- Read the full guide on the web: Score your site for agents: ## Sitemap See the full [sitemap](https://agent-ready.dev/sitemap.md) for all pages on agent-ready.dev.