What is WebMCP? A plain-English guide for website owners

TL;DR

• WebMCP is a proposed browser API that lets a web page publish "tools" — a name, a plain-language description, an input schema and a function — that an AI agent in the browser can call directly.
• As of October 2026 it is a draft, not a standard. Chrome (from 149) and Edge (from 150) run origin trials; Firefox and Safari have not implemented it.
• You can start with plain HTML: add toolname and tooldescription to one important form. The same clean labels that help agents also help screen-reader users.

What WebMCP is, in one paragraph

Today, when someone asks an AI assistant in their browser to "book a demo with this vendor" or "find the cheapest plan with SSO", the agent has to read your page like a stranger: take a screenshot or parse the HTML, guess which button does what, type into fields and hope nothing moved. WebMCP gives the page a way to say what it can do in a format agents understand. The draft specification puts it in one line: "The WebMCP API enables web applications to provide JavaScript-based tools to AI agents." Instead of clicking around, the agent calls request_demo or compare_plans with structured inputs, and your own code does the work.

The project's explainer describes pages that use WebMCP as "in-page Model Context Protocol (MCP) servers" that run client-side logic instead of server APIs (WebMCP explainer).

Why this matters: how agents use your site today

Without WebMCP, an agent has two options on a typical marketing site:

1. Read and actuate the user interface. It works out from pixels or the DOM what each element is for. A redesign, a cookie banner or a lazy-loaded component can break the flow.
2. Use a separate API. That works only if you have a public API, and it bypasses the page the user is looking at — including your session, your validation and your UI state.

The WebMCP explainer names both problems and positions WebMCP between them: tools reuse "much of the page's existing client-side code", and the user sees the result on the page they are already on. The explainer is just as clear about what WebMCP is not for: fully autonomous workflows with no browser UI, and replacing backend integrations or human interfaces. It is built for a person and an agent working in the same tab.

For a website owner the practical upside is control. You decide which actions agents get, how they are described, what inputs are valid and what the agent hears back — instead of leaving an agent to guess.

How WebMCP works

A tool has four parts

Every tool, whichever way you register it, comes down to the same pieces defined in the draft:

Tools can also carry annotations: readOnlyHint (the tool only reads data), consequentialHint (it has significant or irreversible effects), untrustedContentHint (its output contains content you do not vouch for, such as user reviews) and, from Chrome 156, debugging for developer-only tools (imperative API docs).

The declarative API: turn a form into a tool

The lowest-effort path is HTML. Chrome's declarative API docs describe two required attributes on the form element — toolname and tooldescription — plus an optional toolparamdescription on fields. Without that attribute, the browser uses the field's label text as the parameter description. Here is a demo-request form made agent-callable:

<form toolname="request_demo"
      tooldescription="Request a live product demo with a sales engineer. Use when the visitor wants to see the product or talk to sales."
      action="/demo" method="post">

  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>

  <label for="team-size">Team size</label>
  <select id="team-size" name="team_size" required
          toolparamdescription="How many people would use the product">
    <option value="1-10">1–10</option>
    <option value="11-50">11–50</option>
    <option value="51+">51 or more</option>
  </select>

  <button type="submit">Request a demo</button>
</form>

When an agent calls this tool, the browser focuses the form and fills it in, and the form stays visible. By default, the user still clicks Submit. If you add the toolautosubmit attribute, submission happens automatically. Your submit handler can tell agent submissions apart through SubmitEvent.agentInvoked and send a structured answer back to the model with respondWith(). Chrome also adds CSS pseudo-classes (:tool-form-active, :tool-submit-active) so you can show the user that an agent is working on the form.

The imperative API: register a tool from JavaScript

For anything a form cannot express — a pricing calculator, an order lookup, a filter on a product grid — you register tools in JavaScript. The current draft and Chrome's documentation put the API on document.modelContext. Some earlier write-ups and demos use navigator.modelContext instead, so older tutorials may not match what browsers expect now.

