WebMCP

Definition

WebMCP is a proposed browser API that lets a website hand AI agents a list of things it can do. Instead of an agent looking at a page, guessing which button submits the form, and clicking it, the page declares: here is a tool called search_catalog, here’s what it does, here are the parameters it takes. The agent calls the function. The site’s own JavaScript runs.

The specification is a Draft Community Group Report from the W3C Web Machine Learning Community Group, co-edited by engineers at Google and Microsoft. It is not a W3C Standard and isn’t yet on the standards track. The current draft dates to August 26, 2026.

The API works two ways. The imperative version registers tools in JavaScript through document.modelContext.registerTool(). The declarative version uses HTML attributes on existing forms — toolname, tooldescription, toolparamdescription — and the browser generates the JSON Schema from the form’s own structure.

A minimal imperative registration:

javascript

document.modelContext.registerTool({
  name: "addTodo",
  description: "Add a new item to the to-do list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string", description: "Task description" },
      priority: { type: "string", enum: ["low", "medium", "high"] }
    },
    required: ["text"]
  },
  execute: async ({ text, priority = "medium" }, { signal }) => {
    todoApp.addItem({ text, priority });
    todoApp.renderList();
    return { content: [{ type: "text", text: `Added: "${text}"` }] };
  }
});

And the declarative equivalent for a form:

html

<form toolname="supportRequestTool"
      tooldescription="Submit a request for support."
      action="/submit">
  <label for="firstName">First Name</label>
  <input type="text" name="firstName">
  <select name="team" required
          toolparamdescription="Determines what team this request is routed to.">
    <option value="support">Customer Support</option>
    <option value="returns">Returns Team</option>
  </select>
  <button type="submit">Submit</button>
</form>

Two properties of the design matter more than the syntax. Tools are tab-bound — they exist only while a user has the page open, and they run inside that user’s already-authenticated session. And they’re gated by a tools Permissions Policy that defaults to self, so a third-party iframe can’t register tools on your behalf unless you explicitly allow it.

The name confuses people, so worth saying plainly: WebMCP isn’t a version of MCP, and it isn’t built on MCP. Google’s own documentation states that “WebMCP is not an extension or a replacement of MCP.” They share a conceptual model — describe capabilities to an agent as callable tools — and almost nothing else architecturally.

How WebMCP relates to marketing

For most of the web’s history the site’s job was to be legible to two audiences: people and crawlers. Agents are a third, and they’ve been reading sites the hard way — screenshots, DOM parsing, simulated clicks. That approach is slow, brittle, and breaks every time a marketing team ships a redesign.

WebMCP changes what a brand’s website is to an agent. It stops being a surface to be interpreted and becomes an interface to be called. A few consequences follow.

Conversion, not just citation. Generative engine optimization and answer engine optimization work on the discovery half of the funnel — getting a brand mentioned, cited, and summarized accurately by an AI assistant. WebMCP is aimed at the other half. A brand that gets recommended by an assistant but can’t be transacted with by that assistant has bought attention and lost the sale.

Redesigns stop breaking agent journeys. Because tools bind to application logic rather than to selectors and layout, the agent path survives a visual refresh. Anyone who has watched an automation suite collapse after a template change will recognize why that’s the actual selling point.

A new analytics problem. Agent-initiated tool calls aren’t page views and they aren’t clicks. They don’t fire the same events, they don’t carry the same referrers, and existing attribution models have nowhere to put them. Measurement teams will need a category for this before the traffic arrives, not after.

An unresolved ad question. If an agent completes a purchase by calling update_cart and proceed_to_checkout, it never renders the sponsored placement, the recommendation carousel, or the retargeting pixel. The specification says nothing about advertising, which is not the same as being neutral about it. Publishers whose economics depend on impressions have a real problem here and no obvious answer yet.

Shopify is the clearest example of what adoption looks like in practice. Every Liquid storefront now ships WebMCP tools with no merchant configuration: search_catalog, browse_store, get_product, show_variant, get_cart, update_cart, cancel_cart, proceed_to_checkout, manage_orders, and search_shop_policies_and_faqs. Millions of stores became agent-callable without their owners doing anything, or in most cases knowing about it.

How to measure WebMCP

WebMCP isn’t a metric, so there’s no formula. But it introduces a set of things worth instrumenting, and the useful ones look like this:

