WebMCP and the e-commerce spec I am not sure I know how to write
Google slipped WebMCP into the Chrome roadmap on Tuesday. The audience for integration specs shifted from a human developer to an agent, and most of what I know how to write goes to the wrong place.
I have spent a chunk of my career writing integration specs. The first one I remember clearly was at Metro Cash & Carry around 2014, a partner-ordering flow with field-level validation rules, error codes, retry semantics. I wrote it for a human who would open Postman, hit the endpoint, read my doc, and write a client.
That template does not fit what Google slipped into the Chrome roadmap on Tuesday. The mismatch is not catastrophic. It looks more like my first 20-page spec at Axioma, where the document was technically correct but written for the wrong reader. The audience has shifted from a developer working through prose to an agent reading a function signature, and most of what I know how to write goes to the wrong place.
WebMCP is “a proposed open web standard that allows developers to expose structured tools…so browser-based AI agents can execute complex tasks with greater speed, reliability, and precision” (source). The origin trial starts in Chrome 149 (source). Plain version: a checkout button, search box, subscribe-and-save toggle, coupon entry, refund request each get a machine-readable wrapper. The agent calls the function the site exposes, no page render needed.
The list of brands already experimenting is what made me close my laptop for an hour: Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, Target (source).
That looks closer to a pilot wave than a research preview.
Mustafa Suleyman at Microsoft AI predicted earlier this year that “human-level performance on most, if not all professional tasks” was 12 to 18 months away (source), and three months later the same piece noted the take had not aged well. I am not predicting an agentic apocalypse for retail, just saying that analysts have new homework.
At Alfa-Bank I worked under Roman Oshurkevich, and I still owe most of my spec-writing discipline to him. He taught me to write specs a developer could implement without asking a single question. Forty million plus users sat on the other side of those documents, with regulatory consequences if a single field was ambiguous, so the instinct was to write everything down, including what any sober developer would call obvious. At Axioma that instinct broke. The setting was a flower exchange where bids cleared at five in the morning, and a missed second could mean a lost lot. A team lead named Ablyakim, whom I respected a lot, walked over to my desk in my first month and told me my spec was too detailed. The senior team there did not need a babysitter. They wanted the boundary specified and the rest left alone.
Coming back to WebMCP. An agent on the other end of the contract reads like neither of those two. Closer to a very confident developer who follows the contract exactly and never asks a clarifying question. The Alfa-Bank instinct fits better, but the artifact is not the same.
Human Consumer Agent Consumer
| |
v v
README + API Machine-readable intent contract
+ side effects
+ delegation boundaries
+ retry semantics
Granularity has to go up. A REST endpoint that exposes a basket and a /checkout POST was fine for a human integrator who would read your README first. The agent wants get_basket, apply_coupon, address_is_serviceable, place_order, each named for the intent and documented with the side effects it produces on the user’s account. The agent can guess at coarser tools and will. Guessing at scale is the failure mode the contract exists to remove.
The error contract has to communicate intent rather than just a status code. At Metro I once spent two weeks chasing a partner whose system retried a hard-validated request with a different payload every time, on the theory that “400 means bad input, try something else” (the partner did not call to ask. They never called). A poorly contracted agent behaves the same way, faster and across more endpoints. “Address not in serviceable region, do not retry with a different street” carries information that “400 Bad Request” cannot, and the agent needs the first.
Then there is consent, which I do not have a clean template for. An agent acting on a user’s behalf needs the site to tell it what it can do silently and what it must bounce back to its principal. The shape in my head looks roughly like four classes, each needing different language in the contract.
A one-shot purchase inside a stated budget can probably be silent. The user asked for a printer, the agent picked one, price within the cap. Proceed, log, summarize. The analyst’s work here is mostly the budget object and the summary schema.
Recurring charges are different. “Subscribe and save” is the same checkout button visually and a completely different financial commitment. The contract should mark recurring intent explicitly, with the agent required to surface the renewal cadence and cancellation path before confirming. At Alfa-Bank we treated recurring-debit flows as a regulated field, with mandatory disclosures rendered in a specific component because the legal team did not trust free-text rendering. The same instinct transfers here. The disclosure should be a structured field the agent re-presents to its principal verbatim, with summarization off the table.
PII to a third party is its own class. What is acceptable depends on the destination - an address handed to a known courier integration is one thing, a date of birth landing in a marketplace seller’s CRM is another conversation entirely. The contract has to enumerate which fields the function reads and where they actually travel, and the agent discloses the destination, not just the field.
Irreversible actions are the fourth. Refunds that consume a one-time credit, account closures, reviews posted under the user’s name, anything with no inverse function. Those need a confirmation token issued by the principal for that specific action, not a session-wide blanket. This is closer in spirit to a two-person rule. It probably belongs on the function description itself, since a policy footnote is too easy for the agent to skip past.
There is a structural question underneath all four classes that I have not figured out. Do the consent classes live inside the WebMCP description, where the agent reads them with the function signature, or in a separate policy document the agent has to consult? My current draft does both, which is probably wrong, but I would rather double-state than under-state while the trial is running.
How real is the production case? PwC and Anthropic announced last week that one client’s insurance underwriting cycles compressed from ten weeks to ten days using Claude, with delivery times cut by up to 70% across a portfolio of deployments, and PwC will train 30,000 staff on Claude (source). Underwriting is not e-commerce and one engagement is one data point, but the shape is recognizable: a workflow that used to be human-reads-packet, fills-form, routes-to-next-human becomes agent-calls-tool, escalates only when the contract says so.
I do not know how much of WebMCP survives the origin trial, whether Gemini in Chrome ships on the stated timeline, whether Shopify and Etsy keep the experiment past Q4. What I do know is that the contract layer is being drafted in public this week, on those nine platforms, and the people who write e-commerce integration specs have new homework regardless of how the trial concludes.
What I would actually like to hear from anyone already inside an agentic flow: where are you putting the consent classes, inside the function description or in a separate policy the agent has to consult? My draft does both and I am not happy with either.