Written by Jeremy Souffir Founder, JTS Tech Services
The short version. Until now, an AI agent trying to do something on your website had to work the way a very determined stranger would: look at the page, work out which things are clickable, guess what they do, click one, see what happened. WebMCP changes the premise. It is a proposed web standard, currently running as an origin trial in Chrome, that lets a page hand the agent an actual list of things it can do, with proper inputs — read the amount due, list the available payment methods, select one, fill these fields, submit. Stripe has now implemented it across its checkout surfaces, and published its own measurements against ordinary browser automation: 42% fewer tokens, 38% fewer tool calls, and a checkout completed 39% faster. Those are vendor numbers on a vendor feature and we will treat them as such. But the mechanism is real, it is documented by Google as well as Stripe, and the part worth your attention is not the speed. It is that WebMCP works page by page, only where someone has chosen to implement it. Stripe has done the payment step on your behalf. Everything a customer's agent has to get through before it reaches that step is still yours, still silent, and still being guessed at.
What is WebMCP, in one paragraph?
It is a way for a web page to expose named functions to an agent running in the browser, in the same spirit as the Model Context Protocol that connects assistants to backend systems, but living in the page itself. Google's documentation describes two ways to declare them: an imperative JavaScript API for defining tools over forms, navigation and your own custom functions, and a declarative option that annotates ordinary HTML form elements so you get tools without writing much code at all. It is a progressive enhancement, which is the important architectural detail — a page that declares no tools keeps working exactly as it does today, and nothing breaks for human visitors. The status is early and everyone involved says so: it is a proposed standard under active discussion, available as an origin trial from Chrome 149 and behind a flag for local development, and Stripe labels its own implementation an experimental capability whose tool schemas may change.
What did Stripe actually ship, and what do the numbers mean?
- It covers the Stripe-controlled checkout surfaces. Stripe's documentation lists full-page Checkout, the embedded form, Elements, and the hosted invoice page. If your payments run through one of those, this arrived without you deploying anything.
- The tools are narrow and sensible. Read the checkout or invoice context such as the amount due and the available payment methods; select a payment method; fill form fields; and, where Stripe controls the submit action, start the payment submission. That is a payment flow, not a shopping flow.
- The tools change as the flow changes. Stripe calls this progressive tool disclosure: the page exposes only what is relevant to its current state, and choosing a payment method can change which fields the agent must collect. Its guidance to agent developers is explicit — do not hard-code tool names or schemas, discover them at runtime, and re-discover after any action that could change the form.
- Stripe's own measured gains. Against a baseline of ordinary browser automation that averaged roughly 1.8 million tokens per transaction and about 39 tool invocations per run, Stripe reports 42% fewer tokens, 38% fewer tool calls, and checkout completed 39% faster, which it describes as roughly a minute of wall-clock time saved per purchase.
- There is a documented fallback. If the tool an agent needs is not there, Stripe tells it to drop back to standard browser automation. Nothing about WebMCP removes the old path; it just makes the old path the slow one.
- The reach is reported rather than announced. Trade coverage of September's launches says Stripe switched WebMCP on across 7.8 million businesses. We could not find that figure in anything Stripe published, so treat it as the trade press's number, not Stripe's. The argument below does not depend on it.
What has actually shipped, and what is still a proposal
Two different things are easy to conflate here, and the distinction decides how much you should spend. The proposal is WebMCP itself: a candidate web standard, in origin trial in one browser, with schemas and APIs that its own documentation says can change. Nobody should be rebuilding a storefront around that this quarter. The shipped thing is narrower and more solid: Stripe has implemented the current draft on its checkout surfaces, so for that one step the benefit lands without you writing code, and it degrades cleanly to browser automation where the standard is absent. As for the performance figures, they were produced by Stripe measuring a Stripe feature, against a baseline Stripe chose, and published on Stripe's engineering blog. That is not a reason to dismiss them — the direction is exactly what you would predict from first principles, because calling a named function with typed inputs is obviously cheaper than inferring one from rendered markup. It is a reason not to quote 39% to your board as though it were an industry benchmark. The honest summary is that the mechanism is sound and early, the numbers are plausible and interested, and the strategic point stands whatever the real figures turn out to be.
Why is this different from an agent reading your page?
We wrote two days ago about how agents read sites today: through the accessibility tree, the browser's structural model of what each element is and what it is called, which is the same thing a screen reader consumes. That is inference. It is the agent reconstructing your intent from the shape of your markup, and it fails in the ways inference fails — an unnamed button is not a mysterious button, it is nothing at all. WebMCP is the opposite posture. Instead of the agent working out that this element is probably the quantity stepper, the page says: there is a tool called set quantity, it takes an integer, here is its current value. One of those is archaeology and the other is an API.
That difference has a consequence people miss. Inference degrades gradually and invisibly: a slightly worse page means a slightly less reliable agent, and you never hear about it. A declared tool either exists or it does not, and when it exists the agent stops guessing entirely for that action. This is why the two things are complementary rather than competing, and why nobody should read this post as a reason to stop caring about semantic markup. The accessibility tree is the floor, and it is the floor for every page you will ever have, in every browser, today. WebMCP is a ceiling you can raise in a few specific places where the guessing is most expensive. Doing the ceiling while the floor is missing would be a strange order of operations, and it is the order we expect a lot of teams to attempt.
So where is the gap, exactly?
Here is the detail that turns this from interesting news into a to-do list. Chrome's documentation states plainly that there is no automatic discovery mechanism across the web: a client finds out which tools exist by visiting the page. There is no registry, no crawl, no equivalent of a sitemap that advertises your capabilities in advance. Tools are a property of the page the agent is standing on, and of nothing else.
- The coverage is one step out of many. A purchase involves finding the product, choosing a variant, checking stock and delivery, adding to a cart, reviewing it, and then paying. Stripe's tools begin at the paying part. Everything before it is your application, and your application has declared nothing.
- The hardest steps are the ones still unassisted. Payment forms are, relatively speaking, the most standardised and predictable part of any store. Variant selection is where agents genuinely struggle: colour and size and length interacting, options that appear and vanish, stock that depends on the combination, controls built as styled divs because the design called for it.
- It is per-origin and per-page, so it is on you. Because there is no cross-site discovery, no platform can declare your tools for you beyond the surfaces it renders itself. Stripe can do its checkout because Stripe's code draws that page. Nobody else's code draws your product page.
- The upside of no discovery is no penalty. There is no leaderboard, no index and nothing that ranks you for participating or punishes you for sitting it out. That cuts against urgency, and honestly it should: this is not a land grab and there is no first-mover advantage to buy.
- The fallback means the downside is bounded too. An agent that finds no tools uses browser automation, which is what it does everywhere today. Declining to implement WebMCP leaves you exactly where you are. It does not push you backwards.
Two ways to get this wrong this quarter
The first is to treat a Chrome origin trial as a deadline. We have watched a year of AI-commerce announcements get converted into urgent roadmap items by the simple mechanism of a vendor blog post existing, and this one has better credentials than most, which makes it more tempting rather than less. It is one browser, behind a trial, on a standard whose schemas its own authors say will change. A store that spends this quarter instrumenting its catalogue with an experimental API, while its product pages still ship prices that only appear after JavaScript runs, has optimised the wrong layer and will get to do the work twice when the draft moves. The second mistake is the lazier one and probably more common: reading that Stripe handled it and filing the whole subject as done. Stripe handled the payment step, which was never the part where agents were failing. If a customer's assistant cannot establish that the large is in stock in navy, it will never reach a Stripe page to benefit from any of this, and you will not see a failed checkout in your analytics because there was no checkout. The abandoned errand leaves no trace. Neither mistake is dramatic, which is exactly why both are easy to make: one buys a solution to a problem you do not have yet, the other assumes someone else bought it for you.
What is actually worth doing now?
- Find out whether your payments already benefit. If you are on Stripe Checkout, Elements, the embedded form or hosted invoices, this step is done. If you are on a different processor or a custom payment page, it is not, and that is worth a question to your provider rather than a project of your own.
- Watch a real agent attempt a real purchase on your store. This is the highest-value hour in this entire post and it costs nothing but the hour. Give a browsing agent an errand with a variant in it: buy this in large, in navy, delivered to this postcode. Watch precisely where it stalls. That is your list, in priority order, derived from your own site rather than from anyone's blog.
- Fix the semantic layer first, because it pays off everywhere. Native buttons and links rather than styled divs, form fields tied to their labels, prices and stock in the served HTML, and facts that matter not locked inside images. This is the floor, it works in every browser for every agent today, and no standards process can obsolete it.
- If you want to experiment, pick the step where guessing costs most. For most stores that is variant and option selection, not checkout. A declarative annotation on an existing form is a small, reversible change and a reasonable way to learn what this actually does.
- Keep it behind a flag and expect to redo it. Stripe's guidance to tool consumers — discover at runtime, hard-code nothing, re-check after every state change — is equally good guidance for a tool publisher. Anything you build against a draft standard should be cheap to throw away.
- Do not let this become a payments project. The people who need to be in the room are whoever owns the product page and the catalogue, because that is where the unassisted steps live. Routing this to whoever owns checkout guarantees a report that says everything is fine.
The reassuring part
You have more time than the announcement cadence suggests, and that is not complacency talking, it is the demand data. Checkout.com's June report found that just 3% of transactions currently involve AI agents, against 89% of merchants actively preparing for them — which is to say the infrastructure is running well ahead of anybody using it. The same research found 27% of consumers trust no organisation at all to operate a shopping agent on their behalf and 24% say they will never delegate a purchase to one, while those who are willing want spending caps, instant revocation and easy cancellation before they will start. Forrester, looking at the same market, reported that adoption of in-chat instant checkout stayed low and flat for its whole life, and that a large retailer's pilot converted roughly three times worse inside the chat window than when customers clicked out to the store. The constraint on agentic commerce right now is trust and permissioning, not whether your variant picker exposes a tool. That is genuinely good news for anyone who felt behind, because it means the sensible plan is the unglamorous one: get the semantic layer right, because it helps every agent and every customer today and cannot be deprecated, and treat the experimental standards as something to follow rather than something to chase. The teams that will look prescient in two years are not the ones who implemented the September draft. They are the ones whose product data was correct and whose pages said what they meant.
Where we fit
The reason this particular gap persists is that it falls between two teams who each have a defensible reason to think it is not theirs. Checkout belongs to whoever owns payments, and payments will correctly report that Stripe has this covered. The product page belongs to whoever owns the storefront, and they are measured on what human visitors do, which still looks fine, because the errands that failed never appeared as sessions with intent. So the steps where agents actually break — the variant matrix, the stock logic, the filter controls, the facts that live only in a banner image — sit in nobody's remit, and the only signal that anything is wrong is an absence you cannot see in a dashboard. That is the work our free AI Shopping Visibility audit is pointed at. We put real browsing agents through the errands your customers delegate, on your live site, and report where each one stops and why: which controls have no accessible name, which prices and availability are invisible until JavaScript runs, which variant combinations cannot be resolved from the page at all, and which of those failures sit between a ready buyer and your checkout. You get it back as a prioritised list with the specific fix for each item, ordered by what it costs you rather than by how hard it is. Retaining us for the follow-through is optional and often unnecessary — a good number of the fixes are small enough for your own developers once someone has pointed at them. What you cannot easily do in-house is the pointing, because it requires driving the agents and knowing which failures are yours to fix and which are the standard's problem to solve later. That judgement is the thing we would actually be selling you, and on this subject, in this quarter, most of it comes out as permission to not bother yet.
Sources
- Stripe — Use WebMCP to complete Stripe payments in a browser (the primary source for what shipped: the supported Checkout surfaces, the available tools, the runtime-discovery guidance, the browser-automation fallback, and Stripe's own labelling of the capability as experimental)
- Chrome for Developers — WebMCP (the standard itself: the imperative and declarative ways to declare tools, progressive-enhancement behaviour, origin trial from Chrome 149, and the statement that there is no automatic cross-web discovery mechanism)
- Stripe — How Stripe is designing Checkout for AI agents (Stripe's own engineering measurements: 42% fewer tokens, 38% fewer tool calls and checkout 39% faster, with the baselines of roughly 1.8M tokens and about 39 tool calls per run, plus the progressive tool disclosure design)
- Checkout.com — Consumer demand for AI shopping is forming fast but trust for agentic commerce is still catching up (the June 2026 report: 3% of transactions involving agents, 89% of merchants preparing, 72% expecting consumers to move faster than they can support, 27% trusting no operator, 24% who will never delegate, and the spending-cap, revocation and cancellation figures)
- Forrester — Agentic payments in B2C commerce: where we are now (Lily Varon, April 2026, for in-chat instant checkout adoption staying low and flat, and the retailer pilot converting roughly three times worse inside the chat window than when customers clicked through)
- Stripe — Agentic commerce (the surrounding documentation set, for how WebMCP sits alongside the Agentic Commerce Protocol and the Universal Commerce Protocol rather than replacing either)
- Yahoo Finance — The trust paradox: agent payment infrastructure is outpacing consumer readiness (the trade coverage of September's launches, and the only place we found the claim that WebMCP was switched on across 7.8 million businesses — a figure we attribute to this coverage rather than to Stripe)
- JTS Tech Services — AI agents read your site through the same structure a screen reader uses (our post from two days ago on how agents cope when nothing is declared; this is the same question answered from the other side)
