Skip to content
Science-backed data on why AI says what it says
Browser usability

WebMCP

WebMCP is an emerging browser interface through which a web application can expose described, structured actions to an AI agent. Detecting a reference or API object does not show that any action was successfully performed.

Checked against BLURSOR’s measurements ·

What it means

Instead of relying entirely on an agent interpreting the interface, a site can describe an action and its inputs. The emerging specification includes JavaScript tools and declarative approaches. This is an optional application capability, separate from making a public page readable or allowing a crawler through robots.txt.

As reviewed on 14 September 2026, WebMCP is a Web Machine Learning Community Group draft, not a W3C Standard or a Standards Track specification. Chrome's documentation describes an origin trial and a local development flag. Browser availability and API details can change; check current documentation before planning an implementation.

Illustrative example

Hypothetical example: checking collection availability

Imagine a shop offering an action that accepts a product identifier and a collection location, then returns availability. An agent could request that information through the described action while the shopper remains in the page.

That example does not demonstrate a working integration. Selecting a location, reserving stock, and placing an order are different operations. A team would need to define and test the intended behaviour of each, particularly where an action changes a customer's order.

How BLURSOR measures it

In the report: Actions exposed to browser agents

BLURSOR searches raw page code for modelContext or a registerTool call. This supports a source-mention result only: documentation, examples, or inactive code can contain those strings.

During a usable browser capture, the probe checks for document.modelContext or navigator.modelContext. It also attempts to read a tool count through supported synchronous properties or methods. API-object presence is runtime evidence, but by itself does not prove that the page registered a usable tool. BLURSOR does not execute the actions or verify their outcomes.

What to do next

  1. Start with a concrete customer task and decide whether a structured browser action would add value to an already understandable interface.
  2. Ask your developer to verify current browser support, inspect actual registrations, and test the result of each intended action in a controlled environment.
  3. Keep ordinary controls usable and define how the user understands and approves consequential actions. Treat source detection as an inspection lead.

What it cannot tell you

  • Not detected is not a penalty or evidence that the business needs WebMCP. A detector can miss integrations loaded later or exposed through different API versions.
  • Presence does not establish interoperability, safe execution, successful transactions, search indexing, or improved AI recommendations.

Sources and further reading

The definitions below describe the underlying concepts. The measurement section describes BLURSOR’s own checks.

Related explanations