A new spec lands. It has a W3C Community Group Draft. It is co-authored by Google and Microsoft. It is running in Chrome 146 beta. Within days the industry has declared it a fundamental shift in search, the next schema markup, the thing you need to implement right now before everyone else does.
The pattern is familiar. The question worth asking, before reaching for the implementation guide, is what the thing actually does — and whether what it does is genuinely new.
What the declarative API actually is
The declarative API, which is the part most of the coverage has focused on, works by annotating HTML forms with machine-readable descriptions. You add attributes to your form and its fields — a tool name, a description, explanations of what each input means — so that an AI agent visiting your page can understand what the form does and how to interact with it correctly.
This is structurally the same thing browser autofill has been doing since the early 2000s. Autofill infers field purpose from labels, name attributes and element IDs — it guesses that a field called "email" probably wants an email address, that a field labelled "postcode" probably wants a postcode. WebMCP makes that inference explicit rather than guessed, with structured annotations rather than heuristics.
The article that introduced most people to WebMCP draws the comparison to schema markup — and it is a fair analogy. You are annotating what already exists so a new class of reader can understand it. Schema markup was also called transformative when it arrived. Some of it was. A significant portion has since been deprecated, ignored by the systems it was meant to signal, or absorbed into practices that barely acknowledge it. FAQ rich results — also covered in the same publication on the same day — were just discontinued.
Where it does get genuinely interesting
The imperative API is a different matter. Rather than annotating existing forms, it allows you to register tools directly in JavaScript — defining what your site can do, what information is needed, and what the action produces. The tools available on a page can change based on state. A search produces results. Selecting a result surfaces a booking option. Confirming the booking completes it. The agent moves through a structured flow without having to guess what each step means.
The toolautosubmit attribute is the part worth paying attention to —
a boolean that allows an agent to complete and submit a form on the user's
behalf without an explicit confirmation step. For a low-stakes action,
that is a genuine convenience. For anything involving commitment —
money, time, preference — the question of what "on behalf of" actually
means becomes worth examining.
There is a less discussed implication here. The same structured annotation
that makes legitimate agent interaction more reliable makes malicious agent
interaction more reliable too. WebMCP makes forms machine-readable by design.
A compromised agent, or one operating with stolen credentials, now has a
structured predictable interface to work with rather than having to infer
field purpose from labels and IDs. Credential stuffing at scale becomes
more efficient. Automated payment fraud through checkout flows with
toolautosubmit enabled becomes more structured. The spec
notes that the attribute should only be used where actions are low-risk
and reversible — but that is guidance not enforcement. Implementation
is at the developer's discretion and the coverage has been almost
entirely enthusiastic without this side of it being mentioned once.
This is not an argument against WebMCP. It is an observation that any technology which reduces friction for legitimate users also reduces friction for illegitimate ones — and that the fraud and security implications deserve at least as much attention as the optimisation opportunities.
The holiday problem
The article uses a trust adoption curve to argue that agentic autonomy will follow the same path as online shopping: scepticism, reluctant adoption, dependency. The examples move from entering a card number online to letting an agent book a family holiday and drive autonomously to Disney World.
The comparison does not quite hold. Entering a card number is a single, confirmable step. Booking a holiday involves dates, budgets, travel companions, flexibility, preferences, trade-offs — a series of decisions that are genuinely yours to make and that have real consequences if made incorrectly. The trust gradient between "autofill my postcode" and "book four flights without asking me first" is not linear. There is a qualitative difference between a system that presents options you confirm and one that commits on your behalf.
That does not mean autonomous agents will not get there. It means the adoption curve is not a straight line from credit card to holiday, and that the category of decisions people are comfortable delegating is likely to remain narrower and more specific than the vision suggests — at least for longer than the article implies.
What this has to do with SEO
This is the question the article frames but does not directly answer. The honest answer is: less than the framing suggests.
WebMCP helps an AI agent interact with your site once it has already arrived. It makes form completion more reliable, more structured, less likely to fail when the UI changes. For sites where AI agents are completing actions on behalf of users — booking systems, ordering platforms, service enquiries — that is genuinely useful.
But it does nothing about discovery. An AI agent still needs to find your
site before it can interact with it. It still needs a reason to navigate
there rather than to a competitor. The content that establishes relevance,
the authority signals that establish trust, the technical fundamentals
that allow crawlers to understand what a site is about — none of that
changes because your contact form has a tooldescription attribute.
WebMCP is a conversion layer. It sits at the end of the journey, after discovery has already happened. The article frames it as a discovery revolution — co-authoring the next chapter of how things get found. But the discovery question is answered upstream, by the same signals that have always mattered: content, authority, crawlability, relevance.
Implement WebMCP if your site has forms that AI agents are likely to interact with. Understand the imperative API if you are building multi-step flows. But the sites that will be discovered by the AI agents that WebMCP is designed to help will be found because of SEO fundamentals — not because of the annotations on their booking forms.
While we are here — llms.txt
Shopify has recently rolled out llms.txt to all stores — quietly, with no public announcement, and apparently still in early testing given how bare bones the default file actually is. The timing is notable. The practical significance is less clear.
llms.txt is a proposed standard — a markdown file placed at your domain root that gives AI systems a structured overview of your site's content. The idea, proposed by Jeremy Howard in September 2024, was originally designed for developer documentation and API reference sites where context windows fill up quickly with HTML noise. A clean markdown file pointing to the most relevant pages is genuinely useful there. Cursor, GitHub Copilot and similar coding assistants fetch it routinely.
For most websites — including e-commerce stores — the evidence is rather less compelling. Out of 62,100 AI bot requests tracked across one study, 84 went to llms.txt. That is 0.1%. A 300,000-domain study found no statistically significant correlation between having the file and receiving more AI citations. The file performed at the level of a forgotten PDF in an assets folder.
Google's position is unambiguous. Gary Illyes confirmed in July 2025 that Google does not support llms.txt and has no plans to — and John Mueller compared it to the discredited keywords meta tag that search engines have been ignoring for over a decade. No major AI provider — OpenAI, Google, Anthropic, Meta, Mistral — has publicly committed to reading or acting on the file in production systems.
The Shopify angle is interesting precisely because of what it reveals. Shopify has not publicly announced the addition and there is no documentation about how to modify the file — suggesting it is still in early testing. The default output is bare bones: links to the collection page, the search page, store contact information. Not the curated, structured, AI-optimised resource that the coverage suggests. Shopify has implemented a file that its own platform's most-used search engine has explicitly said it does not use.
The honest position: llms.txt has a legitimate use case for developer documentation and agent-facing tooling. For everything else, the data does not support the hype. Implement it if you have the five minutes it takes and it makes you feel like the bases are covered. Do not implement it instead of the things that are confirmed to matter — crawlability, content quality, technical foundations, authority. Those have not changed. They will not be replaced by a markdown file in your root directory.
The broader pattern
None of this is an argument against WebMCP. The spec is real, the co-authorship from Google and Microsoft is meaningful, and the imperative API represents a genuine shift in how sites can structure their interactions with automated systems. Early implementation when the barrier is low and the spec is still forming is a reasonable bet.
The argument is against the framing. Every genuine advancement in search infrastructure arrives alongside a wave of coverage that presents it as the thing that changes everything — the end of the previous model, the beginning of a new one. Sometimes that is accurate. SSL mattered. Mobile optimisation mattered. The shift to entity-based understanding mattered.
Most of the time it is not accurate in the way or at the speed the coverage suggests. Google Authorship did not reshape search. FAQ rich results, much-implemented and much-optimised for, were deprecated last week. The pattern of adoption, overpromise, partial delivery and eventual normalisation is consistent enough to warrant a degree of calibration before any new spec gets the game-changer label.
WebMCP is worth understanding. The declarative API is better autofill with structured annotations. The imperative API is something more interesting. The fundamentals of being found, crawled and understood are unchanged. The latest acronym still does not mean sustainable growth or success.