Shopify’s current agent documentation separates product discovery, cart work, checkout work and orders. Cart MCP is the flexible workspace for changing selections. Checkout MCP handles a buyer who is closer to purchase. Authentication determines whether the agent can complete checkout or must hand control to a storefront.
Key takeaways
- Use Cart MCP while products, quantities or context are still changing.
- Convert a cart with
create_checkout(cart_id)when purchase intent is clear.- Checkout tools require authentication or a signed request.
- Direct completion requires a Token credential with permission.
What is the end-to-end sequence?
The documented flow begins with authentication and catalog discovery. The agent can create a cart, update it as the buyer refines the request, and then create a checkout from that cart. The final step is either a storefront handoff or complete_checkout when the agent has the required Token permission.
identify agent
↓
search or look up product
↓
create_cart
↓
update_cart as buyer choices change
↓
create_checkout(cart_id)
↓
update_checkout if required
↓
storefront handoff OR authorized complete_checkout
This sequence uses Shopify’s named MCP tools. It should not be replaced by invented generic endpoints.
Why should cart work stay out of checkout?
Shopify states that Checkout MCP is rate-limited more strictly than Cart MCP at every identity tier. A cart is therefore the appropriate place to add or remove items, refine buyer context and estimate totals. Moving to checkout too early creates avoidable restricted calls and can leave more abandoned checkout state.
Use an explicit transition rule, such as buyer confirmation of the selected variants and quantities. That is an application rule, not a universal Shopify requirement, so document it as local behavior.
What must be preserved when creating checkout?
Before calling create_checkout(cart_id), store the cart identifier and the selected product variants. After the call, treat the returned checkout identifier as a new resource. Do not assume that a local cart object and the checkout response have identical fields or status semantics.
Validate server responses at every step. If a tool reports missing buyer or fulfillment information, request only the needed input and update the checkout using the documented tool. Do not map every outcome to a generic 500 error.
When can the agent complete checkout?
The Token tier can call complete_checkout only when the token has been granted the required permission. Signed and Anonymous agents cannot use that operation. They can still build the purchase context and hand the buyer to the merchant storefront.
This boundary should appear in product requirements and tests. A polished conversation does not grant payment authority.
How should order updates work?
Once an order exists, Shopify positions order webhooks as the mechanism for proactive lifecycle updates. get_order is for buyer-initiated reads and recovery from missed webhook events. It requires a Token credential with the relevant scope and is limited to orders placed through the agent.
Do not poll order state continuously when a webhook can provide the update.
Reproducible integration test
Run the flow against a controlled test product and save redacted tool inputs and outputs:
- Authenticate at the intended tier.
- Search and select one exact variant.
- Create a cart and record its identifier.
- Change quantity and verify the updated totals.
- Create checkout from the cart identifier.
- Supply any required buyer or fulfillment data.
- Verify that unauthorized completion is rejected.
- In an authorized Token test, complete only in an approved test environment.
- Confirm order access and webhook behavior separately.
The resulting trace is an original implementation asset. Remove buyer data, credentials and tokens before publishing any example.
Primary sources and review date
- Shopify carts and checkout for agents, reviewed 2026-08-12.
- Shopify agent quickstart, reviewed 2026-08-12.
- Shopify auth and rate limiting for agents, reviewed 2026-08-12.