What WebMCP is, and what it is not

WebMCP is a proposed browser standard that lets a web page declare its capabilities as tools: named functions with a natural-language description and a JSON Schema for their arguments. An AI agent operating the browser reads that list and calls the functions directly, instead of parsing your markup or interpreting screenshots of it.

The name is deliberate. It borrows the tool vocabulary of the Model Context Protocol and moves it into the page, where the browser session already holds the visitor's login. That single detail is most of the appeal: no API keys change hands, no separate server is stood up, and a tool is only available to an agent when the person it is acting for is already signed in.

The shape of the API

The specification extends Document with a modelContext attribute. It is a secure-context-only interface with three methods and one event.

partial interface Document {
  [SecureContext, SameObject] readonly attribute ModelContext modelContext;
};

[Exposed=Window, SecureContext]
interface ModelContext : EventTarget {
  Promise<undefined> registerTool(ModelContextTool tool,
                                  optional ModelContextRegisterToolOptions options = {});
  Promise<sequence<RegisteredTool>> getTools(
                                  optional ModelContextGetToolOptions options = {});
  Promise<DOMString> executeTool(RegisteredTool tool,
                                 optional object inputObject = {},
                                 optional ModelContextExecuteToolOptions options = {});
  attribute EventHandler ontoolchange;
};

A tool is a dictionary with a name, a description, an inputSchema, an execute callback and optional annotations. Names are limited to between 1 and 128 characters drawn from ASCII alphanumerics plus underscore, hyphen and dot — a constraint worth knowing before you generate names from a CMS field.

dictionary ModelContextTool {
  required DOMString name;
  USVString title;
  required DOMString description;
  object inputSchema;
  required ToolExecuteCallback execute;
  ToolAnnotations annotations;
};

dictionary ToolAnnotations {
  boolean readOnlyHint = false;
  boolean untrustedContentHint = false;
};

registerTool accepts an AbortSignal, and aborting it unregisters the tool — which is how a single-page application keeps its tool list honest as the user navigates. It also accepts exposedTo, a list of origins allowed to see the tool inside the current document tree. The toolchange event fires whenever the set changes.

Two ways in

The imperative API is the one above: you write JavaScript, you register functions. The declarative API synthesises tools from annotated <form> elements, with the browser deriving the schema from the fields you already ship. For a contact form or a search box, that is a far shorter path than writing a handler.

Where it actually stands

This is where most write-ups become promotional, so here are the facts as they were on the date at the top of this page.

The specification is a Draft Community Group Report. It is not on the W3C standards track, and the API moved from navigator.modelContext to document.modelContext in July 2026 — a rename that broke every early adopter. Measured adoption outside demonstrations has been close to zero for most of the year, and for a while there were genuinely more validators than implementations.

So why build on it now

Because the demand side arrived. Until late August 2026 the argument against WebMCP was unanswerable: browsers shipped the API, no mainstream agent called it, so no publisher had a reason to register tools. That was a two-sided bootstrapping problem, and those usually resolve by not resolving.

Then OpenAI shipped WebMCP support in the ChatGPT desktop app. A consumer agent with a real user base now calls registered tools to search, book and buy. That does not make the standard safe — Gemini in Chrome still has to land for the curve to steepen — but it does change the question from will anyone ever call this to how much of the early traffic do you want.

What WebMCP does not replace

• A server-side MCP server. WebMCP tools exist only while a page is open, so an agent cannot discover your capabilities without visiting first. Headless and scheduled work still needs a server. See WebMCP versus MCP.
• Server rendering. Tools that sit in a bundle on a page whose content only appears after hydration are tools on a page most crawlers see as empty. Fix the rendering first.
• Accessible markup. Named controls and labelled fields still carry every agent that does not implement the standard — which today is most of them.
• An API. Tools call your own endpoints. If those endpoints are undocumented and untyped, WebMCP inherits the problem rather than solving it.

The through-line is that WebMCP is the last step, not the first. An agent has to reach the page, understand it and be able to act on it before a tool list means anything — which is why our Agent Readiness Score gives WebMCP 25 of 100 points rather than all of them.