UCP Checker
Shopify's Storefront MCP After August 31: What Moved to UCP, and the One Tool Left Behind

Shopify's Storefront MCP After August 31: What Moved to UCP, and the One Tool Left Behind

On 24 June Shopify announced that the cart tools on its Storefront MCP server would be maintained until 31 August, and that agents should move to UCP-conforming Cart MCP tools instead. On 26 August a developer asked on Shopify's forum whether the old tools would actually stop responding or simply become unsupported. A member of Shopify's team replied the next day: the tools "are intended to be removed. They may not go away right away."

Our own agent runtime had been hearing about the deadline for two months by then. UCP Playground first received Shopify's notice in a tool result on 28 June, four days after the changelog.

It is now two weeks past the date. So we looked.

On 15 September we called both endpoints on seven large Shopify-hosted stores. On every one, the old server at /api/mcp now lists a single tool. The cart tools no longer appear in that list — but they still answer when called, each with a notice attached:

DEPRECATION NOTICE: This tool is served by the Storefront MCP server at /api/mcp and will no longer be accessible after August 31, 2026. Migrate to the UCP-conforming tools at /api/ucp/mcp.

This is a migration Shopify has run in two steps over five months, and it is worth laying out what has moved to UCP, what hasn't, and what an agent needs to do differently once it arrives.

Two steps, not one

Catalog went first. In April, Shopify's catalog tools on the Storefront MCP server moved to UCP shapes: search_shop_catalog became search_catalog, alongside lookup_catalog and get_product. Developers on the forum reported the old tool name failing, and on 22 April Shopify's team apologised for the disruption and confirmed that catalog queries had until 15 June to move to /api/ucp/mcp. The old name is gone: calling search_shop_catalog today returns Tool not found. The renamed search_catalog, though, never quite left the old server. Playground's agents were still getting answers from it, with a deprecation notice attached, through the end of July — and it still answers there today when called by name.

Cart went second. The 24 June changelog deprecated get_cart and update_cart on /api/mcp, with a maintenance window to 31 August, in favour of Cart MCP at /api/ucp/mcp — create_cart, get_cart, update_cart and cancel_cart, implementing the UCP cart capability.

On the UCP endpoint each store declares in its manifest, the same seven stores list thirteen tools: five for checkout, four for cart, get_order, and the three catalog tools. That is the whole shopping journey — find, cart, check out, look up the order — on one UCP-conforming server.

What our agents heard first

UCP Playground runs real agent sessions against real stores and records every tool result, so it heard the sunset before the listings changed.

The notice first came back in a tool result on 28 June. From the following week, nearly every Playground session on a Shopify store's old endpoint received it — roughly nine in ten, week after week, through July — across over 100 agent sessions on nearly 40 stores. Three details from those results are worth recording.

  • It was attached to everything. The June and July wording told agents to "migrate to the UCP-conforming Cart MCP tools", but it came back on catalog searches and product lookups as well as cart calls — and, for two days in late July, on the policies tool too.
  • The wording changed. By 11 August the notice had become generic — "Migrate to the UCP-conforming tools at /api/ucp/mcp" — which is the text the old server returns today.
  • We stopped hearing it on 31 July, because that is the day Playground itself moved to /api/ucp/mcp. Everything after that date comes from our crawler and from direct calls, not from Playground sessions.

What our crawl saw on the way

The retirement was not a switch thrown on 31 August. Across the Shopify-hosted stores in our census, the share of weekly checks in which the old endpoint listed only the policies tool — no cart, no product details — moved like this:

Week Legacy endpoint down to the policies tool only
Through late July 0%
From the week of 3 August 5–9%
Week of 31 August 37%
Week of 7 September 59%

Tools started disappearing from the listing store by store in early August, weeks before the deadline, and the pace picked up sharply around it. By the second week of September, most checks saw the old server reduced to one tool.

What the listing does not tell you is whether the tools still work. That took a call, and the answer on 15 September was yes: get_cart, update_cart, get_product_details and search_catalog all still respond on /api/mcp, each with the deprecation notice appended. They are delisted, not removed — consistent with "may not go away right away", and a window that any integration still on the old server should treat as borrowed time.

The one tool that stays

