What is WebMCP, and should your site use it yet?

WebMCP is a browser API that lets a web page hand an AI agent a set of named tools, such as "request a studio visit" or "search the catalog", each with a description and typed inputs. The agent calls the tool instead of guessing which button does what. You can add it to an existing HTML form with a few attributes, or register tools in JavaScript. As of 6 October 2026 it is a draft from a W3C Community Group, not a W3C standard, and Chrome runs it as an origin trial. It is the "act" part of an AI-ready website, next to the parts agents read.

What it is, and what it isn't

A browsing agent that is asked to book something today reads the page, often through its accessibility tree or screenshots, and then clicks and types like a person would (how AI agents read websites covers that). WebMCP gives it a shorter path. The page declares its actions as tools on document.modelContext, and the agent calls them with structured input.

Three things it is not:

• Not a W3C standard. The specification is a Draft Community Group Report from the Web Machine Learning Community Group, dated 2 October 2026, edited by Brandon Walderman (Microsoft), Khushal Sagar and Dominic Farolino (Google). Some older articles call it a standard, and some use navigator.modelContext. The current draft uses document.modelContext.
• Not an MCP server. The tools run in the visitor's tab, with the visitor's session and cookies. Chrome's documentation says the API "is primarily designed for local browser workflows with a human in the loop".
• Not something that changes your page for people. Browsers without WebMCP ignore the attributes, and the form works exactly as before.

Where it works, as of October 2026

Chrome's documentation doesn't list which agents call these tools today. Its stated aim is an API that "any browser with agentic capabilities can implement".

The smallest correct start: a form

If your site has a booking, quote or contact form, this is the whole change. We ran this exact form in Chrome 154 on 6 October 2026, with WebMCP turned on, and checked what the browser registered:

<form action="/visit" method="post"
      toolname="request_studio_visit"
      tooldescription="Ask the studio for a visit on a given date. The studio replies by email to confirm.">
  <label for="name">Your name</label>
  <input id="name" name="name" required>

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

  <label for="date">Preferred date</label>
  <input id="date" name="date" type="date" required
         toolparamdescription="The day you would like to visit, in YYYY-MM-DD.">

  <label for="size">Group size</label>
  <select id="size" name="size">
    <option value="1">Just me</option>
    <option value="2-4">2 to 4 people</option>
  </select>

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

document.modelContext.getTools() returned a tool named request_studio_visit with this input schema, built by the browser:

{
  "type": "object",
  "properties": {
    "name": { "type": "string", "description": "Your name" },
    "email": { "type": "string", "description": "Email" },
    "date": {
      "type": "string",
      "format": "date",
      "description": "The day you would like to visit, in YYYY-MM-DD. (Dates MUST be provided in 'YYYY-MM-DD' format.)"
    },
    "size": {
      "type": "string",
      "anyOf": [
        { "type": "string", "const": "1", "title": "Just me" },
        { "type": "string", "const": "2-4", "title": "2 to 4 people" }
      ],
      "enum": ["1", "2-4"],
      "description": "Group size"
    }
  },
  "required": ["name", "email", "date"]
}

What that output teaches:

• Your labels become the agent's instructions. "Email" is all the agent learned about that field. A label like "Email we reply to" serves people and agents better. toolparamdescription replaces the label text when the label isn't enough.
• required carries over, and each <option> becomes an allowed value with its visible text as a title.
• Field types are only partly carried. The date field gained "format": "date", but the email field arrived as a plain string. Your server still has to check it.

What happens when an agent calls it

We called the tool from the page with executeTool and watched the form.

Without toolautosubmit, Chrome filled every field, moved focus to the submit button and matched the form with the :tool-form-active pseudo-class. The tool call then waited. The declarative explainer describes the intent: the agent "should then tell the user to check the form contents, and submit it manually". This is the right default for anything that books time or spends money.

With toolautosubmit, the form submits on its own, and the submit event has agentInvoked set to true. You can answer the agent directly with respondWith, and the value you pass becomes the tool's result:

