WebMCP Browser-Native Agent Protocol — What It Is, Why ...

llms.txt has been around for over a year. Adoption is still under 11% of public sites, OpenAI and Google's crawlers don't fetch it in volume, and the SERanking 300K-domain study published in early 2026 found no measurable citation lift on sites that ship it. The promise was: a clean declarative way for sites to tell AI agents what they're for and what they expose. The reality has been: an extra file that nobody asks for.

WebMCP is the fix.

What WebMCP actually is

Chrome shipped WebMCP in Canary on February 10, 2026, behind the chrome://flags "WebMCP for testing" toggle. It is a W3C Community Group Draft jointly developed by browser vendors and the AI agent ecosystem. The core idea: a webpage declares what actions an agent can take on it, in formats the browser itself enforces and exposes to whichever agent the user is running. Unlike llms.txt, which sat next to the site and was an opt-in fetch by AI crawlers, WebMCP runs in the user's browser and is consumed by the user's agent — Claude Code, Cursor, the Chrome built-in AI Prompt API, OpenCode, or any agent extension.

There are two surfaces. The Declarative API is HTML attribute annotations on existing forms and elements: data-webmcp-action, data-webmcp-form, data-webmcp-input. A static page can expose actions by adding attributes — no JavaScript required. The Imperative API is a window.webmcp namespace with register() and expose() calls, for sites that need dynamic capability declarations (a SPA, a CMS-backed page that varies per user).

Both compile to the same outcome: when a WebMCP-aware browser agent loads your page, it sees a structured surface of actions it can take on the user's behalf. The model doesn't have to scrape, infer, or guess what's clickable. The page tells it.

Why this is different from llms.txt

Three reasons llms.txt didn't take, and WebMCP probably will.

Browser distribution. llms.txt requires every AI crawler vendor to opt in. Most haven't. WebMCP runs in the browser the user is already using to interact with the agent. Chrome Canary already supports it. Edge ships Chromium and will inherit. Once one major browser implements something this directly, the others follow within a release cycle.

The agent is on the user's side. llms.txt was about telling someone else's crawler what your site is for. The crawler may or may not care, may or may not respect the declarations. WebMCP is about telling the user's own agent what actions it can take on your page. The user's agent has every incentive to read those declarations because it makes the agent more useful to its operator.

The standardization pattern is different. llms.txt was Anthropic publishing a markdown spec with no formal IETF / W3C process. WebMCP is W3C Community Group Draft with cross-vendor participation from the start. Community Drafts aren't binding standards yet, but the process means surface conventions are likely to stabilize rather than splinter.

The four declarations to add

The WebMCP Readiness Checker audit tests for these four:

1. /.well-known/webmcp discovery file. A JSON manifest at the conventional well-known path declaring the site's overall WebMCP capabilities. Browser agents check this first to learn what actions the site supports site-wide. Pattern follows .well-known/ai-plugin.json and similar precedents.

2. Inline <script type="application/webmcp+json"> capability blocks. Per-page action declarations. Lets a single page declare specific actions the agent can take — submitting a particular form, calling a specific API endpoint, navigating to a specific outcome. Inline because it's per-page, structured because it's machine-consumed.

3. Declarative attributes on existing HTML. data-webmcp-action, data-webmcp-form, data-webmcp-input, data-webmcp-trigger annotations on existing forms and buttons. The static-page path. A WordPress site, an Eleventy build, a hand-written contact page can adopt WebMCP without writing any JavaScript by adding attributes to elements that already exist.

4. The window.webmcp imperative API. For SPAs and dynamic sites where capabilities change per user or per session. webmcp.register({...}) exposes an action; webmcp.expose(formElement) annotates an existing element programmatically. The agent receives the same structured action surface as if the declarations had been static.

Why this is a first-mover moment

Adoption right now is essentially zero. The Chrome flag is behind a Canary build. Most SMB site owners have never heard of WebMCP. The few large sites that have adopted are mostly experimenting with the Imperative API on internal tools.

For an SMB site shipping any of the four declarations in the next 90 days, the calculus is straightforward:

Cost: minutes-to-hours of work depending on which surface you adopt
Risk: the spec may shift before stable release; selectors might rename
Upside: when the Chrome WebMCP flag flips to default-on (likely this year), every WebMCP-aware agent in every Chromium browser on the planet immediately understands your action surface

The downside risk is small because the declarations don't break anything if the spec moves — they're additive HTML attributes and a JSON file at a well-known path. Worst case, you re-deploy when the spec stabilizes.

The upside is the kind of thing that's only available before a standard reaches mass adoption. Once every site on the internet has WebMCP declarations, having them stops being a differentiator. Right now, having them at all is.

A minimal first adoption

If you want to ship the simplest possible WebMCP surface today, do these three things:

1. Add a .well-known/webmcp JSON file declaring your site at the highest level:

{
  "name": "Your Site",
  "description": "What this site does",
  "capabilities": []
}

(Empty capabilities is fine for a minimal manifest. Discovery is the first signal.)

2. On any contact / signup / search form, add data-webmcp-form and data-webmcp-action="submit-form" to the form element, and data-webmcp-input="email" (or appropriate type) to each input. The form keeps working for humans; the agent now knows what fields exist and what the form does.

3. Run WebMCP Readiness Checker on the page to confirm the audit picks up your declarations.

That's the whole minimum. Three changes, one file, half an hour. Good enough to be one of the first SMB sites in the WebMCP audit registry, far enough ahead of the curve to write the case study when the spec ships.

Why the audit exists separately

The WebMCP Readiness Checker is the audit-side of this. It probes any URL for the four declarations above and scores 0–100 in 25-point increments per surface. In May 2026, almost every site you point it at will score 0 — which is the point. The audit gives you a measurable starting position, an honest signal of where adoption stands across the broader web, and a way to verify your own implementation as you ship the four declarations.

Where this fits with everything else

WebMCP is one slice of the broader agent runtime as the new browser layer shift. Markdown for Agents covers the content-retrieval side: how an agent gets a clean version of your page. WebMCP covers the action side: what the agent can do on your page once it's read. The two are complementary — a page can ship one without the other, but the most agent-legible sites in 2026 will ship both.

For SMB sites, the order to think about it: ship Markdown for Agents first (content retrieval is the bigger near-term lever), then add WebMCP declarations (action surface is the bigger long-term lever). Both are additive. Neither requires new infrastructure. Neither breaks anything for human visitors.

Fact-check notes and sources

Chrome WebMCP introductory post (February 10, 2026): developer.chrome.com/blog/webmcp-epp
VentureBeat coverage of the Canary launch: venturebeat.com — Google Chrome ships WebMCP in early preview
W3C Community Group Draft (working location): the WebMCP spec is in active draft via the Web Platform Incubator Community Group
Chrome Prompt API (the local browser-side AI surface that increasingly consumes WebMCP-declared sites): developer.chrome.com/docs/ai/prompt-api
llms.txt adoption study (May 2026): aeo.press — State of llms.txt in 2026
DataCamp WebMCP tutorial (the cleanest end-to-end walkthrough I've seen): datacamp.com — WebMCP tutorial

If you're building a small but ambitious operator stack — your own site, your own audit loop, your own measurement — The $20 Dollar Agency covers the lean operating model behind that approach.

This post is informational, not legal or implementation advice. WebMCP is a W3C Community Group Draft as of writing — surface conventions may change before stable release. Mentions of Chrome, Anthropic, OpenAI, and other parties are nominative fair use; no affiliation is implied.

WebMCP — The First Real Agent API For Your Site (And Why llms.txt Wasn't It)