# WebMCP Standard Proposal for Agentic Web Actuation Now Available in Chrome (Origin Trials) > Source: > Published: 2026-06-13 03:32:00+00:00

Google recently announced that WebMCP is entering origin trials in Chrome 149. The new WebMCP standard proposal lets sites expose tools (e.g., JavaScript functions and HTML forms) to in-browser AI agents, which can thus reliably simulate user actions instead of resorting to possibly expensive (e.g., on-screen reading) and often unreliable guesswork (e.g., DOM scraping).

Google explained the motivation as follows:

By defining these tools, you can instruct agents exactly how and where to interact with your site. The result? An agent can now call machine-friendly functions to complete complex tasks in seconds with greater reliability, precision, and personalization. Imagine a user is planning a multi-city vacation. Instead of watching an agent click through travel forms, they can authorize it to query backend APIs directly to instantly build a personalized, weather-optimized itinerary for their approval.

Without WebMCP, an AI agent wanting to act on behalf of the user would download the DOM for relevant web pages, understand the roles of the buttons on the page, take and analyze some screenshots, and deduce the coordinates for a simulated mouse click on the relevant button. As often noted, the process can be non-deterministic and token-expensive: a CSS layout shift or a delayed ad load can break the entire automation loop; image processing, even for low-resolution images, is the source of added latency and token consumption.

As with the standard backend-focused Model Context Protocol (MCP), web authors can provide an explicit API for AI agents to perform personalized tasks on behalf of human users. WebMCP, however, operates entirely on the client side. WebMCP is purpose-built for the browser and omits various server-side concepts, such as resources. Essentially, WebMCP helps agents reliably understand Web UI by defining APIs that provide agents with a menu of named, typed, and described actions they can call directly.

The specification defines two API surfaces. The Declarative API allows developers to annotate existing HTML forms with custom attributes:

<form

toolname="Search flights"

tooldescription="This form searches flights and displays [...]"

toolautosubmit>

The Imperative API uses the modelContext interface to register tools. Tool registration requires a name, a description, and an input schema with relevant properties:

document.modelContext.registerTool({

name: 'toggle_layer',

description: 'Control pizza layers (sauce, cheese). Use "add", "remove", or "toggle".',

inputSchema: {

type: 'object',

properties: {

layer: { type: 'string', enum: ['sauce-layer', 'cheese-layer'] },

action: { type: 'string', enum: ['add', 'remove', 'toggle'] },

},

required: ['layer'],

},

execute: async ({ layer, action }) => {

await toggleLayer(layer, action);

return `Performed ${action || 'toggle'} on layer: ${layer}`;

},

});

The registered tool executes UI logic, handles state management, and returns direct payloads to the agent.

One early implementer who built a WebMCP polyfill for Chrome DevTools reported up to a 90% reduction in LLM token usage:

Playwright and Chrome DevTools MCP servers are the standard for agent-driven web app testing, but their token efficiency is terrible: the screenshot-action-screenshot loop quickly explodes context windows.

I’ve been using browser automation instead of TDD (agents over-mock tests), but needed to solve the token bloat. So I forked the Chrome DevTools MCP server to execute WebMCP tools from client-side JavaScript.

[…] Initial benchmarks show a roughly ~90% decrease in token usage, but other benefits which are harder to measure are speed and determinism (both of which are significantly improved).

The proposal authors remind developers that LLMs are susceptible to indirect prompt injection and that exposing native site APIs introduces security risks that have to be understood and managed. The authors recommend that developers use explicit annotation hints within their tools. Data payloads sourced externally must include an untrustedContentHint, signaling to the agent that the input requires strict security scrutiny. Conversely, non-mutating operations can utilize a readOnlyHint to help the agent decide when explicit human confirmation can be safely bypassed.

There are also operational risks to consider. If a refund workflow is callable but the refund policy is stale, the agent can execute the wrong action cleanly. If a user has access to a page but not to the downstream business rule, a browser agent can expose a permission gap that human judgment previously masked. Developers are encouraged to use AI evals on targeted user journeys.

Early adopters noticed that while WebMCP gives the agent a better interface to the site, the agent still needs “accurate information about policies, customer state, product rules, eligibility, exceptions, and escalation paths.”

Developers are additionally encouraged to write succinct tool descriptions and outputs that fit within predefined character budgets: 500 characters per tool description, 150 characters per parameter description, 30 characters per tool name and parameter name, and a 1,500-character limit per individual tool output.

Google’s Chrome team announced WebMCP alongside broader browser AI work at I/O 2026, including agentic browsing, built-in AI APIs, and developer tooling for AI agents in Chrome.