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.

WebMCP exposes tools in an open web page. A site can register public tools or tools in a signed-in session; authorization still belongs to the application. To inspect an implementation, enable WebMCP in Chrome and test one tool in the browser.

The shape of the API

The specification extends Document with a modelContext attribute. The following abbreviated interface shows registration, discovery and execution. Compare the current draft with the browser version you test.

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 and is not on the W3C standards track. Check the current API and your target browser before shipping. The migration guide explains the change from navigator.modelContext to document.modelContext.

So why build on it now

OpenAI now documents WebMCP tools for ChatGPT Work and Codex in ChatGPT's built-in browser. That gives publishers a concrete client to test against, although access depends on rollout, model and workspace availability.

For now, start with a task a visitor can complete in the page and verify that the client can discover and call the registered tool. OpenAI's documentation currently covers the imperative API; declarative form tools and iframe tools are not yet supported there. A published integration path is useful evidence, but it does not establish how much traffic WebMCP will bring to any site.

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.

An agent has to reach the page, understand it and be able to act on it before a tool list helps. Our Agent Readiness Score currently gives WebMCP 10 of 100 points. The other checks cover discovery, content access and the ability to complete a task.