A Shopify MCP server is the tool layer that lets an AI assistant do work in your store; the real value is in the rules on those tools. For Horeca Papatya's live B2B store we built a custom MCP server with 10 tools: bulk jobs run as a dry run first, new products start as drafts, deletes need approval. A plain sentence is enough. It works with any MCP-capable agent harness.
Source: project code repository, 16 Apr – 9 Nov 2026. Scripts, state files and tests counted on 10 Nov 2026; product cap from the server code.
Horeca Papatya supplies hotels, restaurants and cafés in Romania from a single Shopify store: priced retail products and unpriced, quote-only B2B products in one place. Small jobs pile up in the store every day. We wanted an AI assistant to handle them by chat, without putting the live store, the storefront customers see, at risk.
Removing a product series, fixing tags, finding low stock: each meant clicking through the Shopify admin one item at a time. Accuracy depended on whoever did the work.
When a language model doesn't know a Shopify category or a product's name, it makes up a plausible answer. On a live store, plausible isn't good enough.
A wrong bulk publish or delete shows up for customers at once. Every bulk job needed a preview first, and a way back ready before it ran.
When we started, Shopify's own AI tools were aimed at developers and shoppers. We needed a layer that changes the store, with rules we set ourselves.
The agent harness can change. Dry run, drafts and delete approval sit in the server's code, so every harness works by the same rules.
Diagram: products, inventory and sales channels connect to a custom Shopify Admin MCP server with 10 tools. Three rules: dry run first, drafts first, delete only with approval. Any MCP-capable harness can connect: Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, Windsurf, ChatGPT and Claude.
Product names show compatibility only. Some harnesses need the server to be reachable from the internet.
The store manager writes without knowing code or the admin. The assistant picks the right tool, shows what will change, applies it on approval and reports back.
The interface is a chat: no code, no admin panel. The server sets the rules.
Large jobsCatalog builds of hundreds of products ran under the same rules, through separate scripts the agent wrote. That story has its own case study.Catalog case study
chat.request · series-x → DRAFTsearch_products · query: tag:series-xbulk_update_products · setStatus: DRAFT · dryRun: trueconfirm · applybulk_update_products · dryRun: falsesearch_products · query: tag:series-x status:activeAn illustrative flow; tool names and defaults match the server.
The server and its rules came first. Then everyday store jobs moved to chat. For large jobs that don't fit in a chat, the same agent wrote scripts that follow the same rules. Every step left a trace in the project repository.
Figures from the project code repository, counted on 10 November 2026.
OutcomeStore jobs are asked for in a plain sentence and run as checked API calls.
OutcomeBulk changes are previewed first; publishing and deleting wait for a person to approve.
OutcomeOne sentence instead of clicking product by product in the admin; results are read back from the live store.
OutcomeThe catalog builds are told in a separate case study; the same rules apply there too.
OutcomeWhat changed, and how to undo it, is on record.
OutcomeThe interface is a chat: no code, no admin panel; whoever runs the store can use it.
OutcomeStore jobs are asked for in a plain sentence and run as checked API calls.
OutcomeBulk changes are previewed first; publishing and deleting wait for a person to approve.
OutcomeOne sentence instead of clicking product by product in the admin; results are read back from the live store.
OutcomeThe catalog builds are told in a separate case study; the same rules apply there too.
OutcomeWhat changed, and how to undo it, is on record.
OutcomeThe interface is a chat: no code, no admin panel; whoever runs the store can use it.
Writing "be careful" in a prompt is lost the moment the agent harness changes. With dry run, drafts and delete approval in the server's code, Claude Code, Codex and Cursor all work by the same rules.
When you use AI for ecommerce, defaults decide most of what a mistake costs. A dry run by default, drafts by default and no delete without approval turn even a bad mistake into a preview screen.
Product categories came from an approved taxonomy file; product names and statuses were read from the live store. Anything the model might guess should come from a source it can read.
A batch with its own rollback script reverts with one command. Writing that script first turns a big change from a risk into a routine job.
Single products and small bulk jobs stay in chat. A job of hundreds of products needs a script with a state file, tests and a rollback script. The agent writes that too, and the rules stay the same.
Basics: what is an MCP server and our Shopify MCP guide. Our service: AI agents for business.
A Shopify MCP server gives an AI assistant tools it can call in your store through the Model Context Protocol. The server in this project uses the Shopify Admin GraphQL API: it searches, creates and updates products and changes stock and publishing. Bulk jobs run as a dry run first; new products start as drafts.
Yes, if your agent harness supports MCP. The server isn't tied to one assistant: Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, Windsurf, ChatGPT or Claude can connect. Some, like ChatGPT, need the server reachable from the internet; the dry run, draft and approval rules stay the same.
The rules keep it small. A bulk change is listed as a dry run first, a new product starts as a draft and a delete needs explicit approval. In large jobs every batch has a state file and a rollback script; a batch that goes wrong reverts with one command and the store is back as it was.
You state the filter in a plain sentence: a tag, a series or a status. The assistant finds the matching products and shows the change as a dry run first. Once you approve, it applies it and reports the result read from the live store. The default cap is 250 products; if more match, the job is refused.
It depends on the goal. Shopify's own MCP servers are mostly for developers and shopping. If you want a layer that manages your store, with rules you set, you need a custom server. Our Shopify MCP guide keeps track of what each official server does; take a look before you choose.
Yes. The interface is a chat: no code, no admin panel. Whoever runs the store writes the request in a plain sentence; the assistant shows the change first and applies it on approval. Setup and maintenance sit with SEMROI. We can run the work for you, or hand it to your team with a guide, to use with your own assistant.
Tell us which store jobs take up the most time. We will show you which ones an MCP server can take over by chat and which should stay with human approval.