if ("modelContext" in document) {
  await document.modelContext.registerTool({
    name: "check_order_status",
    description: "Look up the shipping status of an order by its order number.",
    inputSchema: {
      type: "object",
      properties: {
        orderNumber: { type: "string", description: "Order number as printed on the receipt, for example A-10293" }
      },
      required: ["orderNumber"]
    },
    annotations: { readOnlyHint: true },
    async execute({ orderNumber }) {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}/status`);
      if (!res.ok) return "No order with that number. Ask the user to check the receipt.";
      const { status, eta } = await res.json();
      return `Order ${orderNumber}: ${status}. Estimated delivery: ${eta}.`;
    }
  });
}

The feature check matters: browsers without WebMCP simply skip the block. Per the draft, the API only exists in secure (HTTPS) contexts. It is also gated by a tools permissions policy that defaults to self, so a cross-origin iframe needs allow="tools" before it can register anything. To remove a tool later, pass an AbortSignal when you register it and abort the signal.

What a good tool looks like

Chrome's best-practices guide is short and worth reading in full. The points that matter most for a marketing or SaaS site:

• One job per tool, and no overlapping tools — overlap confuses the agent.
• Name the outcome precisely. Chrome's example: create-event should create the event; a tool that only opens the form should be called something like start-event-creation-process.
• Accept raw input. Take "11:00 to 15:00" as a string instead of asking the model to calculate minutes.
• Validate strictly in code, loosely in schema, and return descriptive errors so the model can correct itself and retry.
• Register tools when they are useful in the current page state, and unregister them when they stop being usable. Each tool takes up part of the model's context. Lighthouse warns when a page registers more than 40 (Lighthouse docs).

Where WebMCP stands as of October 2026

The draft is moving quickly, so check the date on anything you read — including this page.

The browser and agent rows come from the project's own implementation status page. Chrome's documentation still says "WebMCP is under active discussion and subject to change in the future." Some details have already changed. The Chrome declarative API page, for example, notes that window.ontoolactivated and window.ontoolcancel are not supported from Chrome 156.

What this means in practice: few of your visitors' agents call WebMCP tools yet. The work is cheap, though, and the declarative half mostly rewards things you should do anyway, such as labeled fields and clear form purposes. To see which agents already reach your pages today, and how they identify themselves, read how to tell when AI agents visit your website.

WebMCP, MCP, llms.txt and robots.txt: who does what

These names get mixed up. They solve different problems and work fine together.

The Model Context Protocol is "an open-source standard for connecting AI applications to external systems." The WebMCP explainer says the group considered adopting MCP directly and decided against it, because MCP lacks web concepts such as origins, browser permissions and tab lifecycle. WebMCP keeps MCP's vocabulary and is meant to complement a backend MCP server, not replace it. For the file-based side of this, see llms.txt explained.

What a website owner should do now

If you want a broader to-do list that covers crawlers, content and analytics as well as tools, use our agent-ready website checklist.

Safety: what to think about before you expose a tool

WebMCP runs your code with the user's session, at an agent's request. The draft's security section spends real space on this, and three points apply to any site:

• Agents can be manipulated. Prompt injection — instructions hidden in content the agent reads — is the first risk the draft discusses, including poisoned tool descriptions and tool outputs. If a tool returns user-generated text, such as reviews or forum posts, set untrustedContentHint.
• Mark anything consequential. Purchases, cancellations, deletions and messages sent on the user's behalf should carry consequentialHint, so agents and browsers can require explicit confirmation. Chrome's overview notes you can ask for user interaction through a confirmation dialog for sensitive actions.
• Your server is still the gatekeeper. A tool is a convenience layer, not a permission system. Keep authentication, rate limits and validation on the server exactly as you would for a human clicking the same button.

A rule of thumb: start with read-only tools (look up, compare, check availability) and forms the user submits themselves. Add actions that change state only when you have watched real agent traffic.

WebMCP will keep changing until browsers ship it by default, so treat today's work as preparation, not a finished integration. The forms you clean up and the tool descriptions you write will carry over as the draft evolves.