这件事出错的最常见方式是安静的。你照着教程走，把一段 JSON 粘进客户端配置，重启，然后它跑起来了：工具列表出现了，连接是绿的。接着你问「昨天的订单怎么样」，得到的东西没什么用，而且看不出为什么。
原因是 Shopify 发的是两个不同的 MCP server，而容易装的那个看不见你的店。
两个 server
Shopify 在 2026 年 4 月把自家的 AI Toolkit 开源，把官方 MCP server、agent skill 和一个 Claude Code 插件打包进同一个命名空间。这里面有两样东西经常被混为一谈。
Dev MCP 跑在本地，不需要登录，给助手的是 Shopify 的开发者文档和 API schema。它是给写 Shopify 应用的人用的，而且在那件事上确实好用。它读不到昨天的订单，也改不了商品，因为按设计它根本不碰线上店铺。
Admin MCP 才是对真实店铺数据工作的那个，它需要一个 Admin API token。那个 token 就是全部区别所在，也是全部配置成本所在。
如果你是在 Shopify 上做开发，装 Dev MCP 然后就别往下读了。它免费、官方，这篇文章不打算替代它。如果你是在经营一家店、想对它提问，你需要的是另一个。
Admin 这条路真正要你付出的
你要在自己店铺后台里建一个自定义应用，给它授予需要的 Admin API 权限范围，然后保管拿到的 token。这里有三个决定，人们通常做得不好。
第一个是权限范围给多宽。给少了，失败会推迟到调用时才出现，变成聊天回复里一条很难读的授权错误。全给了，你就造出了一个能重写你整个商品目录的 token，躺在某台笔记本的配置文件里。
第二个是 token 放在哪。明文写进 JSON 配置是大多数教程展示的默认做法，因为那是最短的一句指令。但对一个能发布商品的凭据来说，这不会是你主动挑的做法。
第三个是轮换。token 的寿命通常比你当初造它的理由长。配置流程里没有任何一步会提醒你。
读和写不是同一种风险
问「上周哪些 SKU 卖断了」是读。便宜、可逆，答错了你发现了，往下走就行。
改价格、改商品描述、发布到销售渠道，这些都是对着一个此刻正有顾客在逛的线上店铺跑的。协议对这个区别没有意见。MCP 描述的是一个工具和它的参数，它不携带「这一个不可逆」这种概念。
这意味着闸门必须在客户端里。如果你的客户端在模型一吐出工具调用就执行，那么在「一条被读错的指令」和「一整个被改价的商品目录」之间，唯一站着的东西就是模型今天状态好。没有人会主动选择这种风险画像，人们是从一份配置教程里继承来的。
换个平台，形状一模一样
eBay、Etsy、WooCommerce 现在都有社区 MCP server，故事几乎逐字重复：一个你自己生成的 token 或密钥对、一次权限范围决定、一个要一直跑着的本地进程，以及一个必须被信任去执行写操作的客户端。一个在四个平台上卖货的人如果走这条路，最后是在运维四个小服务、保管四份凭据。这是一份真实的工作，而没有人把它排进过计划。
Orkas 在这件事里的位置
Orkas 本身是 MCP 客户端，所以上面说的每个 server 在它这里的用法和在别的客户端里一样。它还自带一个 Shopify Admin 连接器，建在商户自有的 Dev Dashboard 应用之上，重点在两个细节上。
权限范围是在连接时校验的，不是等某次调用失败才发现。Orkas 会逐项检查所需权限：商品、订单、客户、库存、门店、草稿单、退货、折扣、发布，以及适用的履约订单权限。在你花掉一整段对话去试出来之前，它就告诉你缺的是哪一项。凭据加密保存在你自己的设备上，而不是躺在配置文件里。
而写操作的闸门在客户端里，不在 prompt 里。凡是写入、删除、花钱或碰到线上店铺的动作都要过一次授权提示，不可逆的动作还有单独的闸。同一份连接器目录覆盖 eBay、Etsy、Walmart Marketplace、WooCommerce 和 Amazon Seller Central，以及国内平台，所以「四个小服务」那个问题不会每开一个店就重来一遍。
这篇没有覆盖的部分
以上这些都不会让 Orkas 变成一套店铺管理系统。它不管库存、不做订单流转、不替你调价；你要的是那些，ERP 继续留着。它替代掉的是那一堆你本来要自己拼起来的小集成，用来对自己的店铺提问，并且对答案采取行动。而在「采取行动」这一半上，它替代掉的是「模型今天状态好就够了」这个假设。