EvalSignal 012 / Independent agent infrastructure
Instead of making an AI agent guess what a page can do, WebMCP lets the site expose its actions as structured tools.
Until now, AI agents - browser assistants driven by models such as Claude, ChatGPT, or Gemini - have generally had to use websites much like a person does: take a screenshot, inspect the DOM, guess which button means "Add to Cart," click, and hope. That approach is slow and brittle. A small redesign can break an agent's entire flow overnight.
WebMCP is a proposed web standard aimed at fixing this at the root. Announced at Google I/O 2026 and now being developed under the W3C Web Machine Learning Community Group, it lets a website tell an agent exactly what it can do and how each action should be called.
Think of WebMCP as Anthropic's Model Context Protocol adapted for the browser, but without a separate MCP server to deploy. The page itself becomes the tool surface:
checkout or filter_results with the browser.There are two implementation paths:
navigator.modelContext.registerTool(). This suits complex and dynamic flows such as multi-step booking or filtering.One important design choice is that tools execute visibly on the page. The user can see the agent operating the interface instead of silently calling an unrelated backend API. That preserves the site's experience and makes the result easier to inspect.
Early origin-trial reports say structured WebMCP calls produce fewer errors and higher task-completion rates than visual DOM scraping, with checkout flows completing faster in particular. These are early, vendor-reported results, so they should be treated cautiously. The direction, however, is clear: a typed contract should be more reliable than interface guesswork.
navigator.modelContext.Extension-based agents are another natural client. One open-source example is WebBrain. It currently works through screenshots and the accessibility tree, but an extension-based, local-model-friendly agent is also a practical place to test WebMCP tools inside a real browser session.
For broader cross-browser experiments, small polyfills also exist. Latch, for example, is a zero-dependency script that scans the DOM and registers core actions as WebMCP tools.
This is not production-ready everywhere. Still, simultaneous movement from major browser vendors and agent-focused browsers suggests WebMCP is more than a one-off experiment.
chrome://flags/#enable-webmcp-testing, enable it, and relaunch Chrome.The simplest route is to annotate an existing form with the Declarative API:
<form id="reservation-form" tool-name="book_table"
tool-description="Books a table reservation">
<input name="date" type="date" required>
<input name="guests" type="number" min="1" required>
<button type="submit">Book Table</button>
</form>For dynamic scenarios, register a tool through the Imperative API:
navigator.modelContext.registerTool({
name: "filter_results",
description: "Filters the product list by max price",
inputSchema: {
type: "object",
properties: {
maxPrice: { type: "number" }
},
required: ["maxPrice"]
},
async execute({ maxPrice }) {
applyPriceFilter(maxPrice);
return { filtered: true, count: getVisibleCount() };
}
});document.domain, including through an Origin-Agent-Cluster: ?0 header, cannot use the API.<iframe allow="tools">; the default Permissions Policy allows only self.WebMCP remains an origin-trial technology and the specification can change. Locking in a permanent integration today carries risk.
But the underlying idea is hard to argue with: agents should not have to reverse-engineer every interface before doing useful work. If you already see agentic traffic, a small Declarative API pilot is a low-cost way to learn where structured browser tools help and where visual interaction still matters.
Sources and further reading
Chrome for Developers: WebMCP | W3C WebML Community Group: WebMCP
