WebMCP — Browser Agent Interaction

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, 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) 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

	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:

<form tool-name="search-products" tool-description="Search the catalog by keyword">
  <input type="text" name="q" tool-param-description="Search query, e.g. 'red shoes'">
  <button type="submit">Search</button>
</form>

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:

{
  "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	Outside the browser	JSON-RPC tools on a server	OAuth / API keys
A2A	Anywhere	A whole agent with named skills	Agent-level auth
OpenAPI	Anywhere	REST endpoints with schemas	Per-endpoint scheme
SKILL.md	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.
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 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

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).
Add the attributes. tool-name on the <form> element, tool-description on the form, tool-param-description on each <input>.
Use lowercase-hyphen names. search-products, not searchProducts.
Write descriptions for an agent, not a human. Lead with the verb. Be specific about the parameter type (e.g., "Search query string, 1-200 chars" not just "search").
Publish the manifest. /.well-known/webmcp.json listing the same tools. This is the discovery path for agents that don't scan the DOM.
Test in Chrome Canary with the experimental flag enabled.

Common errors scanners flag

No manifest — /.well-known/webmcp.json returns 404. The check is informational; site can still expose form-level tools.
Manifest returns HTML — SPA catch-all routes return the homepage instead of the JSON file.
Form annotations without descriptions — tool-name is set but tool-description is missing, so agents can't tell what the form does.
Invalid tool name — uppercase, underscores, or special chars in tool-name.
Annotations on non-form elements — only <form> elements should carry tool-name.

FAQ

Is WebMCP a fork of MCP?

No. They are separate specs from separate working groups with separate architectures. They share the "tools" concept (a named, parameterized action an agent can call) but the protocols, transports, and trust models are completely different. The naming is unfortunate.

Will Chrome's WebMCP work in Firefox or Safari?

Not currently. Firefox and Safari have not implemented the spec. Cross-browser support depends on the spec maturing past Draft status, which is a multi-year process.

Should I add WebMCP if I already have MCP?

Yes if your service has a website with forms that users fill out today. The two address different agent contexts: server-side agents use MCP; user-in-the-loop browser agents use WebMCP. Sites with both let agents pick the right surface.

Does AgentGrade penalize sites without WebMCP?

No. WebMCP is an informational check. The score is not penalized for missing it. It is a positive signal when present.

Is WebMCP secure?

The security model inherits from the browser: same-origin enforcement, the user's existing session, CSRF protection. An agent can only call tools the user could call manually on the same page. There is no escalation surface beyond what the user already has. The risk is that the agent acts on the user's behalf without the user understanding what's happening — a UX problem, not a security boundary problem.

What replaces /.well-known/webmcp.json if I host my forms in an iframe?

Same-origin rules apply: an agent in the parent page can call form-level tools in same-origin iframes. Cross-origin iframes are isolated. The manifest should be on the iframe's origin.

Does WebMCP work with single-page apps?

Yes, but forms must be present in the DOM at the time the agent scans. SPAs that hydrate forms on user interaction may need to declare them in the manifest instead.

When will WebMCP ship to stable Chrome?

No public timeline. The spec is Draft; production rollout depends on spec stability, security review, and demonstrated developer adoption.

Spec maturity

Draft, not shipped. WebMCP is a W3C Community Group draft, available behind an experimental flag in Chrome Canary only. The spec may change. Adoption is early — annotating forms is cheap insurance for sites that want to be ready when production browser support arrives.

Learn more

WebMCP specification — the W3C draft
WebMCP GitHub repository — proposals and discussions
Chrome: When to use WebMCP and MCP — the official positioning
MCP — the server-side counterpart
A2A — agent-to-agent protocol

agentgrade