WebMCP: What It Is and How to Set It Up on Your Website

In our last post we plugged AI assistants into the ad stack: MCP servers that let Claude or ChatGPT query your platforms. WebMCP flips the whole arrangement around. Instead of your assistant reaching out to remote APIs, your website itself announces what an agent is allowed to do on it. The page becomes the server.

This one is a proper setup guide. We will cover what WebMCP is, where the spec actually stands as of August 2026, how to register your first tools with real code, how to test them, and the security and measurement questions nobody should skip. It is more technical than usual, but if you run a website that agents are already visiting (spoiler: they are), this is worth thirty minutes of your developer’s time.

The problem: agents browse like interns on their first day

Agentic browsers and assistant features are already operating websites on behalf of users: comparing your prices, filling your forms, trying to book your services. Today they do it the only way they can, by reading the rendered DOM and guessing. Which button submits? Is this field the work email or the personal one? Did the click even work?

Screen-scraping agents are brittle in exactly the way screen-scraping anything is brittle. A CSS refactor breaks them. An A/B test confuses them. A cookie banner (we have written about those) blocks them mid-task. And when an agent fails on your site, the user does not blame the agent. They just never arrive, and your analytics quietly records one less conversion. You cannot fix what you cannot see, and agent failures are invisible by design.

What WebMCP actually is

WebMCP (Web Model Context Protocol) is a proposed browser API that lets a web page register a set of typed, named tools that AI agents can call directly, instead of poking at your DOM. Conceptually it borrows the tool model from MCP: each tool has a name, a natural-language description, a JSON Schema for its inputs, and a function that executes it. The difference is where it lives. A classic MCP server runs as a separate process with its own credentials. A WebMCP tool is just JavaScript on your page, running in the user’s session, with exactly the access the logged-in user already has. No API keys, no backend integration project, no new infrastructure.

Status check, because this space moves fast: WebMCP is a Draft Community Group Report from the W3C Web Machine Learning Community Group, edited by engineers from Google and Microsoft, last updated 28 July 2026. Chrome is running a public origin trial from Chrome 149, and Microsoft has been shipping preview support in Edge. It is explicitly experimental: earlier drafts had a provideContext() method that was removed in March 2026, and the API is migrating from navigator.modelContext to document.modelContext. Translation: build behind a feature check, expect renames, do not bet the quarter on it. But do start.

Why this matters if you care about acquisition

Think of the web’s history as three layers of machine-readability. robots.txt told crawlers where they could go. Structured data and schema.org told search engines what your things are. WebMCP tells agents what they can do. It is the difference between being findable and being usable.

For marketers this is the early days of a new surface. When an assistant can reliably request a quote, check availability or complete a signup on your site, and fails to do so on your competitor’s, that reliability becomes a ranking factor in the only index that will matter to agents: what works. We already optimize for crawlers and for humans. A third audience just sat down at the table.

Setup, step 1: get into the origin trial

Since WebMCP is not yet a stable web platform feature, production use runs through Chrome’s origin trial program. Register your origin at the Chrome origin trials console (linked from the Chrome blog post above), grab your token, and serve it on every page that registers tools, either as a meta tag or an HTTP header:

<!-- in your <head> -->
<meta http-equiv="origin-trial" content="YOUR_TOKEN_HERE">

# or as a response header
Origin-Trial: YOUR_TOKEN_HERE

The trial currently runs from Chrome 149 through Chrome 156, which gives you a real window to experiment on production traffic before anything is set in stone.

Setup, step 2: register your first tool

Everything hangs off the model context object. Because the API is mid-migration between navigator and document, feature-detect both and write the rest of your code against whichever exists:

const mc = document.modelContext || navigator.modelContext;
if (!mc) {
  // No agent-capable browser: your site works exactly as before.
}

Here is a complete read-only tool. It exposes the services listed on a page as structured data, so an agent asked “what does this company actually do?” gets a clean answer instead of scraping your hero copy:

await mc.registerTool({
  name: "list_services",
  title: "List services",
  description: "Returns the services this consultancy offers, with a one-line
    summary of each. Use when the user asks what the company does or whether
    it covers a specific capability.",
  inputSchema: { type: "object", properties: {} },
  annotations: { readOnlyHint: true },
  async execute() {
    const cards = [...document.querySelectorAll(".service-card")];
    const services = cards.map((card) => ({
      name: card.querySelector("h3")?.textContent.trim(),
      summary: card.querySelector("p")?.textContent.trim(),
    }));
    return JSON.stringify(services);
  },
});

Three details worth internalizing. The description is not documentation, it is targeting: the agent chooses tools by reading it, so write it the way you would brief a junior colleague, including when to use it. The inputSchema is a contract: the browser validates agent-supplied arguments against it before your code runs. And readOnlyHint tells the agent (and the browser UI) that calling this is safe to do without ceremony.

Now the interesting one, a write tool. This wires the lead form itself, the thing agents most often fumble:

