When you build a store on our fashion starter, it gets WebMCP support as part of the package: the tools are registered, the boundary is defined, and the storefront exposes the actions an agent can safely call. We added that surface earlier this year, when the standard was still a Chrome origin trial. This week ChatGPT shipped site tools in its desktop app, and storefronts running the starter were ready for it without a rewrite or a new integration.
We covered the Shopify default-on move in a separate post. This one is about the storefront that ships with the starter, and what it means now that a real agent can drive the page.
What ChatGPT site tools change for a storefront
ChatGPT’s desktop app can now use a website’s WebMCP tools directly inside its built-in browser. The agent and the shopper see the same live page and the same signed-in session. For a store running our starter, that means a ChatGPT Work user can search the catalog, move through the store, and manage a cart, all from inside the agent, without a separate plugin or backend server.
Here is that flow from a storefront running the starter:
The agent does not get a private API. It gets the storefront’s own logic, exposed as a small set of named tools. That is a change in kind, not a faster way to scrape a catalog.
The useful part is not a chat box bolted onto the page. It is the storefront exposing bounded actions that the agent calls through the same frontend logic a click would.
What your storefront gets without extra work
The tools are registered on document.modelContext, the same API that ChatGPT expects. A storefront from the starter exposes a small, deliberate set:
products.search(read-only)navigation.toProduct,navigation.toCartcart.manage,cart.applyPromotion,cart.removePromotioncheckout.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 preparing checkout, not completing it. That split is the whole point: the agent assists the shopper; it does not become the cashier.
The boundary is in the tool design, not in a checkpoint bolted on afterward. ChatGPT reviews every tool call before it runs, and the write set stops well before anything transactional. So the question for any store exposing agent tools is not whether to open the surface. It is what the right boundary is for a caller that is not a mouse.
Here is the decision you are actually making, even if it does not look like one yet. Once an agent is on the page, you choose which actions are safe to expose and build that boundary into the tool design, rather than hoping a generic safety layer catches the cases you didn’t think through.
What this does and does not mean for a shop
An honest limit: ChatGPT site tools need ChatGPT Work or Codex, the desktop app, and a supported model. Most end consumers cannot use this yet. So today this is a capability for a shop’s operators and pro users, not a replacement for the human checkout.
That is fine. The point of building the surface into the starter was never to replace the shopper. It was to make the storefront legible to an agent that is already on the page, and to decide up front which actions are safe to expose.
For a shop running the starter, getting this live is short: merge the branch, set the env flag at build time, and verify discovery in the ChatGPT desktop browser. The surface ships with the starter, but it is not a feature you switch on and forget. The verification is worth doing deliberately, because the tool list the agent sees is the surface a shopper can now drive without touching the storefront controls. The interesting work is upstream, in the tool set you choose to register and the boundary you put around it. Shipping the integration does not finish any of that.
