← Blog · September 3, 2026 · Mohamed Salama
What Is WebMCP? How Websites Become Tools for AI Agents
Listen

What Is WebMCP? How Websites Become Tools for AI Agents

Today, when an AI agent uses a website on your behalf, it does so the hard way. It takes a screenshot or reads the DOM, guesses which button means "add to cart," clicks, waits, and guesses again. It is slow, it breaks whenever the layout changes, and the site owner has no say in any of it. WebMCP is a proposed web standard that fixes this by letting a page tell the agent, in a structured way, what it can do. This piece covers what WebMCP is, how it works, where browser support stands as of September 2026, how it relates to the Model Context Protocol, and why anyone who runs a website should be paying attention.

The one-sentence version

WebMCP lets a web page register a set of named, described, schema-typed tools that a browser-based AI agent can call, using either a small JavaScript API or plain attributes on HTML forms. The specification puts it neatly: pages using WebMCP "can be thought of as in-page Model Context Protocol servers" that expose client-side logic and DOM interaction rather than server-side APIs. The user stays on the page, the browser stays in the middle, and the agent does the tedious part.

Where it came from

The idea was demonstrated first by an independent developer project, MCP-B, which ran MCP-style tools inside the browser. Google's Chrome team and Microsoft's Edge team then published a unified proposal in August 2025, and the W3C's Web Machine Learning Community Group adopted it as a work item that September. The draft is edited by Brandon Walderman at Microsoft and Khushal Sagar and Dominic Farolino at Google, and it remains a Draft Community Group Report, meaning it is a serious proposal with real implementations but not yet a W3C Recommendation. Chrome shipped the first implementation in Canary in February 2026 behind an early preview program, and at Google I/O in May 2026 the team announced an origin trial in Chrome 149 that runs through Chrome 156, letting any site test it in production with real users. Edge ships support behind a flag. As of this writing there is no public Safari or Firefox position.

Google has named Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, and Target as companies experimenting with it. The cluster is telling: travel, commerce, and finance are the places where an agent doing a multi-step task on a website is most valuable and where a mis-click costs the most.

How it works: two APIs

The specification offers an imperative API for dynamic applications and a declarative one for ordinary forms. Most real sites will use both.

The imperative API

The entry point is document.modelContext. A page calls registerTool with a name, a description written for a language model, a JSON Schema for the inputs, and an execute callback that runs the page's own code and returns a result. The canonical example from the spec registers an "add-todo" tool whose callback adds an item to the user's list and returns a text confirmation. Tools can be unregistered with an abort signal, a toolchange event fires when the set of tools changes, and getTools and executeTool let an agent discover and invoke what the page offers. Because the callback is ordinary JavaScript running in the page, it reuses whatever validation, state, and authentication the site already has. The agent never gets an API key; it gets the same session the user already has, mediated by the browser.

One implementation detail matters if you are experimenting now. The API originally lived on navigator.modelContext. The draft moved it to the document object in May 2026, and Chrome deprecated the navigator location in version 150. Older tutorials will show the old name.

The declarative API

For the large fraction of website actions that are already HTML forms, no JavaScript is needed. Two attributes on a form, toolname and tooldescription, are enough for the browser to synthesize a tool: the form's fields become the input schema, and each field's label becomes its parameter description. An optional toolparamdescription attribute overrides that per field, and toolautosubmit lets the agent submit without waiting for the user to press the button. Remove either required attribute and the tool disappears. A search form, a support request form, a booking form: each becomes callable with roughly one line of markup. That is the lowest-friction path to "agent-ready" the web has seen, and it is why the declarative API is likely to drive most early adoption.

How it differs from MCP

The naming invites confusion, so it is worth being precise. The Model Context Protocol connects an AI application to a server: a backend, an API, a database, usually through a URL or a local process, with the agent authenticating in its own right. WebMCP connects an agent to a page: it runs in the user's browser tab, in the user's session, while the user watches. The specification's non-goals draw the line explicitly. WebMCP is not for headless browsing, not for fully autonomous workflows without human oversight, and not a replacement for backend protocols like MCP.

In practice the two are complementary layers of the same idea. A company might publish an MCP server so agents can act on its systems programmatically, and add WebMCP to its website so an agent helping a signed-in customer can use the site directly without the company building anything new. The same tool concept, with a name, description, and JSON Schema, runs through both, so a team that has designed tools for one has done most of the thinking for the other.

Why it matters

For site owners, WebMCP turns agent traffic from something that happens to you into something you shape. Today an agent scraping your page decides what your site does. With WebMCP you decide which actions exist, what they are called, and how they are described, and you keep the user on your property rather than in a third-party interface that summarizes you away. The spec lists preventing that disintermediation of web content as an explicit goal.

For users, the promise is reliability and control. Structured tool calls do not break when a stylesheet changes, and the browser can show what the agent is about to do and ask before it does it.

For accessibility, an agent driving a well-described tool surface is a new kind of assistive intermediary, and sites that annotate their forms for agents are also, as a side effect, annotating them for people.

The open problems

WebMCP inherits every security problem of agentic AI and adds a few of its own. The draft's security and privacy section names them directly. A tool description is text the model reads, so a page can hide instructions in it (prompt injection). A description can misrepresent what the tool actually does. A site can design tools with far more parameters than a task needs, coaxing the agent into handing over personal data it holds from elsewhere. An agent that carries state across tabs can leak one origin's data into another. And private browsing modes need to stay private when an agent is present. Academic work is already probing these seams, including a 2026 paper on runtime manipulation of the WebMCP tool surface.

There are practical unknowns too. The spec's declarative section is still being written. Only Chromium-based browsers implement anything today. The primary consumer, Gemini in Chrome, is described as coming soon rather than shipped, so most tool calls right now come from extensions and developer tooling such as the Model Context Tool Inspector. And the adoption figures circulating in marketing posts should be treated as noise: the meaningful signal is the named partner list and the origin trial, not percentages.

What we would do now

Three suggestions, in order of effort.

Annotate your forms. Adding toolname and tooldescription to your most important forms costs almost nothing, is harmless in browsers that do not understand it, and forces a useful question: what does this form actually do, in one sentence? If you cannot answer, the form probably needs work anyway.

Design your tool surface deliberately. Decide which actions an agent should be able to take, keep parameters to the minimum, mark read-only tools as such, and assume every description will be read by a model that can be tricked. Treat it as product design, because it is.

Think about MCP and WebMCP together. If you already expose an MCP server, or plan to, the same catalog of capabilities should inform what your website registers. We build conversational products on FlowCP, and our working assumption is that the products that win the next few years will be reachable by agents through both doors.

The web spent thirty years being designed for eyes and cursors. WebMCP is the first serious attempt to add a second interface for agents without abandoning the first. Whether it becomes a standard depends on browsers beyond Chromium and on the security story holding up under real traffic. Either way, the question it asks every site owner is worth answering now: what should an agent be allowed to do here? If you are working that out for your own product, tell us about it.

Sources