## What is WebMCP?
WebMCP is a W3C Community Group draft proposal that lets AI agents interact with websites *through the user's browser* rather than over a separate API. Sites annotate existing HTML forms with attributes that declare them as callable tools; the browser exposes those tools to an agent via a new `navigator.modelContext` API. The proposal is backed by Google and Microsoft and is currently available behind an experimental flag in Chrome Canary.
The name is a deliberate echo of [MCP](/kb/mcp), Anthropic's Model Context Protocol, but the two are distinct specs that solve different problems. MCP defines a JSON-RPC protocol for an agent to call tools on a server. WebMCP defines a browser API for an agent to call tools that already exist as forms on a page. They share the "tools" concept and not much else.
## Why WebMCP matters
The traditional path for agent-website integration is: the site publishes an API ([OpenAPI](/kb/openapi)) or an MCP server, the agent authenticates separately, and calls run over a backchannel. This works for first-party agent integrations but breaks down for the long tail of websites that have valuable functionality but no API team to build a parallel surface.
WebMCP takes the inverse approach: the site already has a form to do the thing, the user is already logged in, the browser already has the session. Why build a parallel API? Annotate the existing form with a few attributes, and an agent in the browser can call it directly — inheriting the user's auth, the site's CSRF protections, and the browser's permissions model for free.
The use cases are mostly *user-in-the-loop* agent flows: an agent acting on behalf of a logged-in user on the site the user is currently visiting. Booking a flight, filing a support ticket, posting a comment — anywhere a form would normally take a human submission.
## How WebMCP differs from [MCP](/kb/mcp)
| | MCP | WebMCP |
|---|---|---|
| Who calls whom | Agent → server | Agent → browser → server |
| Where the agent runs | Outside the browser | Inside or alongside the browser |
| Authentication | OAuth 2.1 / API keys | The user's existing browser session |
| Transport | JSON-RPC over HTTP/SSE | Browser internal API (`navigator.modelContext`) |
| What you build on the site | A dedicated MCP endpoint | Attribute annotations on existing HTML forms |
| Connection lifetime | Persistent across sessions | Ends when the tab closes |
| Discovery | MCP registry / well-known | DOM scan + `/.well-known/webmcp.json` manifest |
The architectures are nearly opposites. MCP gives external agents a stable backend interface; WebMCP gives in-browser agents access to the existing frontend. A site can publish both: MCP for headless agent integrations, WebMCP for user-in-the-loop browser flows.
## How WebMCP works
There are two cooperating pieces: **DOM annotations** (per-page) and an optional **manifest** (per-site).
**1. Annotated forms.** A site marks any HTML form as agent-callable with three custom attributes:
```html
```
The browser-side WebMCP runtime scans the DOM for `tool-name` elements, builds a tool list, and exposes it to the agent. When the agent invokes `search-products` with `q: "running shoes"`, the browser fills in the form and submits it on the agent's behalf — through the user's session.
**2. The manifest.** A site can publish `/.well-known/webmcp.json` declaring tools that may not be visible on every page (or that involve multi-step flows). The manifest format mirrors MCP's tool descriptors:
```json
{
"spec": "webmcp/0.1",
"tools": [
{
"name": "search-products",
"description": "Search the product catalog",
"url": "/search",
"method": "GET",
"parameters": [
{
"name": "q",
"type": "string",
"description": "Search query"
}
]
}
]
}
```
The manifest gives agents a discovery path that doesn't depend on DOM scraping. AgentGrade checks both: a present `/.well-known/webmcp.json` and any `tool-name` attributes on the homepage.
## WebMCP vs other agent-interop layers
| Spec | Where the agent lives | What's exposed | Auth |
|---|---|---|---|
| **WebMCP** | In the browser | Annotated HTML forms | User's session |
| **[MCP](/kb/mcp)** | Outside the browser | JSON-RPC tools on a server | OAuth / API keys |
| **[A2A](/kb/a2a)** | Anywhere | A whole agent with named skills | Agent-level auth |
| **[OpenAPI](/kb/openapi)** | Anywhere | REST endpoints with schemas | Per-endpoint scheme |
| **[SKILL.md](/kb/skills)** | Anywhere | Prose playbook | N/A |
WebMCP is the only one that runs inside the user's browser. The others all assume the agent is on a server or in a chat client; WebMCP assumes the agent is the *user's user agent*, with all the trust and authority that implies.
## Current status
WebMCP is a **Draft Community Group Report** under the W3C Web Machine Learning Community Group. As of mid-2026:
- The spec is published at [webmachinelearning.github.io/webmcp](https://webmachinelearning.github.io/webmcp/).
- The reference implementation is behind an experimental flag in Chrome Canary (chrome://flags/#enable-web-mcp).
- It is **not** shipped in any production browser. Firefox and Safari have not announced plans.
- The spec is expected to change before reaching W3C Working Draft status.
Because the user-side surface is gated on browser support, sites that ship WebMCP today are early — they're betting on the spec stabilizing and browsers shipping. The cost of being early is low (a few HTML attributes); the upside is being agent-callable for the first wave of in-browser agents that adopt the spec.
## Who's backing WebMCP
- **Google** — Chrome team published the proposal and ships the prototype.
- **Microsoft** — co-editor on the spec; co-publisher of a [Chrome developer blog post](https://developer.chrome.com/blog/webmcp-mcp-usage) explaining the relationship between MCP and WebMCP.
- **W3C Web Machine Learning Community Group** — the governance body.
Notably absent: Anthropic (the MCP author) and OpenAI. The spec is positioned as complementary to MCP, not competitive, but the overlap in naming has caused some confusion.
## How to add WebMCP to your site
1. **Pick the forms that matter.** Don't annotate every form on the site. Pick the 1-3 most valuable agent-callable actions (search, submit, subscribe).
2. **Add the attributes.** `tool-name` on the `