What Is WebMCP?

WebMCP is a browser-native web standard (Draft Community Group Report, W3C Web Machine Learning Community Group, published July 2026) that lets websites expose JavaScript functions as callable “tools,” via the document.modelContext API and its registerTool() method, so AI agents can act on a page directly instead of parsing the DOM or taking screenshots. It adapts concepts from Anthropic’s Model Context Protocol (MCP) for the browser but is not identical to MCP: WebMCP tools run client-side, in the user’s authenticated session, and browsers are free to expose them via MCP or other function-calling formats.

That is the whole idea in two sentences. The rest of this post covers the mechanics, where it diverges from MCP, who is building it, and why it matters if you run a website an AI agent might one day need to act on rather than just read.

How WebMCP Works

The spec adds one new entry point: document.modelContext, a read-only attribute on the Document interface. A page calls its registerTool() method to hand the browser a description of something it can do:

document.modelContext.registerTool({
  name: 'search-posts',
  description: 'Search this blog's posts by keyword',
  inputSchema: {
    type: 'object',
    properties: {
      query: { type: 'string' }
    },
    required: ['query']
  },
  async execute({ query }) {
    return searchLocalIndex(query);
  }
});

A few things matter about that shape. The tool’s execute function runs in the page’s own JavaScript context, with access to whatever state, cookies, and session the page already has, so a tool can act on data the agent could never legitimately scrape from the rendered HTML. inputSchema is a JSON Schema, the same format MCP tool definitions use, which is a deliberate compatibility choice: an agent that already knows how to call an MCP tool does not need a second mental model for a WebMCP tool.

Two optional annotations shape how an agent treats the tool without inspecting its code. readOnlyHint: true tells the caller the tool only reads data and never changes state, which is the signal an agent can use to invoke it without asking the user to confirm first. untrustedContentHint: true marks a tool whose output should be treated as untrusted, arbitrary text pulled off the page rather than something the site vouches for, which matters once an agent starts feeding tool output back into its own reasoning.

One gap worth naming: the spec also describes a declarative path, annotating a plain HTML <form> so the browser can synthesize a tool from it without any JavaScript. As of the current draft, that section is explicitly marked incomplete. Section 4.3 of the spec reads, in full: “This section is entirely a TODO. For now, refer to the explainer draft.” The only implemented path today is the imperative registerTool() call shown above.

The API’s own name has already changed once. Early implementations and the browser’s origin trial exposed this surface as navigator.modelContext, and several community explainers, including the informative AIKR technical notes, still document it that way. The current Draft Community Group Report moved the attribute onto Document instead, so document.modelContext is what the spec defines today. If you find code or a tutorial using navigator.modelContext, it is either targeting an earlier draft or an implementation that has not caught up yet. Our own WebMCP + SvelteKit implementation guide was written against the polyfill’s navigator.modelContext surface; treat the spec, not that post, as the source of truth for the current attribute name.

WebMCP vs. MCP (Anthropic)

WebMCP borrows MCP’s vocabulary, tool names, descriptions, JSON Schema inputs, on purpose: an agent that already knows how to call an MCP tool needs almost no new logic to call a WebMCP one. But the two solve different problems at different layers.

	WebMCP	MCP (Anthropic)
What it is	A browser web API (document.modelContext)	A server-side protocol (JSON-RPC over stdio or HTTP)
Where it runs	Client-side, inside the page, in the user’s open tab	A separate server process the agent connects to
Who exposes tools	Any website, by calling registerTool() in its own JavaScript	Whoever stands up and hosts an MCP server
Auth model	Inherits the browser’s existing session and cookies	The server implements its own auth (OAuth, API keys, etc.)
Discovery	The agent finds tools by loading the page	The agent finds tools by connecting to a known server endpoint
Relationship	Adapts MCP’s tool-calling shape for the browser	The protocol WebMCP borrows vocabulary from

The practical difference: MCP needs a server you build, deploy, and authenticate against. WebMCP needs nothing but JavaScript already running in a page a user has open. That makes WebMCP a fit for the huge number of interactive web apps that will never justify standing up an MCP server, and a poor fit for anything that needs to run without a browser tab open, since the spec has no headless mode.

Who’s Building It

WebMCP is developed under the W3C Web Machine Learning Community Group. The current Draft Community Group Report lists three editors: Brandon Walderman (Microsoft), Khushal Sagar (Google), and Dominic Farolino (Google). “Draft Community Group Report” is a specific, informal status inside the W3C process, work a Community Group has agreed to publish, not a document that has entered the formal W3C Recommendation track or received the patent and cross-vendor review that track requires.

Chrome has been the primary implementation vehicle, running WebMCP as an origin trial so developers can test against it ahead of any stable release. That combination, a two-browser-vendor editor list plus one browser actually shipping trial code, is normal for a proposal at this stage, and it is also why the API surface itself is still moving: the navigator.modelContext to document.modelContext change happened while the origin trial was live.

Why It Matters for AI Agents

Everything discussed so far solves one specific problem: an agent visiting a page today has to either parse the DOM (brittle, breaks on any redesign) or take a screenshot and reason over pixels (slow, imprecise, and blind to anything off-screen). Both approaches guess at what a page lets you do. WebMCP tools state it directly.

That distinction matters most for the categories of site where guessing is expensive. In Agent Commerce Readiness, the argument for the Agentic Commerce Protocol is that agents fall back to scraping, redirecting the user, or skipping a merchant entirely when a checkout flow isn’t machine-readable; WebMCP is the same argument one layer down, for any interactive action, not just payment. In why AI isn’t citing your website, the underlying pattern is that AI systems reward structured, extractable content over content that requires interpretation, the same logic that makes answer engine optimization work for text now applies to interactivity: a page that declares its tools is easier for an agent to act on correctly than a page an agent has to reverse-engineer.

None of that requires waiting for WebMCP to reach a final W3C Recommendation. The imperative registerTool() path is implemented today behind an origin trial, and a page can register tools now, the same way our SvelteKit implementation does, well ahead of the spec settling. The sites that get this working while the API is still a Draft Community Group Report will be the ones agents can already act on correctly once broader browser support lands.