這件事出錯的最常見方式是安靜的。你照著教程走，把一段 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 繼續留著。它替代掉的是那一堆你本來要自己拼起來的小集成，用來對自己的店鋪提問，並且對答案採取行動。而在「採取行動」這一半上，它替代掉的是「模型今天狀態好就夠了」這個假設。