We shipped the WebMCP fashion starter integration in April, when the standard was still a Chrome origin trial and no platform supported it by default. In August, Shopify turned it on for every Liquid storefront, with a changelog line that read “nothing to install or configure.” Being early on a web standard is usually a bet. This one paid off.
This post is about what we built, why we built it early, and why shops should put WebMCP on their roadmap now. Shopify is the proof that we were right, not the topic.
We argued in April that WebMCP is more than a chat widget. A page can expose structured actions that an agent can call directly, instead of an agent scraping the DOM and guessing what a button does. We did not want to wait for a platform to decide what that surface should be, so we built it into the starter.
What we shipped in April
The starter registers a small, deliberate set of tools: products.search (read-only), navigation.toProduct, navigation.toCart, cart.manage, cart.applyPromotion, cart.removePromotion, and checkout.prepare.
Only one tool reads. The rest write. None of them places an order or takes payment. The deepest action an agent can take is to prepare checkout, not to complete it, and cart writes require the shopper’s confirmation. That split is the point: the agent assists the shopper; it does not become the cashier.
The hard part of an agent surface is not the registration API. It is deciding what an agent is allowed to want: every tool you register is a promise about what the storefront can safely do for a caller that is not a mouse. The boundary is in the tool design, not in a checkpoint bolted on afterward: read-only tools, confirmed writes, a hard stop before anything transactional. It is least privilege, applied to agents. Everything runs on the shopper’s live session, and the tools call the same storefront actions a click would. It is not a parallel headless API.
We wrote separately about what this means now that ChatGPT can drive the storefront. This one is about the decision to build the surface early.
The platform default validated the bet
Shopify’s default-on is the interesting part. The tool set it pre-registered covers the standard flow: catalog search and browse, cart management, checkout, order management, and store policies. That is close to the surface we chose for the starter, which is a good sign that the industry is converging on the same shape.
Here is what nobody mentions until the default is live: the default does not make your store agent-ready; it makes it agent-exposed. The tools the platform ships cover the standard flow, and everything that makes your store actually yours (pricing rules, B2B terms, bundle logic) is invisible to the agent unless it runs through the same storefront actions a click would. The agent transacts the wrong version of your store, and you eat the difference. The default decides reach. The business logic decides whether an agent can actually transact your store.
The default ends where your business logic starts
Customer-specific pricing
A B2B store with customer-specific pricing. The agent sees the catalog price; the storefront calls the discount engine when a customer group is in the session; and the cart reflects the correct quantity. If your discount engine is an app that overrides the cart line item through app-driven cart rules, the agent calling update_cart will not invoke it. The agent transacts the wrong price. You eat the difference.
Bundles
A store with bundles. The agent sees a product page. The bundle configuration lives in a custom theme section or an app. The agent can call show_variant on each component, but the bundled SKU and the bundle price are not in the catalog the agent can see. The agent cannot place a bundle order. It becomes worse than the storefront for the products you sell most.
B2B approval chains
A store with B2B approval chains. The agent can place an order; the system can reject it for value or company policy; and the agent has no signal that approval was the reason. It retries, gets rejected again, and the shopper blames the platform.
The pattern repeats: a platform default covers the standard flow, and the store’s actual selling flow lives in the part the default does not see.
The agent surface comes without analytics
The day the default goes live, you have an agent API on your storefront that you never reviewed, never tested, never instrumented. An order can be placed by an agent, a logged-in customer, or a guest session, and the platform does not distinguish between them by default. Storefront analytics see a session; they do not see who was driving it. If you need to know whether an agent-driven order needs a different post-purchase flow, fraud screening, or reporting, that data is not in the order record.
The same applies to abuse. An agent that misuses a tool is a session that calls the tool; a misbehaving agent looks like fast traffic from a single session. None of it is visible as a separate class without instrumentation.
The platform default does not ship that visibility, and neither does a starter. Whoever runs the store builds it. The earlier the surface goes on the roadmap, the earlier that work gets planned instead of reacted to.
WebMCP is still early. Put it on the roadmap now
Honest limits: the WebMCP fashion starter is one implementation of a standard that is still a Chrome origin trial. ChatGPT’s site tools need the desktop app, a Work or Codex account, and a supported model. The typical shopper cannot drive a store this way yet, and the standard itself is still moving.
That is the wrong reason to wait. The platform default signals that agent-readiness has moved from research topic to infrastructure. The rule of thumb: adopt when the cost of waiting (inheriting a default that ignores your business logic) exceeds the cost of building a small, bounded surface now. For most stores that cross over, that crossover is closer than it looks. The stores that start now get to make the decisions: which parts of the store are reachable through standard behavior, which parts need their own tools, and where the write boundary sits. The stores that wait inherit the default, and the default ends where their business logic starts.
Here is the decision you are actually making, even if it does not look like one yet. You can put WebMCP on the roadmap now, while the surface area is small and you can design the boundary around your business logic, as we did with the fashion starter. Or you can wait for the next platform to flip the switch, and audit your custom logic for agent exposure while an agent is already transacting your store at the wrong price.
A two-engineer team can ship an agent surface that respects custom pricing. That is the work we did in April, and it is the work every shop will need to do once the default is live on their store.
