搜「Amazon Seller MCP server」，首頁會給你三類答案：賣你一條連接的托管中繼、你自己跑的開源倉庫，以及把這兩類都收錄進去的目錄站。它們描述同一個能力，用詞幾乎一樣：用自然語言問你的店鋪，從真實資料拿到答案。
這個能力是真的，也值得有。但它比那句話聽起來的範圍窄，而失望大多產生在這個差距里。
Amazon Seller MCP server 到底是什麼
Model Context Protocol 是讓 AI 客戶端呼叫別人定義好的工具的一種方式。Amazon Seller MCP server 就是一個小程序，把 Amazon 的 Selling Partner API（SP-API）包一層，把它的端點暴露成你的客戶端能調的工具。這個設計里沒有任何 Amazon 特有的東西。同樣的做法正在被套到 Shopify、eBay、Stripe 和另外一百個 API 上。
用來推銷它們的例子相當一致，而且對自己能做什麼是誠實的：上個月分站點的銷售額和銷量、哪些 SKU 快斷貨、過去九十天分類目的退貨率。這些全是對本來就存在的端點做讀查詢。MCP 這一層省掉的是「導出報表、打開表格」這一步。
三種形態，各自的代價
托管中繼。廠商替你跑服務，你去授權。啓動最快，也是唯一不需要本地進程的選項。代價是你的賣家資料要經過一個你現在必須去評估的第三方，而且按人頭或按呼叫付費。
你自己跑的倉庫。GitHub 上有好幾個，其中一些明確寫著是給 Claude Desktop 用的。你和 Amazon 之間沒有別人，這正是重點。但你現在在運維一個服務：讓進程活著、跟上 SP-API 的上游變更、憑據過期時去輪換。
原生就說這個協議的客戶端。不需要單獨的 server，因為客戶端本身就是 MCP 客戶端，連接器也內置了。活動部件更少，但你選的是客戶端，而不是往現有的那個上加東西。
被跳過的那一步
三條路最後都匯到同一個前置條件，而幾乎沒有哪份教程把它放在開頭：你需要一個自己的 SP-API 應用。這意味著開發者註冊、選擇你的應用要申請哪些角色，以及持有會過期、要輪換的 LWA 憑據。
由此產生的兩個後果很容易發現得太晚。第一，角色是按類別授予的，其中覆蓋買家個人身份資訊的受限角色要走單獨的審批，大多數賣家既拿不到也不需要。第二，SP-API 是按端點限流的，所以一個用一句話問出來的問題，可能變成一串被限流的呼叫；而一個會靜默重試的客戶端，會一邊等一邊燒 token。
這些都不是「別做」的理由。它們是「別信十分鐘搞定」這個說法的理由。
取數能給你的東西有個上限
假設一切都跑通了。你現在有一個聊天窗口，能告訴你分類目退貨率是 8.4%，以及有四個 SKU 會在三周內斷貨。
這兩個數字都不是決策。退貨率要等你知道它是尺碼問題、包裝失敗，還是 listing 本來就不該做的承諾，才開始有意義，而這些都在評論正文里，退貨介面裡沒有。斷貨要放在備貨週期和季節里才有意義。而當你決定重寫 listing 時，模型需要知道 Amazon 要的是關鍵詞密集、在字符預算內的標題和五條 bullet，需要知道功效類說法要有證據，還要知道哪些極限詞會讓 listing 被下架。
那是領域知識。MCP 是傳輸層。它本來就不會提供這些，指望它提供是搞錯了類別。
Orkas 在這件事里的位置
Orkas 本身是 MCP 客戶端，所以上面說的任何 server 在它這裡的用法，和在別的客戶端里一樣。它還自帶了 Amazon Seller Central 連接器，走你自己的 SP-API 私有應用，憑據加密儲存在本機，買家個人資訊既不申請也不暴露。就這一個集成來說，沒有單獨的服務需要你養著。
更要緊的是上面那一層。Orkas 內置四個電商 skill，攜帶的正是協議不攜帶的領域知識：把利潤假設寫明白的類目調研、帶分平台規則和合規檢查的 listing 生成、從必賣理由卡片一路到圖片 prompt 和影片分鏡的創意規劃，以及先把買家標識脫敏、再把抱怨聚成你能改的東西的評論分析。
它們跑在你能提供的任何東西上。配了連接器，資料走 API 進來；沒配，它們就讀你自己導出的報表。今天大多數賣家本來就是這麼乾的，作為起點完全夠用。
這篇沒有覆蓋的部分
MCP server，無論是我們的還是別人的，讀的都是你賣家帳號里已經有的資料。它不會給你全平台的搜索量、BSR 歷史或競品銷量估算；那些是買了授權的資料集，賣這些資料的工具不會被一個協議替代。如果你的問題需要那些資料，就去買那些資料。如果你的問題是「手上這些數字該怎麼用」，那是另一個工具、另一篇文章。