MeasureWhat it tells youHow to capture it
Tool invocation countWhich declared tools agents actually useLog inside each execute callback
Tool success rateInvocations that complete without error or abort, divided by total invocationsTrack resolutions vs. rejections and AbortSignal firings
Agent-assisted conversion rateSessions containing at least one tool call that end in a conversionSession-level flag written when a tool fires
Tool coverageShare of your revenue-critical interactions exposed as toolsManual audit against a task inventory
Parameter rejection rateHow often agents send inputs your validation refusesCount validation failures inside execute
Time to task completionWhether the tool path is actually faster than the UI pathTimestamp first tool call to conversion event

A high invocation count with a low success rate usually means the tool description is misleading rather than that the agent is bad. Descriptions are the interface. Treat them like copy.

How to utilize WebMCP

Common use cases, roughly in order of how ready they are:

Form completion. Google leads with this one. Multi-step forms with conditional logic — insurance quotes, B2B lead qualification, appointment booking — are exactly where autofill and DOM-scraping agents fail. A declared tool maps each field explicitly.

Product search and configuration. Faceted search, variant pickers, and pricing configurators involve state an agent can’t see from the outside. get_product returning which option combinations are actually in stock is information no screenshot conveys.

Cart and checkout. The Shopify tool list is a template. Add to cart, adjust quantity, review totals, move to checkout — with checkout itself typically kept behind a human confirmation.

Support and self-service. Policy lookups, order status, returns initiation. These are high-volume, low-margin interactions that benefit from being handled without a human on either end.

Internal tooling and diagnostics. Google specifically calls out debugging tools exposed to agents through developer settings. Less glamorous than commerce, probably where a lot of early real usage lands.

Interactive marketing assets. ROI calculators, assessment quizzes, comparison tools. If you built it to generate leads, an agent calling it directly is a lead you’d otherwise have missed.

Getting started, practically: enable chrome://flags/#enable-webmcp-testing for local development, or register for the origin trial to test with real users. Start by exposing three to five tools covering your highest-value tasks rather than trying to mirror the entire site. Angular ships experimental WebMCP support, and Progress Software added it to Telerik and Kendo UI, so component-library users may get some of this without writing it themselves.

WebMCPMCP serverDOM/computer-use agentsStructured data (Schema.org, llms.txt)
What it exposesCallable tools on a live pageCallable tools on a persistent serviceNothing — the agent infersDescriptive facts
Can it take action?YesYesYes, unreliablyNo
LifecycleEphemeral, tab-boundPersistent daemon or serverPer-sessionStatic
Where it runsUser’s browser tabYour backend or a hosted endpointAgent’s environmentN/A
AuthenticationInherits the user’s sessionNeeds its own auth flowNeeds credentials or a logged-in browserN/A
Infrastructure neededNone beyond your frontendA server to build and operateNone on your sideNone
DiscoveryOnly when the agent visits the pageRegistered with the agent in advanceCrawl or navigateCrawlers and indexes
Breaks on redesign?NoNoConstantlyNo
MaturityCommunity draft, origin trialWidely deployedIn production across major agentsMature

The honest framing is that these stack rather than compete. Chrome’s documentation recommends MCP for core business logic and background work, WebMCP for in-browser interaction during an active session. Structured data still handles discovery. WebMCP handles what happens after the agent arrives.

Best practices

Write descriptions for a reader who can’t see the page. “Search products” is a weak description. “Search the store’s product catalog by keyword; returns matching products with current price and stock status” tells an agent when to pick this tool over another one. Specificity in the description is what drives correct tool selection.

Update the UI before the tool returns. Agents often re-check the page after a call to confirm it worked. If the DOM hasn’t changed yet, the agent may conclude the call failed and retry — sometimes creating a duplicate order in the process.

Validate inside execute. Schema constraints aren’t enforced consistently across agents. Assume anything can arrive and check it in your own code.

Keep destructive actions behind a human. Use toolautosubmit only on read-only operations. Anything that spends money, sends a message, or deletes something should require a person to confirm.

Use the annotations. readOnlyHint tells an agent a tool is safe to call speculatively. untrustedContentHint flags returns containing user-generated content, which matters because that content is a prompt injection vector.

Expose tasks, not endpoints. A tool should map to something a user wants to accomplish. Wrapping every internal API method one-to-one produces a menu no agent can navigate.

Set the Permissions Policy deliberately. The tools feature defaults to self. Cross-origin iframes need an explicit allow="tools". Note also that WebMCP requires origin isolation and gets disabled if you send Origin-Agent-Cluster: ?0.

