WebMCP Is Not a Replacement for MCP

WebMCP does not replace MCP. The two protocols sit at different layers. MCP connects an agent to a service it can use from anywhere. WebMCP connects an agent to the website the user has open, with the page’s live session and the user watching.

That distinction matters for architecture. A team that treats WebMCP as an MCP replacement will build a tool that stops working when the tab closes. A team that treats MCP as the only option will miss the live interface context that makes a browser agent useful.

What MCP does

What WebMCP does

WebMCP is a proposed browser standard for exposing a page’s own functions as tools. A page registers each tool with a name, a natural-language description, a JSON Schema for its inputs, and an execute function. A browser agent discovers those tools and calls them through the browser.

There are two ways to register them. The imperative API uses document.modelContext.registerTool() in JavaScript. The declarative API annotates an existing HTML form with attributes such as toolname and tooldescription, and the browser turns the form fields into the tool’s input schema.

WebMCP tools are ephemeral. They exist while the page is open. They can use the live DOM, the current session, and cookies, and the browser can show the action to the user as it runs. Once the user navigates away or closes the tab, the agent cannot call the tool.

The difference in one table

Question	MCP	WebMCP
Purpose	Make data and actions available to agents anywhere, anytime.	Make a live website ready for instant interaction with a browser agent.
Lifecycle	Persistent server or local process.	Ephemeral and bound to the open tab.
Connectivity	Desktop, mobile, cloud, or web.	Environment-specific browser agents.
UI awareness	Headless and external to the page.	DOM-aware and browser-integrated.
Discovery	Agent-specific registration flows.	Tools registered by the page during the user’s visit.
Best use	Background API actions and service logic.	Navigating and operating a live web interface.

The two layers in one workflow

Travel booking is a clean example. An MCP server can search inventory, check prices, read a loyalty account, and create the reservation. Those functions should work from a desktop agent, a chat client, or a scheduled task, with no browser tab involved.

WebMCP covers the part that only exists on the page. The agent can fill a multi-city itinerary, choose passenger counts, set dates in a custom picker, and pause for the user to confirm the purchase. The booking logic can sit behind the same API in both cases. MCP exposes it as a persistent service; WebMCP exposes the live form and its current state to the browser agent.

The user sees the form being filled and can stop the action. That visible, interruptible flow is the reason WebMCP exists. It is not a smaller MCP server hidden in a web page.

What WebMCP does not do

It does not replace an MCP server. A tab-bound tool cannot handle a background job after the user leaves.
It is an MCP-inspired browser API rather than a JavaScript implementation of MCP, and it omits server-side concepts such as resources.
It is not a persistence layer. Tool registration belongs to the page lifecycle, not to an account or a daemon.
It is not headless-first. The current design assumes a local browser workflow with a human available to confirm sensitive actions.
Browser support is still experimental. The specification is a draft, and implementations vary by browser.

A minimal tool

The imperative API is the direct option for dynamic interfaces. This tool sets two dates on a booking page and returns a short result to the agent.

await document.modelContext.registerTool({
  name: "set_travel_dates",
  description: "Set the departure and return dates on the current booking form.",
  inputSchema: {
    type: "object",
    properties: {
      departure: { type: "string", description: "ISO date, YYYY-MM-DD" },
      returnDate: { type: "string", description: "ISO date, YYYY-MM-DD" }
    },
    required: ["departure", "returnDate"]
  },
  annotations: {
    readOnlyHint: false,
    consequentialHint: false
  },
  execute: async ({ departure, returnDate }) => {
    setDates(departure, returnDate);
    return `Dates set: ${departure} to ${returnDate}`;
  }
});

The declarative API is the lighter option when a normal form already does the job. Adding toolname and tooldescription makes the form discoverable; the existing fields become the schema.

<form toolname="search_flights"
      tooldescription="Search flights for the current trip.">
  <input name="origin">
  <input name="destination">
  <button type="submit">Search</button>
</form>

Security and the user in the loop

WebMCP makes the user’s presence part of the interaction, but that does not make it safe by default. Tool descriptions and tool outputs are still text that an agent will interpret. A page that returns user-generated content or external data should mark the tool with untrustedContentHint. A tool that books, buys, deletes, or transfers should set consequentialHint so the browser or agent can require confirmation. A read-only lookup should set readOnlyHint.

Keep the exposure narrow. Tools are same-origin by default, cross-origin iframes need the tools permission, and exposedTo should list only origins you would trust with the same data. Do not expose a tool that reads private account data to every embedder. Do not assume the model will ignore an instruction embedded in a document the tool returns.

The human in the loop requires deliberate design; the protocol does not provide it automatically. Put the confirmation before the irreversible step, and make the result visible in the page.

Status and when to use it

WebMCP is a Draft Community Group Report and does not carry W3C Standard status. Chrome runs an origin trial from Chrome 149, and local testing uses the chrome://flags/#enable-webmcp-testing flag. Treat it as an experimental surface with a fallback while browser support remains experimental.

Use MCP when the agent needs a service from anywhere: a scheduled report, a background sync, a chat client that is not looking at your site, or a task that must survive a closed tab. Use WebMCP when the agent needs to operate the page the user is looking at: fill a form, use a custom picker, navigate a workflow, or pause for confirmation.

Use both when the product has a service layer and a live interface. Keep the core logic behind your API, expose a thin MCP server for persistent access, and register a thin WebMCP tool for the in-tab experience. They share a domain model, not a lifecycle.

WebMCP is a browser-side layer that makes an open website legible to an agent. MCP remains the service-side layer that makes the work available after the tab is gone.