搜「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 历史或竞品销量估算；那些是买了授权的数据集，卖这些数据的工具不会被一个协议替代。如果你的问题需要那些数据，就去买那些数据。如果你的问题是「手上这些数字该怎么用」，那是另一个工具、另一篇文章。