document.querySelector("form[toolname]").addEventListener("submit", (event) => {
  if (!event.agentInvoked) return; // people get the normal submit
  event.preventDefault();
  event.respondWith(
    fetch(event.target.action, { method: "POST", body: new FormData(event.target) })
      .then((res) => (res.ok
        ? { ok: true, message: "Request received. The studio replies by email." }
        : { ok: false, message: "The request did not go through. Please try again." }))
  );
});

The browser's own validation still runs. When we passed not-an-email with autosubmit on, the call was rejected with "Form validation failed: email: Please include an '@' in the email address." That protects against typos, not against misuse, so the server check stays.

When to reach for registerTool

Use the imperative API for actions that aren't a form: a read-only lookup, a filter on a product list, or a step inside a single-page app.

if ("modelContext" in document) {
  const registration = new AbortController();
  document.modelContext.registerTool(
    {
      name: "get_opening_hours",
      description: "Return the studio's opening hours for the next seven days.",
      inputSchema: { type: "object", properties: {} },
      annotations: { readOnlyHint: true },
      async execute() {
        const res = await fetch("/api/hours");
        return await res.json();
      },
    },
    { signal: registration.signal }
  );
  // Later, when the tool no longer applies: registration.abort();
}

The if keeps every other browser on the plain page. Aborting the signal unregisters the tool. The specification limits names to 128 characters of letters, digits, underscores, hyphens and periods. Chrome's guidance is stricter: 30 characters for names, 500 for tool descriptions, 150 for parameter descriptions and about 1,500 characters per tool result.

The safety rules

Chrome's security guidance is blunt: "it's impossible to guarantee safety inside of a large language model." Plan for an agent that has been misled by something it read elsewhere.

1. Mark what each tool does. readOnlyHint for tools that only read. consequentialHint for "high-stakes or non-reversible actions". untrustedContentHint when the tool returns reviews, comments or other content you didn't write.
2. Keep toolautosubmit off for anything that spends money or books time. Shopify's checkout tools follow the same idea. Its documentation tells agents: "Before you call complete_checkout, show the buyer the current order and total, and get their permission to place it." The tools also hand control back to the buyer when a step needs them, such as a 3D Secure check.
3. Validate on the server, exactly as for a person. An agent's submission arrives as an ordinary form post. Rate limits, spam checks and stock checks still apply.
4. Mind iframes. WebMCP sits behind a Permissions Policy named tools, allowed for the page's own origin by default. A cross-origin iframe gets it only if you delegate it.
5. Name tools for what they really do. Chrome's best practices separate doing from starting: create-event creates the event, while start-event-creation-process only opens the flow.

How to test it

• Turn on chrome://flags/#enable-webmcp-testing and open your page. Chrome's Model Context Tool Inspector extension lists the registered tools and lets you call them by hand.
• For a live site, register for the origin trial on Chrome's origin trials page and add the token to your pages.
• Run Lighthouse's experimental Agentic Browsing category. It needs Chrome 150 or later, and its WebMCP audits need origin trial registration. It also checks names and roles in the accessibility tree, layout shifts and whether an llms.txt exists (what is llms.txt).
• In an automated test, launch Chrome with the WebMCP feature enabled and read await document.modelContext.getTools(). Our run used --enable-features=WebMCPTesting in Chrome 154.

Should you add it yet?

Add the declarative attributes now if your site has a few forms that matter, such as booking, quotes, contact or sign-up. The change is small, browsers without support ignore it, and good labels help screen reader users too. Wait on anything elaborate. The draft still marks the algorithm that turns a form into a schema as "TODO", and Chrome revised its WebMCP security, imperative and declarative pages in September 2026 alone. Check the status again before you build on it.

Agents decide what a site can do before they visit any one page. The A2A protocol's Agent Card, published at /.well-known/agent-card.json, is one way to list a site's skills. If you publish one, give its skills the same names as your tools. The free AI-ready check looks for that file, along with robots.txt, llms.txt and structured data. A tool is only as good as what happens after the submission, so connect the form to a real backend where every request, from a person or an agent, lands in the same place.