Don’t over-parameterize. The spec flags this as a privacy risk: an input schema detailed enough to be maximally useful can also coax an agent into passing along user information it had no reason to send.

Log everything from day one. You’ll want the baseline when agent traffic becomes material, and reconstructing it later isn’t possible.

The gap between infrastructure and usage is the whole story right now. Chrome’s origin trial runs from version 149 through 156, Edge has experimental support behind a flag, and Firefox and Safari are still in discussion with no commitment either way. Named brands including Expedia, Booking.com, Shopify, and Target have joined the trial. Actual production deployment is another matter, and one analysis in July 2026 put real adoption outside demo sites and validators at approximately zero. There are, at the moment, more WebMCP checker tools than WebMCP implementations, which is a fairly precise description of where a standard sits.

The bottleneck isn’t publisher supply. It’s that no mainstream agent calls WebMCP tools yet. Claude, ChatGPT’s agent mode, Perplexity, and Gemini all still work through DOM parsing and screenshots. Google has said Gemini in Chrome will be the first mainstream consumer, and that ship date is the one that matters — everything else in the ecosystem is waiting on it.

A few things worth watching after that:

The declarative API is the piece most likely to change. It’s described in the specification as largely unfinished, and it’s also the version most marketing teams would actually be able to deploy, since it’s HTML attributes rather than a JavaScript refactor.

Discovery is unsolved. An agent has to already be on your page to learn what tools you offer, which is fine for a user-driven session and useless for anything proactive. Expect proposals for out-of-band tool manifests.

Prompt injection is the security story that will define adoption. Tool descriptions and tool return values both flow into an agent’s reasoning, and a malicious site — or a legitimate site displaying user reviews — can put instructions in either. The specification names the problem. It doesn’t solve it.

And the protocol landscape is crowded. Agentic commerce has UCP, ACP, and MCP already circulating with different backers, and how WebMCP fits alongside them is being worked out in public, at speed, by parties with competing interests.

FAQs

Is WebMCP the same as MCP? No. They share a name and a concept but not an architecture. MCP connects agents to persistent external systems through a server you build and run. WebMCP exposes tools from a live web page inside the user’s browser tab, using your existing frontend code. Google’s documentation is explicit that one isn’t a version of the other.

Do I need a server to implement WebMCP? No. That’s the main practical difference from MCP. Tools are registered in the page’s JavaScript or through HTML form attributes, and they execute in the browser using whatever code already powers your UI.

Which browsers support it? Chrome runs an origin trial from version 149 through 156. Edge has experimental support behind a flag. Firefox and Safari haven’t committed. For local development, enable chrome://flags/#enable-webmcp-testing.

Is it navigator.modelContext or document.modelContext? document.modelContext. The API moved from navigator in July 2026, so older tutorials and blog posts still show the outdated form. Early adopters had to migrate.

Will WebMCP help my SEO? Not directly. Search rankings aren’t affected by tool registration. The value is downstream of discovery — an agent that has already found you can complete a task more reliably. Treat it as a companion to GEO and AEO work rather than a substitute.

Can an agent use my tools without a user present? Not currently. Tools are bound to an open tab and the specification is designed around local browser workflows with a human in the loop. Headless invocation isn’t supported.

What stops a malicious site from abusing this? Several things partly, and nothing completely. Same-origin enforcement, the tools Permissions Policy defaulting to self, and required origin isolation constrain who can register tools. But the spec is candid that there’s no guarantee a tool’s declared intent matches its actual behavior, and prompt injection through descriptions or return values remains an open risk.

Does Shopify already do this? Yes. Shopify ships a set of WebMCP tools on every Liquid storefront and on Hydrogen developer preview storefronts, live now, with no merchant setup required.

How much work is implementation? It depends entirely on your architecture. A form-based lead capture tool using declarative attributes is a small change to existing markup. Exposing a stateful configurator through the imperative API means writing and maintaining real code, and complex sites may need refactoring first.

Should we implement now or wait? Nobody’s traffic is coming through WebMCP today, so there’s no immediate conversion case. The arguments for moving early are that implementation costs are modest for form-heavy sites, that the origin trial is a low-risk way to learn, and that agent routing behavior may develop preferences that are harder to displace later. The argument for waiting is that the declarative API isn’t finished and could change under you.

Sources

Tags:

Was this helpful?