The tool that remains on /api/mcp is search_shop_policies_and_faqs, and it still returns real answers about returns, shipping and store policies. It was never part of the deprecation — the changelog covers the cart tools only — and, having briefly carried the same notice in July, it no longer does. It has no counterpart on the UCP endpoint.

That gap has been noticed. On 13 August a developer running agents on several Shopify storefronts asked on the forum what the UCP successor for policy and FAQ questions would be. At the time of writing, no reply from Shopify is visible on the thread.

The protocol does not have that capability yet either. UCP today can carry policy information as structured data — typed policies and links such as refund_policy and faq — but it has no capability for asking a store a free-form question. The closest thing in progress is PR #538, an open proposal from Shopify's Ilya Grigorik for dev.ucp.shopping.ask: a platform asks a natural-language question on the buyer's behalf — "what is your return policy for items bought on sale?" — and gets a text answer with related links, optionally grounded on a product and continued across turns. The PR was opened in June, and on 11 September it drew a comment written from Target's perspective. Until something like it lands, an agent that needs to answer "can I return this?" still depends on the old server.

What changes for an agent that makes the move

Moving from /api/mcp to /api/ucp/mcp is not a URL swap. Four things behave differently, and three of them showed up directly in our calls.

Find the endpoint in the manifest. Each of the seven stores declares its UCP MCP endpoint in /.well-known/ucp, on its myshopify.com host. Read it from there rather than constructing it.

Every call needs an agent profile. Cart MCP and Catalog MCP require meta["ucp-agent"] with a profile URL pointing at your agent's UCP profile. A tool call without it came back as HTTP 422, UCP discovery failed, with the reason Missing profile uri. No bearer token is needed; authentication only changes your rate-limit tier.

Listed is not the same as callable. The unauthenticated tool listing shows all thirteen tools. But Shopify's documentation is explicit that "the returned tools depend on the capabilities your agent advertises", and it means it: calling get_cart with an agent profile that does not declare the cart capability returned Tool not found: get_cart, even though get_cart sits in the listing. If your agent will build carts, its profile has to say so.

That behaviour is worth a note for implementers on both sides. UCP's specification says that when negotiation leaves no mutually supported version for a capability an operation needs, the business must return a capabilities_incompatible error. What an agent sees from Shopify today is a tool that is not there. Whether request-time enforcement is required, and how it should surface, is exactly the question an SDK maintainer raised in issue #805, after finding the specification, the reference server and the conformance suite reading it differently. A large production server has now answered it in practice; the council has not yet answered it on paper.

update_cart replaces the whole cart. Cart MCP's update_cart uses PUT semantics: each request sets the cart's full state, and anything you leave out is removed. cancel_cart also requires an idempotency key. Code that sends only the lines it wants to change will quietly drop everything else.

We saw the same shape of problem from the other direction in our store-misbehaviour study, where a capability that was declared but not implemented split the models on how to respond. Here the risk runs the other way: a tool that is listed and implemented, but not offered to an agent that forgot to ask for it.

What we'll be watching

We don't run Shopify's servers, and nothing here is a judgement on the pace of a migration that most of the ecosystem is following. We measure what happens after a change ships, from the public surface, the same way for every platform.

Three things to watch from here. When the delisted cart tools on /api/mcp stop answering, which is the point at which "borrowed time" ends for anyone still calling them. Whether policy and FAQ questions get a UCP home — through ask or something else — so the old server can retire entirely. And whether the request-time enforcement question in #805 is settled in the specification, now that one of the largest UCP implementations has shipped an answer.

For the roughly 10,500 verified Shopify stores in our census, the practical picture today is simple: the shopping journey lives on UCP, the policies question does not yet, and an agent's profile decides which tools it is allowed to see. The Shopify platform page and product discovery guide track the live side of that.


About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

Sources

Check your domain's UCP status

See if your storefront is ready for agentic commerce in seconds.

Weekly UCP Report

Get the agentic commerce digest every Monday

Real adoption data, ecosystem trends, new spec versions, and the stores that broke or recovered this week. Read by founders and engineers building the next generation of commerce.

Free forever No spam Unsubscribe anytime

View a sample report →

Weekly UCP Report
Issue #54 · Oct 12, 2026
+664
new verified stores
Verified rate
Latest spec
Cart capability