WebMCP for site owners: what to expose first

Browser agents can interact with pages through clicks, text entry and other tools. WebMCP gives compatible agents explicit operations to call, which can reduce the ambiguity of working through a visual interface.

For a service business, the useful question is whether a tool helps a visitor complete a real task: understand a service, check availability or prepare an enquiry. Registration alone does not establish reliable completion, search visibility or customer demand. Test the actual journey in the browsers and agents your customers use.

WebMCP in one paragraph

document.modelContext lets a page publish named tools: each one a name, a plain-English description, an input schema and a function. They run inside the visitor’s own browser tab, under their own login, while they watch. It is not an API you host and not an MCP server you run yourself — the browser does the translation to the agent underneath (Brosset, 23 Feb 2026).

Two ways to add it — one is just HTML attributes

The declarative route needs no JavaScript: add toolname, tooldescription and toolparamdescription attributes to a form you already have. Without the optional toolautosubmit attribute, a human still has to click Submit — the agent fills the form, the person confirms it. The imperative route, registerTool(), suits anything JavaScript-driven: a search box, a calculator, a booking widget (Chrome declarative API docs).

Where it stands in September 2026

WebMCP started as a Microsoft proposal on 28 August 2025 and has moved fast since. Chrome opened a Chrome 149 origin trial on 9 June 2026, and by August the biggest names in e-commerce had switched it on for real customers.

It’s still a Draft Community Group Report of the W3C Web Machine Learning group, explicitly “not a W3C Standard nor on the W3C Standards Track” (spec, dated 2026-09-04). Edge 150 has a matching origin trial; Firefox and Safari have open standards-position issues but no committed status yet (implementation status, fetched 5 Sep 2026).

Who can actually call your tools today

Check the current browser and agent documentation before relying on support. Origin trials, experimental flags and built-in browser integrations have different availability. A page exposing tools does not prove that a particular visitor’s agent can call them. The implementation-status record is a starting point; verify a complete task in your intended setup.

Real examples worth looking at

Shopify’s Liquid storefronts ship ten tools out of the box — search_catalog, get_cart, proceed_to_checkout, search_shop_policies_and_faqs and six more — “live today… nothing to install or configure” (Shopify changelog, 5 Aug 2026). Cloudflare’s developer preview exposes a different initial scope — Content Credentials tools and a bridge to an existing site MCP server: flip Agent Readiness > WebMCP in the dashboard and it injects a bridge script that registers tools client-side, “nothing to deploy and nothing to change at your origin” (Cloudflare, 6 Aug 2026). It does not automatically create a working enquiry or booking integration for a service business.

Our recorded implementation example on enm-compass.life added eleven tools across its core flows. Its score on AIEO’s own agent-interaction checks moved from 0 to 100. That records tool detection under our scoring rules, not a measured improvement in rankings, citations or enquiries. AIEO also exposes seven tools for its scanner and related information.

What to expose first

Don’t try to wire up everything. Chrome’s own guidance is blunt: more tools with overlapping purposes make it harder for an agent to pick the right one (best-practices docs). One useful tool may be enough to start. For a broader workflow, these are three roles worth considering:

1. One read tool. A site overview or search, marked readOnlyHint, so the agent can look before it acts.
2. The one action that’s the point of the site. Prepare a quote, booking or enquiry. Use the relevant consequence annotations, but enforce authorisation and confirmation in the application itself; an annotation is not a substitute for those controls.
3. One status tool. Something that closes the loop — order status, booking confirmation — so the agent (and the person behind it) knows the action actually landed.

Chrome recommends character budgets that can vary by agent and change over time: tool descriptions under 500 characters, parameter descriptions under 150, names under 30, and each tool doing one job rather than several. Use “Express” as a value, not shipping_id=1 — agents reason in words, not database keys — and validate inputs in your own code, because schema constraints aren’t guaranteed to be enforced (Chrome secure-tools docs).

What not to expose yet

For payments, account changes and other consequential actions, enforce authorisation and an explicit confirmation step in the application. Chrome’s guidance discusses an evolving user-interaction API, but its shape differs across draft versions; verify the supported API in the target browser rather than relying on agent.requestUserInteraction() as a portable control. Anything that returns user-generated content should carry untrustedContentHint — the spec names tool descriptions, tool outputs and high-value tool implementations as its three prompt-injection risk points, and that’s worth taking seriously before you wire up a review-summary tool.

The UK angle: privacy and who’s on the hook

In-page execution does not establish where data goes. A tool can call a backend or third-party service, and the visitor’s agent may receive its results. Inspect the actual inputs, outputs, recipients, purpose and retention before exposing personal information. An existing form’s lawful basis does not automatically settle a new use. Explain the processing clearly, minimise the returned data and enforce the user’s permission for consequential actions. The ICO’s privacy-information guidance provides the relevant transparency checklist.

How to check it actually worked

The gotcha almost every checker misses: if registerTool() sits inside a bundler chunk that only loads via import(), and no <script src> on the page names it directly, a naive scan — or a plain grep — won’t find it. Lighthouse 13.3 added an “Agentic Browsing” category that calls the Chrome DevTools Protocol’s WebMCP domain directly to watch for real registration events, catching both declarative and imperative tools, but it needs Chrome 150+ and an origin trial token (Lighthouse 13.3 release). AIEO’s own scan follows same-site import chains rather than just scanning the HTML, and weights agent interaction at 20% of the overall score.

What to do this month

• Pick a useful task. Add read, action and status tools only where the journey needs them.
• Add the four tool* attributes to an existing form, or call registerTool() for a JS-driven flow.
• Register for the Chrome origin trial token if you want it live beyond your own testing.
• Run Lighthouse’s Agentic Browsing audit and a WebMCP-aware scan against your own domain.
• Write each tool description like you’re briefing a new receptionist on their first day.
• Use document.modelContext in new code — navigator.modelContext still works but is the legacy name.

WebMCP won’t replace your normal site for human visitors. It just means the growing share who arrive via an agent get a working interface instead of a guess. Run the free scan at /scan/ to see what your own site currently exposes.