Headerline Review

Home › AI Readiness › WebMCP Checker: Detect Whether a Site Exposes Agent Tools

WebMCP Checker: Detect Whether a Site Exposes Agent Tools

Editorial team · Updated 2026-10-14 · 5 min read

A WebMCP checker reports whether a website exposes in-page tools to browser agents. Detection comes down to one question: does the page define document.modelContext and register tools through it? Because WebMCP is still an origin trial, most sites will return no, and that is a normal result today.

What WebMCP is

According to BusinessMCP’s WebMCP guide, WebMCP is a browser API that lets a web page expose named, described, schema-typed actions to an AI agent running in the browser. It is a draft from the W3C Web Machine Learning Community Group, driven by Google and Microsoft, and not a finished standard. Its tools resemble MCP tools, but they run in the page, so no separate server is needed. Because they run in the visitor’s browser they inherit that visitor’s existing session.

A page registers a tool by calling document.modelContext.registerTool() with a name, a description, an input JSON schema and an execute handler. The guide notes the API moved from navigator.modelContext to document.modelContext on 21 July 2026, and recommends registering on both during the transition.

Where it stands

Aspect State, per the vendor’s guide
Standard status Community Group draft
Browser support Chrome origin trial, Chrome 149 to 156, ending 16 November 2026
Other browsers Nothing shipping in Edge yet
Token required Yes; without a valid token the API is undefined
Real-world adoption Close to zero outside demos
Stability Already changed once

Dates and versions in a fast-moving draft age quickly, so confirm them against Chrome’s origin trial page before planning around them.

Key takeaway: a “no WebMCP” result is the expected default in 2026. A checker is useful mainly to verify that your own deliberate implementation is actually live.

How detection works

There are two ways to check, and they answer slightly different questions.

In the browser. Open the console on the page and evaluate whether document.modelContext exists. If it is undefined, the page cannot register tools there. This tests your browser’s support and your token together, so a failure may mean your browser lacks the feature, not that the site lacks tools.

From the outside. A hosted checker inspects what the site serves: scripts that call registerTool, and the origin trial token delivered by meta tag or HTTP header. BusinessMCP offers a free WebMCP checker, and the same check is available as an API endpoint priced at $0.01 per call in its website checks API.

An outside check cannot execute a tool or confirm behaviour inside a live session. It reports what is exposed, not whether the tools work well.

The silent failure to watch for

BusinessMCP’s guide warns that expired tokens fail silently, with no console error or exception. If you ran a trial, forgot to renew and never added monitoring, your tools just vanish. This is the single best reason to schedule the check: a weekly run catches a lapsed token the day it happens. See scheduled website monitoring for a simple setup.

Also guard your registration code with an existence check. The guide says that without one, registerTool() throws on every page load, which can break unrelated scripts.

Testing your own implementation

  1. Serve the origin trial token via meta tag or header, as the trial requires.
  2. Load the page in a supported Chrome version and confirm the API exists.
  3. Confirm each tool appears with a user-language description, since agents match requests against descriptions.
  4. Keep tools idempotent and safe; put irreversible or money-moving actions behind a confirmation in your own UI.
  5. Log an analytics event inside each handler if you want to count tool calls.
  6. Run an outside checker to confirm the exposure is visible without your session.

Should you bother?

The guide’s own advice is measured: ship it only if the cost is low and failure is harmless, and do not expect near-term traffic impact. For most sites the right action is to know the status, not to build. Include the WebMCP result alongside other signals in your AI readiness picture, and if you drive checks through an agent, see the MCP tool route.

Because the API, dates and trial rules are all moving, verify them on Chrome’s official pages before relying on anything here.

Interpreting the possible results

A WebMCP check can come back in a few distinct shapes, and each calls for a different response.

Result What it probably means What to do
No tools exposed, no token The site has not adopted WebMCP Nothing, unless you meant to
Token present, no tools Trial enrolled but registration code missing or failing Check the registration script and its existence guard
Tools exposed Implementation is live Review descriptions and safety of each tool
Tools disappeared since last run Token expired, script removed or deploy regression Investigate the same day
Check unknown The page could not be fetched or read Retry, then inspect by hand

The distinction between “not adopted” and “broken” cannot be made from a single run, which is another reason to keep history. A tool that existed last week and is gone now is a far stronger signal than a tool that never existed.

Security thinking for page tools

Because WebMCP tools run in the visitor’s browser and inherit their session, a tool can do whatever that user can do on the page. BusinessMCP’s guide advises keeping tools idempotent and safe, and putting irreversible or money-moving actions behind a confirmation step in your own interface. Apply the same discipline you would to any endpoint that acts on behalf of a logged-in user: validate input against the schema, avoid exposing actions that were never meant to be automated, and log use.

Also consider what you expose by description. Agents match user requests against tool descriptions, so a vague or overly broad description can cause a tool to be invoked in contexts you did not anticipate. Write descriptions in the language users use, and keep each tool to one clear job.

Where WebMCP sits among the other checks

Think of the four website checks as layers. Crawler access decides whether machines may read your pages. The readiness grade summarises how understandable they are. Email authentication concerns a different channel entirely. WebMCP is about letting an agent act in the page rather than just read it. Because of that, it belongs at the end of your priority list for most sites, and the AI readiness score is the better place to begin.

If you automate the check, the call is cheap at $0.01 and available as the MCP tool webmcp_check; see using the checks from an AI agent for how that fits into an agent workflow.

Frequently asked questions

What is WebMCP?

A browser API that lets a page expose named, described, schema-typed actions to an AI agent running in the browser. It is a W3C Web Machine Learning Community Group draft, not a finished standard.

How can I tell if a site uses WebMCP?

Check whether document.modelContext, or navigator.modelContext on older Chrome versions, exists on the page. If it is undefined, WebMCP is unavailable there.

Can I use WebMCP in production?

Per BusinessMCP’s guide it is currently a Chrome origin trial, and adoption outside demos is close to zero. Ship it only if the cost is low and failure is harmless.

Why would a WebMCP check fail on my site?

Without a valid origin trial token served for the origin, the API is undefined. Expired tokens fail silently, with no console error.