WebMCP and the agent-readable web

Shipped, proposed, or speculative?

Almost everything written about WebMCP mixes three very different kinds of claim. This page keeps them in separate columns, because the difference between them is the entire story.

Status of the specification

Dated, because this moves. Everything below reflects what was publicly known as of September 2026.

Read that table before reading anyone's WebMCP strategy advice, including the rest of this page. Five of the six rows are negative.

What actually shipped, and when

Google's Chrome team shipped an early preview in Chrome Canary in February 2026: a protocol for more structured interaction between AI agents and website functionality, developed jointly with Microsoft and progressing through the W3C standards process. That is the whole of the shipped artefact.

Two things are worth separating immediately. The first is AI SEO in the ordinary sense: getting content retrieved and quoted by an answer engine. The second is agent action — a machine completing a task on your site. WebMCP addresses the second and says nothing about the first. Conflating them is the most common error in early coverage of this proposal.

For what already reaches sites today — which agents fetch, how often, and whether they render anything — see what agentic browsers actually fetch and a 30-day site log study of agentic crawler behaviour. That is the world WebMCP proposes to replace.

What problem is it trying to solve?

To see why two browser vendors bothered, follow what an agent has to do today to book a flight. It loads the page. It renders the layout. It works out, from pixels and DOM structure, which box is the origin field and which is the destination. It guesses that the calendar widget is a date picker, and that the blue rectangle is the submit button rather than an advertisement. Every one of those is an inference that can fail.

That approach works, sometimes, and it is brittle in a specific way: a visual redesign that changes nothing functionally can break it completely. There is a second cost, less obvious. Visual interpretation is expensive — it requires rendering the page, running its JavaScript, and reasoning over the result. Search infrastructure has measured that tax for years, in Onely's work on Google's rendering delay and on how much longer JavaScript takes to crawl than plain HTML. Whether current AI fetchers pay that cost at all is a separate and much less settled question, covered in do AI crawlers render JavaScript.

WebMCP proposes the obvious alternative: let the page declare what it can do. Instead of an agent guessing that a form searches a catalog, the page declares a "search catalog" function and states what parameters it takes. The guessing step disappears. That is a familiar pattern in web history — something implicit becomes explicit, as schema.org did for page meaning and sitemaps did for URL discovery. The novelty is applying it to actions rather than to information.

How is WebMCP different from MCP?

These get conflated constantly. The names are similar, the ideas are related, and the scope is genuinely different.

The practical difference is operating burden. An MCP server is infrastructure you run, monitor and keep available; a WebMCP declaration ships with the page you already serve. Alex Merced's survey of agentic AI standards in 2026 is the clearest public map of how MCP, A2A and WebMCP fit together.

The consuming side is the half that decides whether any of this matters, and it currently points the other way. Anthropic's web search tool documentation and Perplexity's developer documentation both describe systems that retrieve pages as documents to be read, not as interfaces to be called. Until a shipping assistant says otherwise, supply is the only side that exists. The other half of that picture is in MCP servers as a visibility channel.

Who should act on this, and who should not?

Coverage of emerging standards implies everyone should act. That is rarely true. Find your row.

Documentation is the likeliest beachhead, and the reasoning is worth borrowing. Docs sites are built by the same people who would implement the protocol, so there is no marketing-to-engineering handoff. The actions involved are read-only, which removes most of the security concern. And documentation teams already serve machines deliberately, since IDE coding agents are an established audience. The llms-full.txt convention is a real adopted use case for exactly that reason. If you are guessing where this gets traction first, look for that combination.

What do the precedents predict?

Three previous machine-readability proposals ended very differently, and reasoning from only the convenient one is how forecasts go wrong.

The optimistic precedent: sitemaps. A proposal from a single company that other engines adopted and that became load-bearing infrastructure. Bing still describes sitemaps as central to keeping content discoverable in AI-powered search, and IndexNow is the same play run again, pushed through a deliberate cross-industry adoption campaign. The path took years, but it completed.

The pessimistic precedent: llms.txt. A proposed file with a genuine spec and real adoption numbers — one tracker reported adoption rising 8.8x over a year. Against that sit three findings. Google states publicly that it does not use the file. An analysis across 300,000 domains found no clear effect on AI citations. And log-based work concluded that the overwhelming majority of files are never requested at all. Adoption grew without the underlying benefit ever being demonstrated. Our own 90-day log test reached the same place: a null result, of the kind the null results registry exists to collect.

The difference between those two outcomes is the whole lesson. Sitemaps solved a problem the consuming systems actually had, and those systems chose to consume them. llms.txt proposed a solution the consuming systems largely declined. A standard needs demand on both sides, not just supply.

WebMCP sits awkwardly between them. It has something llms.txt lacked: the party that would consume the interface is the same party shipping the specification. It also has something sitemaps never had to overcome — a much higher implementation cost. A sitemap is generated automatically by essentially every CMS; working, tested, callable functions are not. That asymmetry is the main reason to expect a slow curve even with browser-vendor backing.

What are the risks of exposing callable actions?

Coverage of new standards skews optimistic. Four considerations deserve airtime before anyone implements this.

That last one is not hypothetical. Telling a training crawler from a live retrieval fetcher is already hard: see GPTBot versus OAI-SearchBot and the AI bot user-agent registry, where every entry is a string a client chooses to send. Cloudflare has also documented crawlers that evade no-crawl directives outright. A callable interface inherits all of that and adds side effects on top. None of this argues against the direction; it argues for treating this as engineering work with real trade-offs rather than a marketing checkbox.

What would implementing it actually involve?

Read that list and the recommendation above should make sense. This is a genuine engineering project with ongoing cost. Recommending it broadly, on the strength of a preview with no measured benefit, would be exactly the kind of confident advice this site exists to push back against.

What would change the verdict?

If you are in the awareness-only camp, which is most people, the useful question is what would move you out of it. These are the specific, checkable signals, ordered by how much each would tell you.

Until at least two of those land, awareness genuinely is the correct posture. That is not a hedge; it is the honest read of a preview-stage technology with no measured outcomes. In the meantime the work that pays off is unglamorous and already measurable — a clean crawl path, fast responses, and content a retrieval system can extract without rendering anything. The technical GEO audit covers that ground.

The research gap, and limitations

No study, ours included, has measured whether structured agent-interaction interfaces are associated with AI-search visibility or with agent task-completion rates. What such a study would need is not mysterious: a corpus of sites with declared functions, log access on the serving side, and a fixed panel of agents — the same shape as the crawl-to-citation latency study. Nothing on WebMCP is on the studies roadmap yet, and saying so is more useful than filling the space with a forecast.

• Fast-moving and early-preview — details here reflect what was public as of September 2026 and will date quickly.
• No effect on visibility or citation has been measured — this describes an emerging protocol, not a validated tactic.
• Explainer, not original research. Every factual claim here is second-hand, drawn from public announcements rather than from us testing the preview — the standard applied to other people's numbers in the provenance audit applies to this page too.
• Adoption forecasting is nobody's strength, including ours. The precedents above point in different directions on purpose.

Two ways on from here. If you want to be told when the signals above actually fire, the newsletter is where dated updates to this page get sent. If you would rather read measurement than forecasting, the studies index lists what is actually running, and the llms.txt log test is the closest analogue to how this proposal would eventually be judged.