The most common way this goes wrong is quiet. You follow a setup guide, paste a JSON block into your client config, restart, and it works: the tool list appears, the connection is green. Then you ask what yesterday's orders looked like and get nothing useful, and it is not obvious why.
The reason is that Shopify ships two different MCP servers, and the easy one cannot see your store.
The two servers
Shopify open-sourced its AI Toolkit in April 2026, packaging its official MCP server stack, agent skills and a Claude Code plugin into one namespace. Inside that namespace are two things people routinely conflate.
Dev MCP runs locally, requires no login, and gives the assistant Shopify's developer documentation and API schemas. It is built for people writing Shopify apps, and it is genuinely good at that job. It will not read yesterday's orders or edit a product, because by design it never touches a live store.
Admin MCP is the one that works against real store data, and it needs an Admin API token. That token is the whole difference, and it is also the whole setup cost.
If you are building on Shopify, install Dev MCP and stop reading. It is free, official, and this article is not trying to replace it. If you are running a store and want to ask questions about it, you need the other one.
What the Admin route actually asks of you
You create a custom app inside your own store admin, grant it the Admin API access scopes it needs, and hold the resulting token. That is three decisions people tend to make badly.
The first is scope breadth. Grant too little and the failure arrives later, at call time, as an authorisation error inside a chat response where it is hard to read. Grant everything and you have created a token that can rewrite your catalogue, sitting in a config file on a laptop.
The second is where the token lives. A plaintext token in a JSON config is the default that most guides show, because it is the shortest instruction to write. It is not the one you would choose for a credential that can publish products.
The third is rotation. Tokens outlive the reason you made them. Nothing in the setup reminds you.
Reads and writes are not the same risk
Asking which SKUs sold out last week is a read. It is cheap, reversible, and if the answer is wrong you notice and move on.
Changing a price, editing a product description, publishing to a sales channel. All of these run against a live storefront where customers are shopping right now. The protocol has no opinion about that distinction. MCP describes a tool and its arguments; it does not carry a notion of "this one is irreversible."
Which means the gate has to live in the client. If your client executes tool calls as soon as the model emits them, then the only thing standing between a misread instruction and a repriced catalogue is the model having a good day. That is not a risk profile anyone chooses on purpose; it is one people inherit from a setup guide.
The same shape, on every other platform
eBay, Etsy and WooCommerce all have community MCP servers now, and the story repeats almost exactly: a token or key pair you generate yourself, a scope decision, a local process to keep running, and a client that has to be trusted with writes. A seller on four platforms who takes this route ends up operating four small services and holding four credentials, which is a real job that nobody put on the roadmap.
Where Orkas sits in this
Orkas is an MCP client, so every server described above works with it the way it works with other clients. It also ships a Shopify Admin connector of its own, built on a merchant-owned Dev Dashboard app, and two details are the point of it.
Scopes are validated when you connect, not when a call fails. Orkas checks each required scope: products, orders, customers, inventory, locations, draft orders, returns, discounts, publications and the applicable fulfilment-order scopes. It tells you which one is missing before you have spent a conversation finding out. Credentials are encrypted on your own device rather than sitting in a config file.
And the write gate is in the client, not in the prompt. Anything that writes, deletes, spends or touches a live store goes through a permission prompt, with irreversible actions gated separately from routine ones. The same catalogue covers eBay, Etsy, Walmart Marketplace, WooCommerce and Amazon Seller Central, plus the Chinese platforms, so the four-services problem does not reappear once per storefront.
What this does not cover
None of this makes Orkas a store management system. It does not hold inventory, route orders or reprice for you; if that is what you need, keep the ERP. What it replaces is the pile of small integrations you would otherwise assemble to ask questions of your own store and act on the answers. For the acting part, it also replaces the assumption that a model having a good day is a sufficient safeguard.