Blog · · Updated · 9 min
Shopify MCP: which server builds the store?
None. The Dev MCP hands your AI Shopify's docs, the Storefront MCP hands your catalogue to an assistant, admin servers move data. None renders.
By uxgen
None of them builds the store. That is the short answer, and it is worth having before you spend an evening installing them.
Definition. A Shopify MCP is any server speaking the Model Context Protocol that an AI client calls to reach something of Shopify's: its documentation, a merchant's catalogue, or a store's admin. Four separate things go by the name, and they sit at four different points in the chain. Three are covered below; the fourth, Shopify's official admin connector for Claude (25 tools, at https://setup.shopify.com/mcp), is an admin-side server with Shopify's name on it, and it is taken apart in Connect Claude to Shopify. One teaches your coding agent Shopify's APIs. One opens your catalogue to an AI assistant that is shopping on a customer's behalf. One drives the admin: products, orders, inventory. What none of them returns is markup. Ask any of the three for a quantity tier selector and you get documentation, a product JSON, or nothing at all.
Which one is which?
| Server | Who is the client | What it returns | Does it render anything |
|---|---|---|---|
Dev MCP (@shopify/dev-mcp) | Your coding agent | Documentation passages, GraphQL schema fields | No |
| Storefront MCP | Someone else's shopping assistant | Your products, cart state, policies, order status | No, and it is not for your site |
| Admin-side servers | An agent operating the shop | Products, orders, inventory, metafields | No |
Read the middle row twice. The Storefront MCP is the one people install expecting help with their storefront, and it is the one pointed the other way: your shop is the server, an assistant is the client, and the buyer is on the far side of it.
What does the Dev MCP actually do?
It stops the agent guessing field names. Shopify's Admin GraphQL schema is large and it changes on a versioned calendar; a model writing a mutation from memory will invent a field that existed two versions ago. The Dev MCP gives it documentation search and schema introspection instead, running locally, with no authentication.
claude mcp add --transport stdio shopify-dev-mcp -- npx -y @shopify/dev-mcp@latest
Or, if your client reads a JSON file:
{
"mcpServers": {
"shopify-dev-mcp": {
"command": "npx",
"args": ["-y", "@shopify/dev-mcp@latest"]
}
}
}
Now the part nobody mentions. We probed it over stdio on 2 September 2026, on version 1.14.7, and tools/list answers with exactly one tool: learn_shopify_api. It is a gate. It returns a conversationId, and every other tool refuses to run without one. You tell it which surface you are working on — admin, functions, polaris-admin-extensions, the Shopify CLI, among others — and the documentation search and schema introspection unlock behind that choice.
You can check this yourself, on this or any other stdio server, without installing a client:
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"probe","version":"1.0"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
| npx -y @shopify/dev-mcp@latest
Two things follow from that single tool. The agent has to spend a turn learning before it can answer, so the first Shopify question in a session is slower than the ones after it. And the tool names behind the gate move between releases, so list them yourself rather than trusting a write-up, this one included. What is stable is the shape of the help: docs and schemas, for the API, not for the page.
What is the Storefront MCP for?
For letting a customer shop your store from inside an assistant. Shopify groups its capabilities as product discovery, cart management, store information and order management. In practice: the assistant searches your catalogue in natural language, builds a cart, quotes your return policy, checks an order.
That is a real thing to want, and it is a distribution decision, not a front-end one. The question it answers is should an AI agent be able to buy from me. It answers nothing at all about what a human sees when they land on the page.
We could not verify the current endpoint path from Shopify's public docs in one pass on 2 September 2026, and there are at least two versions of it circulating in blog posts. Take that one from the official reference rather than from anybody's article.
What are all those repositories on GitHub?
Mostly Admin API wrappers, and mostly community-built. Run the search yourself:
gh search repos "shopify mcp" --limit 10 --json fullName,description
We ran it on 2 September 2026. Ten results, and every description was a variation on the same sentence: products, customers, orders, inventory, metafields, through the Admin GraphQL API. Useful if you want an agent that can restock a variant while you talk to it. Useless if what you wanted was a page that sells.
Treat those the way you would treat any third-party server holding an Admin token. It has write access to your shop.
So what is left to write by hand?
Everything a buyer looks at. The mechanics that decide whether a visitor becomes an order do not exist in any of the three families, because none of them is in the business of rendering: the quantity tier that makes the three-pack the obvious pick, the line that says how much is left before shipping is free, the complement offered after the add-to-cart, the sticky bar that keeps the price and the button reachable on a phone. We inventoried what the general component registries carry in shadcn ecommerce blocks, and the answer there was similar.
Here is the size of the gap, in the smallest example we can fit. A multi-pack needs a unit price under the pack price, because $1.27 per sachet is the number a buyer compares and $38.00 is not. Nothing in Shopify's data model knows how many sachets are in a box, so the count is a metafield you define and the line is code you write:
type Variant = {
title: string
price: { amount: string; currencyCode: string }
unitsPerPack: number // your own metafield. Shopify does not have this.
}
export function unitPriceLabel(v: Variant, locale = 'en-US'): string | null {
if (v.unitsPerPack <= 1) return null // single unit: the line would be noise
const perUnit = Number(v.price.amount) / v.unitsPerPack
const money = new Intl.NumberFormat(locale, {
style: 'currency',
currency: v.price.currencyCode,
minimumFractionDigits: 2,
}).format(perUnit)
return `${money} per unit`
}
Twelve lines, and no MCP in the Shopify family will hand them to you. Multiply that by the fifteen or so decisions on a product page and you have the honest scope of the work.
Which ones should you install?
Depends on what you are doing this week. In order:
- Audit the page first. Paste the product URL at /audit. If the page already carries the selling mechanics, you need none of what follows for conversion; if it does not, you know which sections to ask for.
- Writing Shopify code with an agent? Install the Dev MCP, locally, with the command above.
- Opening the shop to AI assistants? Read Shopify's current Storefront MCP reference and decide it as a channel.
- Automating operations? Shopify's own connector for Claude, or a community admin server with a scoped token.
- Making the page convert? A sections server such as uxgen (
claude mcp add --transport http uxgen https://www.uxgen.ai/mcp), in improve mode on an existing store so nothing already on the page moves — the rule is at /docs#improve.
The same list as a table of trade-offs:
- Writing Shopify code with an agent. Dev MCP, yes. It removes a whole class of invented field names.
- Opening the shop to AI assistants. Storefront MCP, and read it as a channel decision.
- Automating shop operations. An admin server, with a hard look at who wrote it and what token it holds.
- Making the page convert. None of them. That work is still yours, and if you are running it on a Shopify theme the trade-off between installing an app and writing the block is set out in upsell apps for Shopify, or build it.
The wider MCP shelf for front-end work, and what each of those servers refuses to do, is in the MCP servers worth installing for frontend work.
We build uxgen, an MCP that hands your AI the selling sections themselves as HTML you keep. The four cart mechanics are readable in the open kit, MIT: github.com/kinerette/uxgen-commerce-kit.
FAQ
What is the Shopify MCP server?
There is no single one. Three families share the name, plus Shopify's official admin connector for Claude: the Dev MCP, installed with npx -y @shopify/dev-mcp@latest, which gives a coding agent Shopify's documentation and GraphQL schemas locally and without authentication; the Storefront MCP, which exposes a merchant's catalogue, cart and policies to an AI shopping assistant; and admin-side servers, mostly community-built, which read and write products, orders and inventory through the Admin API.
Can a Shopify MCP server build my product page?
No. None of the three returns markup. The Dev MCP returns documentation and schema fields, the Storefront MCP returns catalogue and cart data to an assistant, and the admin servers return records. The layout, the section order and the selling mechanics are code you or your agent writes.
Is the Storefront MCP useful for my own storefront?
Only indirectly. It points outward: your shop is the server and an external AI assistant is the client, shopping on a customer's behalf. It is a distribution channel, not a front-end tool, and installing it changes nothing about what a human visitor sees on your site.
Are the community Shopify MCP servers on GitHub safe to use?
They hold an Admin API token, which means write access to products, orders and inventory. That is not a reason to avoid them, but it is a reason to read the source, pin the version, and scope the token to the smallest set of permissions the task needs rather than granting a full-access key to a package you installed from a search result.