WebMCP

What WebMCP actually is

For thirty years the web assumed a human on the other end of the screen. A page laid out buttons, forms, and links, and a person read them and decided what to click. AI agents inherited that world and cope with it badly: they take a screenshot, infer what the interface means, and simulate a click, which is slow, brittle, and easy to get wrong when a layout changes.

WebMCP inverts the relationship. Instead of the agent reverse-engineering your interface, your page declares what it can do. It registers tools, each with a name, a plain-language description, and a typed input schema, and the agent in the browser reads that list and calls the tools directly. A restaurant site stops being a grid of pixels an agent has to interpret and becomes a small, explicit API: searchAvailability(date, partySize), book(slotId, name). The agent calls the function; your code runs; a structured result comes back.

This matters because discovery is moving from search results a person clicks to actions an agent takes on a person's behalf. WebMCP is one proposal for how a business speaks to that agent in its own terms rather than hoping it guesses correctly.

Two ways to expose a tool

WebMCP defines two APIs, and most real sites will use both. They are documented in depth on their own pages; here is the shape of each.

The imperative API is JavaScript. You call document.modelContext.registerTool() with a tool's name, description, an inputSchema written as JSON Schema, and an execute callback that runs when the agent invokes it. It suits dynamic actions like search, filtering, or anything that already lives in your front-end code. See the imperative API reference.

The declarative API is HTML. You annotate a <form> you already have with toolname and tooldescription attributes, and the browser synthesises a tool from the form's fields. It suits standard actions, a search box, a booking form, a contact form, without rewriting them in JavaScript. See the declarative API reference.

The distinction is not cosmetic. A declarative tool is visible in your HTML; an imperative tool is registered at runtime and is invisible to anything that only reads static markup. That single fact shapes how WebMCP can and cannot be detected, which we return to below.

The security model is the point, not an afterthought

An interface that lets software take actions on a site is a security surface, and the draft treats it as one. WebMCP is restricted to secure contexts, so tools only exist on HTTPS pages. Access from cross-origin iframes is governed by a Permission Policy: a call is rejected with a NotAllowedError when the tools policy is not granted. A tool can be scoped so it is exposed only to the origins or agents you intend.

The draft is explicit that these are human-in-the-loop workflows, with user visibility, history, and control over what an agent does. One attribute deserves particular attention: the declarative API includes toolautosubmit, which lets an agent submit a form without a manual review step. That is a convenience and a risk in the same attribute, and it is exactly the kind of design decision a business should understand before shipping. Exposing a tool is exposing a capability; the discipline is the same as any public API surface.

Where it stands, honestly

WebMCP is a Draft Community Group Report in the W3C Web Machine Learning Community Group. A community group draft is a serious, editor-maintained document, and it is not the same thing as a W3C Recommendation. WebMCP is not on the standards track, and nobody can promise if or when it lands there.

You can test it now. Chrome ran a public origin trial from Chrome 149 through Chrome 156; Edge has experimental support behind a flag; Firefox and Safari are in the conversation without commitments. Backing from engineers at both Google and Microsoft is real momentum, and it is why WebMCP has traction that a purely read-oriented convention like llms.txt did not. But momentum is not adoption.

The adoption reality

As of July 2026, no mainstream agent calls WebMCP tools in production. Google has said Gemini in Chrome will be the first consumer, with no confirmed ship date. Claude, ChatGPT's agent, Perplexity, and today's Gemini still read pages the old way. This is the single most important fact for a business deciding whether to act, and it is the one most easily lost in the excitement: publishing WebMCP tools today is forward-positioning, not a live channel. The tools you expose are read by almost nothing yet.

That does not make it pointless. Being early on a genuine platform shift is how some businesses win the next surface. It does mean the honest recommendation is understanding first, action second, and only where the action is cheap and reversible. We are not going to tell you that a feature no agent consumes yet is an emergency.

A live example of "still changing": the namespace moved

If you want proof that WebMCP is unsettled, watch its own name. The API was first exposed as navigator.modelContext. On 21 July 2026 the specification moved it to document.modelContext, and Chrome 150 deprecated the older navigator.modelContext location while the origin trial continued to serve it. Anyone who built against the first name inherited migration work within weeks.

This is not a criticism of the project; it is how pre-standard web features are supposed to develop, in the open, with breaking changes early rather than after the world depends on them. It is also the reason a reference like this one exists: a claim about WebMCP's API is only as good as its date. Where this page names a method or an attribute, it is current as of the reviewed date and should be checked against the primary source before you build on it.

Why a scan may not see WebMCP, and why that is fine

Because imperative tools are registered at runtime by JavaScript, they do not appear in a site's static HTML. A crawler that only reads the page source, the way most audits do, cannot see them. Declarative tools live in the markup and can be detected; imperative ones generally cannot without executing the page. So a report that says "no WebMCP detected" may be reading a site that registers tools perfectly well at runtime.

The stronger point: as of today, the absence of WebMCP is not a defect. There is no mainstream consumer, no ranking effect, and no penalty. Any tool that hands a business a WebMCP score, or implies that a missing document.modelContext is a problem to fix now, is inventing a standard the field has not set. AIOFacts will not do that. What can be observed and reported honestly is narrow: whether a page's HTML contains declarative tool annotations, and whether the page appears to reference the API at all. That is evidence, not a grade. Read what WebMCP readiness really means.

What remains unsettled

• The final namespace and method surface. document.modelContext.registerTool() is current; getTools() and executeTool() are noted as still to be specified.
• How the browser synthesises an input schema from a declarative form's fields. The exact algorithm is marked to-be-determined.
• How a declarative tool returns its result to the agent, and whether declarative tools should have output schemas at all.
• Whether other browsers implement it, and whether any agent beyond Gemini in Chrome consumes it.
• Whether WebMCP, one of several proposals for a business-to-agent interface, is the one the agentic web converges on.

If you have a primary source that updates any line on this page, send it. Corrections are public and dated in the correction record.

Sources

This page is built from primary and first-party material and dated to its last review, 23 July 2026.

• webmachinelearning/webmcp, the W3C Web Machine Learning Community Group repository: specification source, explainers, and issue tracker.
• The WebMCP draft specification: the Draft Community Group Report, including the interface definition and security model.
• Chrome for Developers: origin-trial announcement and release notes for the modelContext API (Chrome 149 through 156).
• AIOInsights: the WebMCP readiness beta, a first-party application of the standard to a specific site.

Where a browser version, an origin-trial window, or an API name is quoted, it is current as of the reviewed date. WebMCP changes quickly; confirm against the primary sources before building.