await mc.registerTool({
  name: "request_contact",
  title: "Send a contact request",
  description: "Submits a contact request to the team. Requires the user's
    name, work email and a short message describing what they need. Always
    confirm the message text with the user before calling this.",
  inputSchema: {
    type: "object",
    required: ["name", "email", "message"],
    properties: {
      name:    { type: "string", maxLength: 120 },
      email:   { type: "string", format: "email" },
      message: { type: "string", maxLength: 2000 },
    },
  },
  async execute({ name, email, message }) {
    const form = document.querySelector("#leadForm");
    form.elements.name.value = name;
    form.elements.email.value = email;
    form.elements.message.value = message;
    form.requestSubmit();
    return "Contact request submitted. The team replies within one business day.";
  },
});

Notice what the tool does not do: it does not bypass the form. It fills and submits the same form a human would use, which means your validation, your spam honeypot, your consent checkbox logic and your server-side handling all still apply. That is the pattern to copy. Tools should be a second interface to the exact behavior your UI already has, never a side door.

Setup, step 3: single-page apps and cleanup

Tools are page-scoped. On a classic multi-page site, register them on load and forget about it. In a SPA, the page persists while the meaning changes, so register tools when a view mounts and remove them when it unmounts, the same way you treat event listeners. Wrap registration in one small adapter module rather than calling the API from twenty components; when the spec renames something (it will), you change one file.

Testing: how to actually see it work

First sanity check: registration. In DevTools on your page, the model context exposes what is currently registered, so confirm your tools are there and their schemas parse. If registerTool throws, it is almost always a malformed inputSchema or an invalid tool name (keep names to letters, numbers, underscores, hyphens and dots).

Second: the agent side. Inside the origin trial, Chrome’s agentic surfaces can discover and call page tools directly. Cross-browser, the community WebMCP polyfill ecosystem (browser extension plus npm transports) bridges your page tools to any MCP-capable client, which also happens to be an excellent local development loop: register a tool, open your assistant, watch it call the page. Keep a human in that loop while you test write tools; you want to see every call while you tune descriptions.

Expect to iterate on descriptions more than code. In our experience the failure mode is rarely “the tool errored”, it is “the agent picked the wrong tool” or “the agent never realized the tool applied”. Both are fixed with sharper descriptions, not more engineering.

Security: the section you should not skip

WebMCP inherits the classic risks of letting software act on behalf of humans, and the spec’s own security considerations are refreshingly blunt about them. The ones we would flag for any client:

• Never trust the client, still. Tool calls execute in the browser, so an agent-submitted form is exactly as untrusted as a human-submitted one. All real validation stays server-side, same as it ever was.
• Prompt injection cuts both ways. Whatever your tool returns flows into the agent’s context. If your tool echoes user-generated content (reviews, comments, search results), a malicious string in that content becomes instructions to the agent. The spec provides an untrustedContentHint annotation for exactly this; use it whenever a tool’s output contains text you did not write.
• Read-only by default, honest hints always. Marking a destructive tool readOnlyHint is not an optimization, it is a lie that the browser will act on. Start with read tools, add write tools only where the UI equivalent is already safe and reversible, and never expose deletes.
• Do not over-collect. A tool’s parameters are a data request to the user’s agent. If list_services asked for an email address “for personalization”, that is a privacy leak with a schema. Ask for the minimum.
• Scope stays same-origin unless you explicitly opt a tool into wider exposure. Leave the default alone unless you have a very good reason.

Measure it or it did not happen

Here is the part most WebMCP write-ups skip and the part we care about most: agent interactions are traffic, and untracked traffic is a strategy blind spot. Today, agent activity mostly hides inside Direct in your GA4 reports. Once you expose tools, you can finally see it, by instrumenting the tools themselves:

function tracked(tool) {
  return {
    ...tool,
    async execute(input) {
      window.dataLayer = window.dataLayer || [];
      window.dataLayer.push({
        event: "webmcp_tool_call",
        tool_name: tool.name,
      });
      return tool.execute(input);
    },
  };
}

await mc.registerTool(tracked({ name: "list_services", /* ... */ }));

Route that event through your tag manager into GA4 and you have an agent-interaction report on day one: which tools get called, on which pages, preceding which conversions. Two house rules. Keep it consent-gated like every other event you send (agents act for a human whose consent state applies), and do not push tool arguments into the dataLayer, because they can contain personal data. Names and counts, not payloads.

Should you implement it this quarter?

Honest answer by site type. If you run high-intent flows that agents will be asked to complete (booking, quoting, B2B lead-gen, commerce), yes: ship two or three read tools plus your primary conversion action behind the origin trial, instrument them, and learn while the spec is still soft. If your site is pure content, the payoff is thinner for now; structured data keeps doing the heavy lifting and you can revisit when the API stabilizes. Either way the skill you are really building is the same one this blog keeps coming back to: treating machines as an audience with its own UX.

The web spent thirty years optimizing for human attention and fifteen for search ranking. The next optimization target is agent success rate, and for once you can get there early. If you want help deciding what to expose, wiring the measurement, or making your stack agent-ready end to end, that is now a service line of its own. This is exactly the kind of thing we enjoy.