Most of what you’ll read about WebMCP frames it as “MCP for websites” and implies that adding it gets you picked up by ChatGPT or Gemini. That’s the wrong mental model, and it leads site owners to spend effort in the wrong place. It doesn’t help an agent find you. It helps an agent that is already on your page, inside a user’s browser, finish a task without guessing which button to click. It is a conversion layer for the agentic web, not a discovery layer, and once you see it that way the decision about when to invest becomes much simpler.
What Is WebMCP, in Plain Terms
WebMCP (Web Model Context Protocol) is a proposed web platform API that lets a web page publish its own functions as “tools” that an AI agent running in the browser can call. Each tool has a name, a natural-language description, and a JSON Schema describing its inputs. Instead of an agent screenshotting your page, reading the DOM and simulating clicks, it calls something like search_flights with structured arguments, and your own JavaScript does the work.
Per the official explainer in the webmachinelearning/webmcp repository, the proposal was first published in August 2025 by engineers from Microsoft and Google. The spec is published by the W3C Web Machine Learning Community Group as a Draft Community Group Report, and the document itself states it “is not a W3C Standard nor is it on the W3C Standards Track.” So: real, multi-vendor and moving fast, but still a draft.
How WebMCP Works: Tools, Schemas and the Browser in the Middle
The mechanism has three parties: your page, the browser, and the agent (a browser’s built-in assistant or an extension). Your page registers tools. The browser collects them from the page the user is looking at and hands that list to the agent. When the agent decides a tool fits the user’s request, the browser runs your tool’s execute function in the page and returns the result to the agent.
Three details matter more than the rest:
- It runs in the user’s session. The tool executes as your front-end code, with the user’s cookies, login and cart. No separate API, no OAuth dance.
- It is gated by a Permissions Policy. The spec ties access to a policy-controlled feature named
tools, allowed for the page’s own origin by default. Cross-origin iframes needallow="tools". - Discovery happens on the page. Chrome’s documentation is explicit that agents must visit a site to learn whether it has callable tools, and describes the imperative API as “primarily designed for local browser workflows with a human in the loop.”
Here is the shape of an imperative tool, following the current draft’s ModelContextTool dictionary:
const controller = new AbortController();
document.modelContext.registerTool({
name: "check_delivery_date",
description: "Returns the estimated delivery date for a postcode and product.",
inputSchema: {
type: "object",
properties: {
postcode: { type: "string" },
sku: { type: "string" }
},
required: ["postcode", "sku"]
},
annotations: { readOnlyHint: true },
execute: async ({ postcode, sku }) => {
const eta = await getDeliveryEstimate(postcode, sku); // your existing app code
return { eta };
}
}, { signal: controller.signal });
// Later, when the tool no longer applies to this page state:
controller.abort();navigator.modelContext vs document.modelContext: The API Already Moved
If you search for code samples, most of them use navigator.modelContext, often with a provideContext() method. That was the original entry point. The current draft moved the API to document.modelContext, because tools belong to a specific page (Document), not to the whole browser tab. A Chromium change titled “WebMCP: Remove navigator.modelContext”, synced to the Web Platform Tests and tracked in Mozilla’s Bugzilla, removes the old property “in favor of document.modelContext.” The current spec defines registerTool(), getTools() and executeTool(), with unregistering handled by an AbortSignal; provideContext() is not in it.
The practical takeaway: any tutorial built on navigator.modelContext is describing an earlier draft. Feature-detect document.modelContext before calling it, and treat any API detail you copy from a blog (including this one) as something to re-check against the spec before you ship.
Declarative vs Imperative WebMCP
Chrome’s announcement of the early preview (February 10, 2026) describes two flavours. The imperative API is the JavaScript registration shown above, for dynamic tasks. The declarative API turns a normal HTML form into a tool by annotating it, which is the version most marketing sites will care about because it needs almost no engineering. The declarative explainer proposes attributes like these:
<form action="/quote" toolname="request_quote"
tooldescription="Requests a renovation quote for a property in Singapore.">
<input name="floor_area" toolparamdescription="Floor area in square feet">
<input name="email" type="email">
<button>Get quote</button>
</form>Be clear about maturity here. The repository says the declarative form “is not part of the specification at this time,” and the explainer says Chromium is implementing “a loose version” of it. An optional toolautosubmit attribute would let the agent submit without the user reviewing the form first, which you should leave off for anything involving money or personal data.
Who Supports WebMCP Today
Based on the project’s own implementation-status page and Chrome’s documentation, as of November 2026:
- Chrome: early preview program from February 2026; an origin trial from Chrome 149, announced on the Chrome for Developers blog on June 9, 2026. For local testing, Chrome’s docs point to the
chrome://flags/#enable-webmcp-testingflag. - Edge: an origin trial is listed as live in Edge 150.
- Brave: experimental support in its Leo assistant.
- ChatGPT Desktop: listed as supported.
- Firefox and Safari: no implementation listed; both have open standards-position requests.
An origin trial means a time-limited experiment on real traffic, not a shipped feature. Nothing here guarantees the API survives in its current form.
WebMCP Is Not MCP (and Doesn’t Replace It)
The name invites confusion. MCP, the Model Context Protocol, is the open protocol Anthropic introduced in November 2024 and donated to the Linux Foundation’s Agentic AI Foundation in December 2025. An MCP server runs on a server, is reachable without anyone opening your website, and is configured into an AI client like Claude. WebMCP tools live inside a page and only exist while that page is open in a browser with an agent.
They borrow the same idea (named tools with schemas) and they complement each other: an MCP server for headless, account-level access; in-page tools for in-session tasks on your actual UI. We go deeper on the trade-offs in WebMCP vs MCP, and on the build steps in WebMCP in Chrome.
WebMCP and SEO: What Actually Changes
Here is the part most explainers skip. WebMCP tools are not a crawlable asset. No search engine has said it reads them or uses them as a ranking signal, and the spec’s own model is that the browser gathers tools from the page a user is actively viewing. So WebMCP SEO is not about rankings. It reshapes the funnel in two places:
- Getting the agent to your page is still search, AI answers and agentic search. Page tools do nothing here. Your existing SEO, structured data and llms.txt work still decides whether an agent lands on you or a competitor.
- Completing the task once it arrives is where the standard lives. If your booking flow is a tool and your competitor’s is a maze of modals, an agent on your site finishes the job and an agent on theirs may give up and try the next result.
That makes tool descriptions a new copywriting surface, closer to a meta description than to code: a short, literal sentence a model reads to decide whether your tool matches what the user asked for. It also creates a measurement opportunity. The spec fires toolactivated events when a tool runs, and the declarative explainer proposes a SubmitEvent.agentInvoked flag so a submit handler can tell an agent-driven submission from a human one. Push either into your analytics as a custom event and you’ll have one of the few clean signals of agent-completed conversions, something referrer data mostly can’t give you today.
Writing Tools Agents Will Actually Use
Chrome’s WebMCP best practices read like a good content brief, which is why SEOs should be in the room when tools are designed:
- One job per tool, with no overlapping tools that make the agent’s choice ambiguous.
- Verb-first names that say exactly what happens. Chrome contrasts
create-event(does it now) withstart-event-creation-process(sends the user to a form). - Descriptions that say what the tool does and when to use it, phrased positively rather than as a list of prohibitions.
- Raw, natural inputs. Accept the date the user typed, and use values like “Express” instead of
shipping_id=1. - Strict validation in code with descriptive errors, so the model can correct itself and retry.
Start with the three to five tasks that already drive revenue or leads. To pick them, you need an honest map of your templates. SEO Rocket builds your site structure from your XML sitemaps and runs a real-crawler technical audit with JavaScript rendering, which is a fast way to see which search, booking and quote pages actually exist before anyone writes a line of tool code.
The Risks the Spec Admits To
The draft is unusually candid about what it can’t solve. It states that agents “cannot verify that tool implementations match their descriptions,” and that there is “no guarantee that a WebMCP tool’s declared intent matches its actual behavior.” It lists tool poisoning (instructions hidden in names or descriptions), injection through tool output, and sites over-collecting personal data through tool parameters. Annotations like readOnlyHint, untrustedContentHint and consequentialHint help agents decide when to ask the user for confirmation, but a malicious site can simply misstate them.
For a legitimate site owner, the lesson is to keep tools honest and narrow. Mark anything that spends money or changes an account as consequential, never auto-submit those, and keep user-generated text out of descriptions. Expect agents to get more cautious, not less, as abuse appears.
Do Now, Watch, Ignore
A playbook proven across 1,000,000+ ranking pages has taught us to separate shipped features from announcements. Here, that looks like this:
- Do now: clean up your key forms (clear labels, sensible
nameattributes, server-side validation). That helps humans, assistive tech and today’s screen-reading agents, and it makes the declarative version close to free later. - Do now if you have engineering time: join the Chrome origin trial on one high-value flow and log agent invocations separately.
- Watch: the spec’s declarative section, Firefox and Safari positions, and which assistants actually call tools in production.
- Ignore: anyone selling it as a ranking factor or an AI-citation shortcut.
Discovery is still where most of the traffic is decided. SEO Rocket’s AI-visibility tracking and keyword research on live Ahrefs data show whether AI answers and searchers reach your pages at all, which is the precondition for any of this mattering.
WebMCP FAQ
Is WebMCP a W3C standard?
No. It is a Draft Community Group Report from the W3C Web Machine Learning Community Group and states that it is not on the W3C Standards Track.
Is navigator.modelContext still valid?
It was the original entry point. The current draft uses document.modelContext, and a Chromium change removes the navigator version, so feature-detect and follow the spec.
Does WebMCP help my site rank in Google or ChatGPT?
No search engine or AI assistant has said so. It helps agents complete tasks on a page they already reached; ranking and citation still come from normal SEO.
Do I need an MCP server to use WebMCP?
No. These tools are plain JavaScript or annotated forms in your page. An MCP server is a separate, server-side integration you can add alongside it.
