WebMCP would let websites expose callable functions to AI agents instead of DOM scraping

A page that declares what it can do

Today an AI agent that books a table or adds an item to a cart on an ordinary website works by imitation: it reads the rendered page, guesses which input field means what, types into it, finds something that looks like a submit button, clicks, and hopes. A proposal called WebMCP wants to replace that guesswork with an explicit contract. Under the scheme, a page would tell the browser which actions it supports, describe each action's arguments with a JSON Schema, and provide a function the agent can invoke directly.

According to a developer write-up on dev.to, Chrome's team announced an early preview in February 2026, the specification is being developed at the W3C with Microsoft involved, and Chrome's documentation was most recently updated in May 2026. The author's framing: this is a good moment to prototype WebMCP and the wrong moment to stake a product release on it. One sign of the churn is that early demos used navigator.modelContext while current Chrome docs use document.modelContext, with method names and options shifting between browser versions — so even sample code from blog posts can be stale.

What the API looks like

The dev.to post summarises the imperative API from Chrome's developer documentation. A document.modelContext object offers registerTool(), which takes a tool definition plus optional settings such as an AbortSignal for unregistering and an exposedTo list restricting which origins may see the tool. The agent side — also handy for testing — provides getTools() and executeTool(), and a toolchange event fires when the set of available tools changes.

A tool definition carries a stable name, a plain-language description the model reads to decide when to call it, an inputSchema written in JSON Schema, optional annotations such as readOnlyHint and consequentialHint, and an execute() function that receives the parsed arguments and a signal. A declarative variant also exists that annotates existing form elements, requiring no JavaScript at all.

MCP, moved into the tab

For anyone who has used the Model Context Protocol on a server, WebMCP is the same idea relocated into the page. Server-side MCP tools live in a separate process, are called by an AI application connected to it, and require authentication the operator builds themselves. WebMCP tools are JavaScript in the page, called by an agent running in the user's browser, and they inherit the user's existing session and cookies.

The dev.to author singles out that last point as the crucial one: a WebMCP tool runs as the logged-in user, in their tab, so no new authentication system is needed — and every security problem that comes with acting as a logged-in user is inherited too.

A worked example

The post's sample code registers two e-commerce tools: a read-only search_products and a state-changing add_to_cart marked consequentialHint. The choices it highlights are broadly reusable. Feature-detect and exit quietly, because most browsers will lack the API for a while. Reuse existing API routes, since the server — which cannot tell a human click from an agent call — still validates everything. Return small, structured results, because agents bear a cost for every token returned. And update the visible UI when the agent changes state, so a human watching the tab sees what happened. Testing is possible from DevTools with getTools() and executeTool(), behind the origin trial or flags Chrome currently requires.

Treat every tool as a public endpoint

WebMCP creates no new permissions, the author stresses; it makes existing capabilities easier for an automated caller to reach. The guidance: keep authorisation on the server rather than only inside execute(); mark consequential tools, but add your own confirmation step for irreversible actions instead of trusting the hint; treat incoming arguments as untrusted model output, since they may have been steered by a prompt injection on another page; restrict exposedTo to origins you control; and rate-limit, because an agent can call a cart endpoint far faster than any human can click.

The W3C repository reportedly has open issues around tool-registration security, including an early provideContext() call that could clear and replace another script's tools, and third-party scripts on a page can register tools too — which makes auditing what a tag manager loads part of the job.

Not an SEO story

The post also pushes back on claims circulating elsewhere: WebMCP has no effect on crawling, indexing or ranking, and Google has said nothing to suggest it will. Discovery still happens through search and links. Where the proposal bites is the step after discovery — the moment an agent that has found two competing stores decides which one is easier to act on.

Why it matters

If agents increasingly take actions on users' behalf, sites that offer only a human-shaped interface will be navigated by fragile simulation, one misidentified input at a time. WebMCP sketches a standard, session-bound alternative in which the site itself declares what can be done and how. The open questions are real — API churn between Chrome previews, unresolved registration security at the W3C, and the fact that any agent-callable tool is effectively a public endpoint running with the user's credentials. But prototyping now is cheap preparation for a web where agents, not only people, are the ones taking action.