A marketing lead and an ops lead land in the same Slack thread with the same three letters. Marketing wants to know whether an in-browser agent can already search the catalogue and fill a cart. Ops wants Claude to answer yesterday's order count and, if the answer looks clean, tidy a leftover discount code.
Both people call the work MCP. Those are two sessions, two write surfaces, and two first tickets. Enable the wrong door first and you either spend a week testing a storefront contract most shoppers still cannot invoke, or you hand a staff assistant production keys before anyone has named who may approve a write.
Shopify WebMCP matters when the shopper holds the tab and the job is catalogue, cart, policy, or checkout navigation in that session. The Claude admin connector matters when a staff member holds Claude and the job is live admin data. Sequence them from the session owner and the data each surface can change.
Introduction
This article teaches you to sequence whether shopper-tab WebMCP or staff Claude admin access should go live first. The in-tab tool map and theme contract test belong in Shopify WebMCP: What In-Browser AI Agents Can Do on Your Store. Isolation patterns for admin writes belong in How to Keep the Shopify Claude Connector Away from Production Data.
Community traffic still folds several doors into one story. Partners already split a front-end Claude review of the public site from any request for admin access. Merchants who added llms.txt or noticed UCP and MCP endpoints then blame that bundle for traffic they cannot attribute. Off-site catalogue syndication is a third discovery path, covered in Shopify AI product discovery: UCP catalog and data readiness. This piece stays on the first-choice question: WebMCP versus the official Claude connector.
Install steps and permission screens for the connector stay in Shopify Claude Connector App: Setup, Permissions, and Risks. Skip another setup walkthrough when the only decision is which door opens first.
Name who holds the session
The first filter is the person sitting in front of the glass, because each surface only works for that person.
Shopify documents WebMCP tools for agents that shoppers bring into the storefront tab. Catalogue tools read through the Storefront API. Cart tools call the same Shopify.actions surface apps already use. Checkout and account tools move that live session. Everything the agent does happens in the tab the shopper is looking at.
The official Claude connector sits on the other side of the counter. A staff member opens Claude, authenticates a store, and asks operational questions against admin data. Writes, when they exist, wait for a confirmation and then apply to the connected store. There is no shopper in that loop, and there is no cart drawer for a customer to watch.
If you cannot name the session owner in one sentence, you do not have a first ticket yet. "We want AI on Shopify" is a budget line. "The shopper's agent should add the navy hoodie in size M" is a WebMCP job. "Ops should ask Claude for yesterday's refund count" is a connector job.
A third owner shows up in the same meetings and still sits outside this choice. Sidekick lives in admin as Shopify's own assistant, with a different training loop, as Shopify Sidekick's continual learning flywheel describes. Remote Storefront MCP and UCP catalog endpoints serve agents that never load your theme. Keep those names on a parking list so they stop stealing the first decision.
Who holds the session
Name the first job the team wants done
Once the owner is named, write the first job as a verb plus an artifact. Vague briefs create duplicate work because both surfaces can "search products" in conversation while doing different things in the system.
WebMCP jobs look like this:
- Search the live catalogue and land the shopper on a product or collection.
- Select a variant the theme can actually honour.
- Add, change, or empty a line in the cart the shopper can see.
- Answer a returns or shipping question from your own policy pages.
- Take a non-empty cart to hosted checkout, where the shopper still pays.
Claude connector jobs look like this:
- Report yesterday's orders, a low-stock list, or a campaign code status.
- Explain a refund pattern from live order data.
- Propose a price or discount change that a human must still approve.
- Draft an admin task that still needs a person who knows your custom apps.
If the first job is a storefront walk-through with no staff credentials, WebMCP is the door even when the person asking works in marketing. If the first job needs customer records, inventory ledgers, or write confirmations, the connector is the door even when someone used the word "agent" in the brief.
A useful stress test: could the work finish if Claude never opened, or if the shopper never opened an in-tab agent? The path that still has a job after that test is the one you sequence first.
Map the data each surface can change
Risk follows the data, not the acronym.
WebMCP can change the shopper's cart and can navigate the shopper to checkout or order history. update_cart may refuse an ambiguous request and return options instead of guessing a line. proceed_to_checkout checks that the cart is not empty. manage_orders sends a logged-out shopper through login first. Shopify's published tool list does not include a tool that charges a card or creates an irreversible order from the agent alone. The shopper still finishes payment.
The practical WebMCP failure is a theme that already left the supportable path. Custom add-to-cart that never calls Shopify.actions, or swatches that paint a selected state without writing the variant id, will look decisive to a human and stall or mis-select for an agent. That contract test lives in the WebMCP article and in Shopify theme customisation limits. Catalogue titles, availability, and empty policy HTML become the agent's voice whether or not the theme is clean.
The Claude connector can read live orders, products, customers, inventory, and analytics, and can apply approved writes to that same store. Shopify does not ship a sandbox, a staging toggle, or a dry-run mode for the official connector. An approved price or discount change shows on the next storefront load. Coarse scopes are hard to narrow later without uninstalling. Customer data also enters Anthropic's context under their privacy policy, which is a different conversation from a shopper's own browser calling storefront tools.
| Criterion | Shopify WebMCP | Claude admin connector |
|---|---|---|
| Who holds the session | Shopper, in the storefront tab | Staff member, in Claude |
| Where it runs | Liquid storefront (Hydrogen developer preview) | Connected Shopify admin via Claude |
| First useful job | Search, variant, cart, policy, checkout handoff | Operational Q&A and confirmed admin writes |
| What it can change | The shopper's live cart and navigation | Live admin records you authorised |
| Payment | Shopper still pays in hosted checkout | No customer checkout in this session |
| Default risk | Theme and catalogue contract the agent inherits | Production writes and coarse admin scopes |
| Install burden | Already on hosted Liquid; client support still limited | Optional connector install and permission review |
| Choose this first when | The first job is an in-tab shopping request | The first job is a staff ops question on live data |
If the data in the first job is a cart line the shopper can undo, WebMCP's risk is recoverable in the same tab. If the data is a price, a discount code, or a customer record, the connector's risk is a production change with no built-in rollback. That difference is why "turn on both and see" is a sequencing failure, not a speed play.
Choose which surface goes live first
Write the sequence as a one-page brief the two Slack owners can share, using four fields: session owner (shopper in the tab, or staff in Claude); first job (one verb and one artifact, in the present tense); data that can change (cart and navigation, or live admin records); and first surface (WebMCP, the Claude connector, or a parked third door).
Then add the gate that belongs to that surface. For WebMCP, the gate is a four-template walk (homepage, collection, product, cart) with search, variant, add, policy, and checkout handoff, logged where the UI and the tool disagree. For the connector, the gate is a named approver for writes, plus a decision on whether production is even the right store. The isolation article covers development-store mirrors, scoped tokens, and a custom Admin MCP server when the team still needs to learn prompts.
Run the WebMCP walk now when the first job is in-tab shopping, even while Chromium origin trials remain limited, because the tools are already on Liquid. Most buyers still lack a client that can call them, and the walk still tells you whether a later client will inherit an honest cart and variant path.
Refuse a connector write on production while the first job is staff Q&A, even if the catalogue still needs cleanup, because read queries can leak customer data into a chat transcript and approved writes can land on the live storefront. Sequence access after you name who may approve, and after you decide whether a development store should take the first month of experiments.
Running both in the same sprint is valid when marketing owns the WebMCP walk and ops owns connector permissions as two tickets with two done definitions. Combining them into one "AI enablement" epic hides the gate that actually blocks go-live.
Recommendation by scenario
Scenario A: leadership saw a post about agents shopping "directly"
Start with WebMCP. Confirm you are talking about the in-tab door, not ChatGPT Shopping, not UCP catalog rank, and not a third-party widget that borrowed the WebMCP name. Run the contract test. Leave traffic forecasts for when a stable client exists. If the theme's cart already ignores standard actions, the first spend is theme recovery, not a connector install.
Scenario B: ops wants Claude to replace a Monday CSV export
Start with the Claude connector, keep the first week read-heavy, and name the person who may confirm a write. If the team wants to iterate on prompts or bulk edits, move that work off production using the isolation patterns rather than practising on live prices. The July setup post covers the install; this article stops at the sequencing call.
Scenario C: both Slack messages arrived in the same hour
Split the work so marketing owns the WebMCP walk with a theme owner while ops owns a connector permission review with a store-access owner. Share the four-field brief so nobody "helps" by enabling the other door as a shortcut, and reconvene only to park third doors such as Sidekick, Storefront MCP sunsets, and UCP feeds.
Scenario D: a developer is counting down a remote MCP cutoff
That ticket is Storefront MCP or UCP, not WebMCP versus Claude. Do not use this framework to sequence an admin connector against an in-tab tool when the actual risk is a remote cart tool sunset. Send the developer back to the endpoint they named.
Scenario E: legal or a regulated category is in the thread
Default the first live surface away from customer records in a staff chat. WebMCP still exposes whatever the Storefront API and policy pages already publish. The connector adds admin-scoped customer and order data to a third-party model context. Sequence a scoped or development-store pattern before anyone treats production Claude as the daily ops desk.
Conclusion
You can now sequence Shopify WebMCP against the Claude admin connector from three facts: who holds the session, which job comes first, and which data that surface can change. WebMCP is the shopper-tab door for catalogue, cart, and checkout handoff. The Claude connector is the staff door for live admin questions and confirmed writes. Mixing those doors into one MCP project is how teams test the wrong contract or approve the wrong write.
If you want that sequence written against your theme actions and your admin access model, book a Shopify stack assessment with oContis Studio. Shopify theme development is the recovery path when custom cart and variant code will fail an in-tab agent. Shopify stack audit is the better first call when staff AI access is landing on a catalogue and app graph nobody has mapped.
