MCP 对接指南：把 AI 助手连接到 SMM 面板账户

MCP（Model Context Protocol，模型上下文协议）是一个让 AI 助手用统一方式调用外部系统工具的开放协议，在 Panel Follows 上它的意思是：你可以直接对 Claude 或 ChatGPT 说"帮我看看 Instagram 粉丝服务的价格"，助手会去搜索目录、算出金额、把结果摆在你面前，等你点头之后再下单。

这件事和"给 AI 一个 API 文档让它自己写代码"不是一回事。MCP 不需要你写脚本，也不需要你把接口文档喂给模型。你在面板里点一次授权，客户端就拿到了一份工具清单，每个工具的名字、参数和使用时机都由服务器直接描述给模型。模型不用猜。

这篇文章讲清楚三件事：这套东西能做什么（18 个工具的完整清单和边界）、怎么接上（OAuth 授权的六步和各家客户端的配置写法）、以及出问题时怎么看（令牌有效期、权限范围、审计日志和常见报错的真实含义）。所有工具名、参数名、按钮文字都按面板里真实显示的写，你照着找就行。

先把最重要的一条边界说在前面：助手花的是你面板余额里的真钱，而且下单不可撤销。 服务器会强制它先查价、先征求你同意，但这是流程约束，不是保险。你自己也要养成看一眼金额再回复"确认"的习惯。

MCP 是什么，它在一个 SMM 面板上解决什么问题？

MCP 是一个开放协议，规定了 AI 客户端（Claude、ChatGPT、Cursor 等）和外部服务之间怎么互相介绍能力、怎么调用功能、怎么返回结果。你可以把它理解成"AI 助手的通用插口"：以前每接一个系统就要为它写一套适配代码，现在只要这个系统提供一台 MCP 服务器，任何支持 MCP 的客户端都能立刻用上。

对一个 SMM 面板的用户来说，它解决的是这样几个具体的麻烦：

第一，你不用再在页面之间来回翻。 想知道"上个月那笔 TikTok 播放量订单跑完没有"，以前要打开控制台、进"我的订单"、翻页、搜索；现在一句话，助手调 list_orders 和 get_order 就答给你了。

第二，选服务变成了比较题而不是搜索题。 目录里同一个平台的同一类服务往往有十几条，价格、最小数量、有没有补充保证、平均耗时各不相同。助手可以一次拉出来，按你在意的维度排成一张表让你挑，而不是你自己一条条点开看。

第三，价格算错的概率降低了。 面板里最贵的一类误操作是把套餐价当成千次价来算，差一千倍。服务器在给模型的说明里专门写死了这一条规则，并且要求它在下单之前必须先调用价格预览工具，把实际扣款金额报给你。

第四，它不需要你会写代码。 面板本来就有一套完整的开发者 REST 接口，写在 /zh/api-docs，能力比 MCP 更全。但那条路要求你能写请求、处理 JSON、管好密钥。MCP 这条路只要求你会复制粘贴一个网址。

需要说清楚的是它不是什么。MCP 不是一个自动运营机器人，它不会在你睡觉时替你决定买什么；它没有独立的判断权，每一次花钱的动作都由你在对话里点头触发。它也不是一条更便宜的通道，通过助手下的单和你在面板上点出来的单，价格完全一样，没有额外费用也没有折扣。

如果你还没用过这个面板本身，建议先看一遍 /zh/blog/panel-follows-shiyong-zhinan，那篇按屏幕顺序讲了注册、充值、下单和售后。本文默认你已经有账户、有余额，知道"服务编号"和"数量范围"是什么意思。

面板里有两台 MCP 服务器，哪一台是给你的？

面板一共跑着两台 MCP 服务器，用途完全不同，接错了会一直卡在鉴权失败上。

对比项	用户服务器	管理服务器
地址	POST /api/mcp/user	POST /api/mcp
谁来连	面板的客户，也就是你	面板所有者
身份验证	OAuth 2.1 令牌或账户的 API 密钥	单一的服务端密钥（MCP_SECRET）
权限范围	只有你自己的账户，18 个工具	整个面板，57 个工具
审计记录	写入 aiAuditLog，带账户 ID	写入 aiAuditLog，不带账户 ID

你要连的是 /api/mcp/user。 这台服务器在每一次请求里都绑定到一个固定的账户：它看得见你的余额和订单，看不见任何别人的数据，也碰不到价格、供应商、其他账户这些管理面的东西。

两台服务器共用同一套协议内核，所以它们在传输层的行为完全一致：都是无状态的 JSON-RPC 2.0，都只接受 POST，都会把工具错误当成正常返回值交给模型。区别只在于"谁能进来"和"进来之后能碰什么"。

管理服务器这一侧和普通用户没有关系，本文后面只用一节交代它的存在，目的是让你知道面板自己也在用同一套协议被管理，而不是让你去尝试连它。没有服务端密钥的情况下那个地址对你完全关闭。

助手能用的 18 个工具都做什么？

连上之后，助手拿到的是一份 18 个工具的清单。它们按用途分成五组，每一个都对应开发者接口里的一个端点，参数名一模一样。

分组	工具
账户	get_account
目录	list_platforms、list_categories、search_services、get_service
订单	preview_order、create_order、create_orders_bulk、list_orders、get_order、cancel_order、refill_order
补充	list_refills、get_refill
自动化	list_events、list_webhooks、create_webhook、delete_webhook

18 个里有 12 个是只读的：get_account、list_platforms、list_categories、search_services、get_service、preview_order、list_orders、get_order、list_refills、get_refill、list_events、list_webhooks。剩下 6 个会写入：create_order、create_orders_bulk、cancel_order、refill_order、create_webhook、delete_webhook。

这两类的区别在后面讲"仅查看"权限时会变得非常重要，因为只读的那 12 个是无论什么权限都在的，写入的 6 个则可以被整体关掉。

每个工具的具体行为

下面这些是服务器给模型的工具说明里写明的行为，不是推测：

get_account 返回账户的标识、邮箱、**可用余额（美元）**和请求限额。助手在准备下单之前一般会先调它一次，确认钱够不够。

list_platforms 列出目录里的平台（instagram、tiktok、youtube 等）以及每个平台下的服务数量。它的作用是告诉模型 search_services 的 platform 参数可以填哪些值，避免模型凭印象编一个平台名。

list_categories 列出含有在售服务的分类，返回 slug、名称和服务数量。同样，它是给搜索工具喂合法参数用的。

search_services 是目录检索工具，支持的筛选条件有 search（服务名里的关键词）、platform、category、type、refill（只看有补充保证的）、cancel（只看能取消的）、dripfeed（只看支持分批发送的）、min_rate 和 max_rate。返回的价格是你自己账户的价格。分页默认一页 20 条，最多 50 条。

get_service 拉取单个服务的全部细节：价格、最小/最大数量、是否支持补充和取消、是否支持分批发送、平均耗时，以及下单需要填哪些字段（fields）。这一项是整套设计里最关键的一环：模型不去猜某个服务要不要填用户名、要不要填话题标签，而是从这个列表里读出来。

preview_order 用和下单完全相同的参数，做一次不真正下单的校验和计价，返回 charge（本单金额）、balance_after（下单后余额）和 sufficient_balance（余额够不够）。

create_order 才是真正下单的那一个：花真钱、扣余额、不可撤销。

create_orders_bulk 一次最多提交 50 单。这些单子是按顺序逐条处理的，中间某一条失败不会影响后面的，每一条都会返回自己的结果。

list_orders 按时间倒序列出订单，状态筛选可选 pending、in_progress、completed、partial、canceled、refunded、failed。默认返回 20 条，最多 100 条。

get_order 查单笔订单的当前状态：起始计数、剩余数量、金额，以及如果有的话，供应商侧的错误信息。

cancel_order 只在服务本身支持取消（在 get_service 的 features.cancel 里）而且订单还没完成时可用。服务不支持的话会返回 cancel_not_supported，这时候只能走工单。

refill_order 只对已完成且带补充保证的订单有效。它是免费的，不影响余额。

list_refills 和 get_refill 用来查补充申请的列表和单条状态。

list_events 读取账户的事件流，按从旧到新的顺序，可以按事件类型筛选。

list_webhooks、create_webhook、delete_webhook 管理事件推送地址。创建时返回的签名密钥只显示一次，删除时连带把还没发出去的推送一起丢弃。

所有列表类工具都是游标分页：你传 starting_after，返回里带 next_cursor。分页上限被刻意压得比较小，因为结果是以文本形式进入模型上下文的，一次塞 500 条服务既贵又会让模型分心。

怎么把 AI 助手连到面板？三个步骤

连接入口在控制台左侧菜单的 "AI 助手"，地址是 /zh/dashboard/mcp。页面顶部就是你需要的那个地址，卡片标题是**"连接地址"**，下面写着"把这个地址添加到你的 AI 客户端。授权在本面板完成，密码绝不会交给客户端。"

页面上列出的三步就是全部流程：

1. "复制地址，在 AI 客户端中添加为 MCP 服务器。"
2. "客户端会把你带到这里，确认授权（也可以只给查看权限）。"
3. "之后就可以说'看看 Instagram 粉丝的价格'或'我最近的订单怎么样了'。"

主面板的连接地址是 https://panelfollows.com/api/mcp/user。如果你是某个子面板（白标面板）的客户，页面上显示的会是那个面板自己的域名，你要用页面上看到的那一个，不要用主站的。

整个过程中你不需要复制任何密钥。第 2 步跳转到的是面板自己的授权页面，你在自己的登录态下点确认，客户端拿到的是一枚有期限的令牌，不是你的密码。这一点在页面上写得很明确："授权在本面板完成，密码绝不会交给客户端。"

如果你当时没登录，系统会先把你送到登录页，登录完成后再回到同一个授权页面，不用重新从客户端发起。

助手能做和不能做的事，页面上也写了

同一个页面上有一张卡片叫**"助手能做什么"**，三行字划出了完整边界：

• "搜索服务、计算价格、查看你的订单和余额。"
• "下单、取消订单、申请补量（refill）。下单前会先请你确认。"
• "不能充值、不能提现、看不到密码，也无法访问其他账户。"

第三行是硬边界，不是配置项。这三件事在工具层面根本不存在对应的接口，不是"默认关闭"。

各家客户端的配置写法是什么样的？

面板的 "AI 助手" 页面里有一张**"各客户端设置"**卡片，四个标签页对应四种常见接法。副标题写着"支持 OAuth 2.1 的 MCP 客户端都可使用。能发送请求头的客户端也可以改用 API 密钥。"

Claude Code（命令行）：

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user

Cursor / VS Code（配置文件里加一段）：

{ "mcpServers": { "panel": { "type": "http", "url": "https://panelfollows.com/api/mcp/user" } } }

用 API 密钥连接（跳过 OAuth，直接带请求头）：

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user \
  --header "Authorization: Bearer pf_live_..."

用 curl 验证连通性（想先确认地址通不通的话，这条最直接）：

curl -s https://panelfollows.com/api/mcp/user \
  -H "Authorization: Bearer pf_live_..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

最后这条命令返回的是完整的工具清单，包括每个工具的参数结构和 readOnlyHint、destructiveHint 两个提示标记。客户端就是靠这份清单知道哪些工具是只读的、哪些会造成不可逆后果的。

客户端类型	推荐接法	理由
支持 OAuth 的桌面客户端	只填地址，走授权页	不用碰密钥，随时能在面板里断开
能自定义请求头的客户端	Authorization: Bearer pf_live_...	一步到位，适合固定环境
自己写的脚本或机器人	API 密钥	没有浏览器可用来完成授权跳转
只想验证地址是否可达	curl 加 tools/list	不产生任何写入动作

页面底部还有一句提示："更想用密钥连接？在这里创建："，后面链到 /zh/dashboard/api，也就是生成开发者密钥的那个页面。

OAuth 2.1 在后台究竟做了哪六件事？

你在界面上只看到"跳转、确认、跳回来"，但协议层面按顺序发生了六件事。知道它们的顺序，出错时你能一眼看出卡在哪一步。

1. 客户端先撞一次墙。 它对 /api/mcp/user 发一个不带身份的请求，收到 401。这个响应里带着 WWW-Authenticate 头，里面写明了资源元数据的位置，也就是 /.well-known/oauth-protected-resource/api/mcp/user（RFC 9728 规定的写法）。

2. 客户端顺着元数据做发现。 先读 /.well-known/oauth-protected-resource，从中找到授权服务器，再读 /.well-known/oauth-authorization-server（RFC 8414），拿到授权端点、令牌端点和支持的参数。

3. 客户端动态注册自己。 向 POST /api/mcp/oauth/register 提交注册请求（RFC 7591），拿到一个客户端标识。注册出来的是公开客户端，也就是没有客户端密钥的那一类，身份靠 PKCE 证明。这个注册端点按 IP 限流，每小时最多 10 次尝试。

4. 浏览器被打开。 客户端把你带到 GET /api/mcp/oauth/authorize，这个端点再把你转到面板自己的授权页面 /mcp/connect。没有登录态的话先去登录，登录完自动回到同一个授权页。

5. 你点确认。 需要的话勾上"仅授予查看权限（不能下单）"这个复选框。

6. 客户端把授权码换成令牌。 向 POST /api/mcp/oauth/token 发请求，用授权码加 PKCE 校验值换取访问令牌。这里强制 S256：plain 方式的 PKCE 会被直接拒绝，这是 OAuth 2.1 的规定，不是可配置项。PKCE 校验值本身的长度必须在 43 到 128 个字符之间。

发现文档里明确声明的能力包括：response_types_supported 只有 ["code"]，grant_types_supported 是 ["authorization_code", "refresh_token"]，token_endpoint_auth_methods_supported 是 ["none"]（因为是公开客户端），code_challenge_methods_supported 只有 ["S256"]，另外还声明了 authorization_response_iss_parameter_supported（RFC 9207，防混淆攻击）和 resource_indicators_supported（RFC 8707，令牌绑定到指定资源）。

还有一个容易被忽略但很关键的细节：这些地址是按请求自身的域名生成的。 也就是说，子面板的客户从自己那个域名连过来时，颁发方也是那个域名，主面板的地址对他完全不可见。白标不会因为接了 AI 助手而漏掉。

回调地址的限制

注册时提交的 redirect_uris 不是随便填的。接受三类：https 地址、回环地址上的 http（127.0.0.1 或 localhost）、以及自定义协议（比如 cursor://、vscode://）。指向远程主机的明文 http 一律拒绝。

换令牌时，回调地址必须和注册时登记的那一份匹配。唯一放宽的地方是回环地址的端口号可以不同，这是 RFC 8252 对本机应用的通行做法，因为桌面客户端每次启动监听的端口不固定。

什么时候用 API 密钥连接反而更合适？

服务器接受三种 Bearer 值：pf_mcp_ 开头的 OAuth 访问令牌、pf_live_ 开头的开发者密钥，以及 64 位十六进制的旧版分销密钥。X-Api-Key 请求头也认。走的是哪条路，只看前缀。

对比项	OAuth 2.1	API 密钥
要不要复制粘贴密钥	不用	要
需不需要浏览器	需要（授权那一次）	不需要
有效期	访问令牌 8 小时，自动续	直到你手动吊销
能不能只给查看权限	能	不能，始终是完全权限
在面板里能看到连接记录吗	能，还能一键断开	看不到，要靠重新生成密钥来切断
适合谁	桌面客户端、日常对话	服务器脚本、无界面环境

这张表里最实际的一行是权限范围：密钥连进来的会话永远是完全权限，"仅查看"这个限制只在 OAuth 这条路上有意义。所以如果你想给某个助手一个纯粹的只读窗口，必须走 OAuth，不能给它密钥。

密钥这条路的优势在于它不需要一个人坐在浏览器前面点确认。跑在服务器上的脚本、定时任务、群里的机器人，这些场景里根本没有浏览器可用，密钥是唯一可行的方式。密钥在 /zh/dashboard/api 页面创建，那个页面同时也是开发者接口的入口。

关于密钥本身的安全性，有一点值得强调：面板数据库里存的不是密钥原文。 所有这些凭据（授权码、访问令牌、刷新令牌、API 密钥）落库时都只保留 HMAC-SHA256 摘要，明文任何地方都不留。所以密钥丢了就是丢了，没人能替你找回来，只能重新生成一把。

授权页面上你看到什么，你确认的又是什么？

授权页面的地址是 /mcp/connect，它只在客户端发起的流程里才有意义，直接打开是没用的，这个页面也不被搜索引擎收录。它是整条链路里唯一一处由你本人做决定的地方，所以值得逐行看一遍。

页面顶部的标题是 "{客户端名称} 请求连接你的账户"，其中的客户端名称来自客户端在动态注册时提交的名字。副标题写着"确认后，该应用可以代表你执行以下操作。"

页面上会显示四组信息：

• "账户"：将被授权的账户邮箱。如果你有多个账户，这一行是你确认没连错号的唯一依据。
• "将跳转到"：授权完成后浏览器会被送去的回调地址。
• 权限列表：这次授权会给出去的能力。
• "仅授予查看权限（不能下单）"：一个复选框，勾上就把写入类工具整体关掉。

底部是两个按钮："确认连接" 和 "拒绝"。点确认之后按钮会变成"正在跳转…"，然后浏览器回到客户端。

有三条使用建议：

看清客户端名称。 这个名字是客户端自己报的，面板原样显示，不做核实。你在一个自己没发起过任何操作的时刻突然看到这个页面，正确的动作是点"拒绝"。

看清账户邮箱。 尤其是你既有主面板账户又有某个子面板账户的时候，两边的登录态是分开的，很容易在错误的域名上完成授权。

看清回调地址。 桌面客户端通常回到 127.0.0.1 上的某个端口，或者一个自定义协议。看到一个你不认识的远程域名就停下来。

如果你在这个页面上看到的是 "连接请求无效或已过期，请从客户端重新开始。"，说明授权码超过了有效期，或者客户端根本没注册。这个提示不代表你的账户有问题，回到客户端重新发起一次就行。

"仅查看"权限到底关掉了什么？

系统里一共只有两种权限范围：account:read 和 account:write。客户端如果什么都不指定，两个都会给。你在授权页面勾上"仅授予查看权限（不能下单）"，拿到的令牌就只带 account:read。

关键在于这个限制是怎么实现的：服务器不是在你调用写入工具的时候拒绝你，而是从工具清单里把它们整个拿掉。只读连接调 tools/list，返回的就是 12 个工具，那 6 个写入工具在这台服务器上根本不存在。

这个选择是有意的。如果只是在说明文字里写一句"这是只读连接，不要下单"，那么遵不遵守就取决于模型的自觉，而这在花真钱的场景里不是一个可接受的保证。把工具从清单里删掉，模型连想调都没有可调的对象。

除此之外，服务器还会在给模型的说明里追加一段提示，大意是：这个连接是只读的，下单、取消和补充的工具在本次会话中不存在；用户想下单的话，请告诉他需要在面板里去掉"仅查看"权限并重新连接。这样模型不会反复尝试一个不存在的工具，也不会编造失败原因。

能力	完全访问	仅查看
查余额、查订单、查补充记录	有	有
搜索服务、看服务详情	有	有
价格预览（preview_order）	有	有
下单（create_order、create_orders_bulk）	有	无
取消订单、申请补充	有	无
增删 webhook	有	无
工具清单里的工具数	18	12

注意 preview_order 落在只读那一侧。这意味着即使是只读连接，助手照样能帮你把价格算清楚、把几个服务比出来，只是最后那一下要你自己回面板去点。对于"我只想让 AI 帮我做功课，不想让它碰钱"的用法，这个组合正好。

还有一个细节：客户端有时会顺手申请一些和本系统无关的权限范围，比如 openid、profile、email。这些不被识别的范围会被静默丢弃，不会导致授权失败，也不会给出任何多余的能力。

助手按什么顺序帮你下一单？

服务器给模型的说明里规定了一条固定的下单流程，模型必须按这个顺序走。这不是建议，是写进服务器指令里的硬要求。

1. 搜。 用 search_services 按平台、分类或关键词找到合适的服务，记下服务编号。
2. 读。 用 get_service 读细节：最小/最大数量、是否支持补充和取消、平均耗时，以及这个服务必须填哪些字段。
3. 算。 用 preview_order 计算金额，把返回的 charge（本单费用）和 sufficient_balance（余额够不够）明确告诉你。
4. 等你点头。 说明里写死了一句话：没有你的明确同意，不许调用 create_order，因为下单花的是真钱且不可撤销。
5. 下单。 调 create_order，把返回的订单号报给你。

一段真实形态的对话大致是这样（下面的服务名和金额都是举例说明，不是面板上的实际报价）：

你： 我想给这条 Instagram 帖子买 1000 个赞，要有补充保证的。

助手： 我找到 3 个带补充保证的 Instagram 点赞服务，价格分别是 A、B、C，最小数量都低于 1000。你倾向哪一个？

你： 用最便宜的那个。

助手： 好。这个服务最小 50、最大 20000，标注支持补充，不支持取消，平均耗时字段为空。1000 个的费用是 X 美元，下单后余额会剩 Y 美元，余额充足。确认下单吗？

你： 确认。

助手： 订单已创建，订单号 #123456。

值得注意的是第 3 步里两个字段的用法。charge 是这一单的实际扣款，不是单价乘数量的心算结果；sufficient_balance 是服务器算出来的布尔值，不需要模型自己去比较余额和金额。这两个字段的存在，就是为了让模型不去做算术。

金额有一个技术细节也写进了模型指令：所有金额以美元返回，而且是十进制字符串，模型被要求不要转成浮点数再四舍五入。原因很实际，浮点数会让 0.0345 变成 0.034499999，报给你的价格就不对了。

如果余额不够，preview_order 这一步就会告诉你，不会等到下单失败。这时候助手能做的只是提醒你去充值，它自己没有充值的能力。

读价格时最容易犯的错：per_1000 和 per_order 的区别

这是整篇文章里最值得你记住的一段，因为它对应的是面板上金额差一千倍的那类事故。

服务返回的价格里带一个 pricing.unit 字段，只有两个取值：

• per_1000：价格是每一千个的价格。买 1000 个就是这个数，买 5000 个是它的五倍。
• per_order：价格是整个订单的总价，不再除以 1000。

后一种通常出现在打包类服务上，也就是那种最大数量等于 1、一次只能买"一份"的服务。面板界面在这类服务上仍然沿用"每千个价格"的文案和 /1000 后缀，这是个已知的历史包袱，本文引用的另一篇指南里也讲过。

服务器在给模型的指令里专门写了一句：看漏这个区分会把金额算错一千倍。 这条提醒的存在本身就说明它有多容易犯。

对你的实际意义是：永远以 preview_order 返回的 charge 为准，不要以你或助手心算的单价为准。 那个字段是服务器算的，它已经处理过计价单位、批次数、你账户的价格系数等等所有因素。

场景	pricing.unit	标价 22 的含义	买"1000 个"实际扣款
普通粉丝/点赞服务	per_1000	每 1000 个 22 美元	22 美元
打包类服务（最大数量为 1）	per_order	整个套餐 22 美元	不适用，只能买 1 份，22 美元

判断方法和在面板界面上一样：看数量范围。最小和最大都是 1 的，就是打包价。助手拿到的 get_service 结果里同时包含最小/最大数量和 pricing.unit，所以它有足够的信息做出正确判断，前提是它真的去调了这个工具。

如果助手在没调 get_service 的情况下直接报了一个价格，那是它在猜。让它重新查一遍，或者你自己在 /zh/services 上核对。

批量下单、分批发送和特殊服务类型在助手里怎么处理？

MCP 工具的参数名和开发者接口完全一致，所以特殊类型的服务在这里也是用同一批参数名传的，不需要记两套词汇。

需求	用哪个工具	关键参数
一次下多单	create_orders_bulk	orders 数组，最多 50 条
分批发送（drip feed）	create_order	runs（批次数）、interval（间隔分钟）
自定义评论	create_order	comments，每行一条，不传 quantity
订阅类（自动播放/自动点赞）	create_order	username、posts（1 到 100）、min、max
提及类	create_order	username 或 usernames（每行一个）
话题标签类	create_order	hashtag 或 hashtags
投票	create_order	answer_number
群组邀请	create_order	groups，每行一个
SEO 类	create_order	keywords，每行一个
需要媒体链接的类型	create_order	media

有三条规则需要单独说：

评论类服务不传数量。 服务器指令里写得很直白：评论类服务不发送 quantity，每行写一条评论，行数决定数量。你贴 300 行，就是 300 条评论的钱。这一点和面板界面上的行为一致，粘贴之前自己数一下。

分批发送只对支持它的服务有效。 runs 和 interval 这两个参数只在服务标记了支持 dripfeed 时才起作用。想筛选这类服务，可以让助手在 search_services 里把 dripfeed 设成 true。节奏控制到底能带来什么、不能带来什么，/zh/blog/instagram-fenpi-fasong-zidong-fuwu 讲得更细。

别去猜字段。 每个服务需要哪些字段由 get_service 返回的 fields 列表说明，这是设计上的单一事实来源。工具说明里对模型的原话是：调用 create_order 之前先看这个列表，不要凭猜测填字段。

关于批量下单还有一个操作上的建议：create_orders_bulk 的每一条都是独立结算的，一条失败其余照常执行。这个特性很好用，但它也意味着没有整体回滚。50 条里有 30 条成功、20 条因为余额不足失败，那 30 条已经扣钱了。所以数量大的时候，先让助手把每一条过一遍 preview_order，把总金额加出来，再决定要不要提交。

助手做不到的事有哪些？

这一节是硬边界。下面每一条都不是"默认关闭的开关"，而是工具层面就不存在的能力。

不能充值。 面板的余额充值走支付渠道，MCP 工具里没有任何一个能触发它。助手最多告诉你"余额不够，请去充值"。

不能提现，不能转账。 同理。

不能改价格。 服务的价格、你的价格系数、子面板的加价倍率，这些都属于管理面，用户服务器碰不到。

不能开工单。 客服工单必须你自己在面板里提交。这一点在服务器指令里也写了：遇到需要人工处理的情况，把用户引导回面板。

看不到你的密码。 密码从来不经过 OAuth 流程，客户端拿到的只有一枚令牌。

访问不了其他账户。 服务器在每次请求里都绑定到单一账户，这是结构性的，不是权限判断。

不能取消不支持取消的订单。 取消能力来自服务本身，服务没有的话工具会返回 cancel_not_supported。

不能给不带补充保证的订单申请补充。 同理，refill_order 只对已完成且有补充保证的订单有效。

不能替你判断掉量是否会发生。 掉量和补充保证的覆盖范围是服务属性，助手能读出来告诉你，但它不能保证结果。这方面的逻辑在 /zh/blog/follower-drop-and-refill-guarantee-explained 里有完整拆解。

还有一条不是"做不到"而是"不该期待"的：助手不会替你判断某个服务的质量好不好。 它读到的是目录里的结构化数据（价格、限额、是否有保证、平均耗时），不是别人的实测结果。真正判断一个服务好不好用的方法只有一个，就是自己用最小数量跑一单然后观察。

安全：你的密码、令牌和有效期

整套凭据体系里有五种秘密，前缀不同、寿命不同。

秘密类型	前缀	有效期
授权码	pf_mca_	10 分钟，一次性
访问令牌	pf_mcp_	8 小时
刷新令牌	pf_mcr_	90 天，每次使用后轮换
客户端标识	mcpc_	不过期
开发者 API 密钥	pf_live_	直到手动吊销

它们都是 32 字节（256 位）的随机值，用 base64url 编码。

数据库里只存 HMAC-SHA256 摘要，明文不落库。 计算摘要用的密钥（pepper）来自服务端配置，不在数据库里，所以即使有人拿到了整个数据表，也无法反推出可用的令牌。

有一条防御机制值得单独讲：授权码是一次性的，重放会触发连锁吊销。 如果同一个授权码被用第二次，或者一个已经被吊销的刷新令牌又送上来了，服务器不会只拒绝这一次请求，而是把这个客户端在这个账户下的全部令牌一并吊销。这是 OAuth 2.1 对公开客户端的推荐做法：出现重放通常意味着凭据泄露，与其猜哪一边是攻击者，不如全部作废让双方重新授权。

对你来说这个机制的可见后果是：某个客户端突然全面失效并要求重新授权时，不一定是 bug，可能是它在某种异常状态下重复使用了凭据。重新走一遍授权流程就恢复了。

刷新令牌的轮换也值得注意：每次用它换新的访问令牌，它自己也会被换掉。这意味着你不能把刷新令牌复制到两个地方同时用，第二个用的那一方会触发上面说的连锁吊销。

传输层是怎么工作的，为什么浏览器打开会看到 405？

这一节是给会去看请求细节的人准备的，日常使用可以跳过。

面板的 MCP 服务器用的是 Streamable HTTP，无状态的 JSON-RPC 2.0。无状态的意思是服务器不保存会话标识，每一个请求自带完整身份，处理完就结束。这样部署简单，也不会出现"会话过期了但令牌还有效"这种别扭状态。

支持的方法有：initialize、tools/list、tools/call、prompts/list、prompts/get、ping，以及 resources/list 和 resources/templates/list（这两个返回空列表，因为这台服务器不提供资源，只提供工具和提示词）。

没有 SSE 流。 对这个地址发 GET 请求会得到 HTTP 405，响应里写着 SSE 不受支持、请用 POST 发 JSON-RPC。所以你在浏览器地址栏里粘贴这个地址然后看到 405，是正常的，不是服务挂了。

协议版本方面，服务器原生说的是 2025-06-18，同时向下兼容 2025-03-26 和 2024-11-05，具体用哪一版在 initialize 那一步协商。

其他几个实现细节：

• 支持 JSON-RPC 批量请求（请求体是数组）。如果一个请求体里全是通知（不需要回复的消息），服务器返回 HTTP 202 且没有响应体。
• 工具报错不是协议错误。 一个工具失败时，返回的是带 isError: true 标记的文本内容，而不是 JSON-RPC 层的错误。这样模型能读到错误信息并自我纠正，比如看到"数量超出允许范围"就知道去改数量，而不是整个调用链断掉。
• 工具输出在 100000 字符处截断，防止一次超大响应把模型的上下文撑爆。
• 每个工具在 tools/list 里都带 readOnlyHint 和 destructiveHint 两个提示。 写入但不具破坏性的是 refill_order 和 create_webhook；标为破坏性的是 create_order、create_orders_bulk、cancel_order 和 delete_webhook。有些客户端会用这两个标记来决定要不要弹二次确认。

每一次调用都留痕：审计日志记了什么？

每一次工具调用都会写进 aiAuditLog 表，字段包括：客户端（取自 User-Agent）、账户标识、工具名、传入参数、返回结果、错误信息和耗时。

有几条规则决定了它记什么、不记什么：

参数里像是秘密的字段会被打码。 名字里含有 apikey、api_key、secret、password、passphrase、token 的字段，值一律替换成 *** 再落库。

只读工具的返回结果不记。 一次服务搜索能返回几十条记录，把它们全存下来体积巨大而价值很低。写入类工具的返回结果则会完整记录，因为那才是需要事后追溯的部分。

参数和结果的 JSON 在 8000 字符处截断。

写日志是尽力而为的。 日志写失败不会影响主流程，你的订单该下还是会下。这个取舍的方向是明确的：宁可丢一条日志，也不能因为日志系统的问题让一笔正常订单失败。

这套记录带来的实际好处是：一笔订单到底是通过 AI 助手下的还是你自己在面板里点的，事后能查出来。 用户服务器和管理服务器写的是同一张表，区别在于账户标识这一列是不是有值。对于团队协作或者需要对账的场景，这一点比它看起来重要。

怎么查看已连接的助手，怎么断开？

/zh/dashboard/mcp 页面最下面的那张卡片叫 "已连接的助手"，一个都没有的时候显示"还没有已连接的 AI 助手。"

连上之后，每一个客户端占一行，行上有五样东西：

1. 客户端名称，来自它注册时报的名字。
2. 权限标记，两种取值："完全访问" 或 "仅查看"。
3. "连接于" 后面跟着授权日期。
4. "最近使用" 后面跟着最后一次调用工具的日期，从来没用过的显示 "从未"。
5. 一个 "断开连接" 按钮。

点断开会先弹一个确认框："该助手将失去对你账户的访问权限。要继续吗？" 确认后显示 "已断开连接。"，失败则是 "断开连接失败。"

这张列表有两个非常实际的用途。

第一个是对账。 "最近使用"这一列能告诉你哪些连接其实早就不用了。装过一次没再碰的客户端留在那儿没有意义，断掉就是了。

第二个是发现异常。 一个你不记得授权过的客户端名字出现在列表里，或者某个连接的"最近使用"时间明显对不上你的实际使用，这就是要立刻断开的信号。断开是即时生效的，不需要等令牌过期。

除了界面上这一下，协议层面也有对应的吊销端点 POST /api/mcp/oauth/revoke，客户端可以在自己被卸载时主动调用它。两条路的效果是一样的。

顺带提醒：用 API 密钥连的助手不会出现在这张列表里。密钥连接没有"连接记录"这个概念，要切断它只能去 /zh/dashboard/api 重新生成密钥，而重新生成会让所有在用这把密钥的程序同时断掉。这是选择密钥而不是 OAuth 的代价之一。

自动化：事件流和 webhook 怎么配合助手？

助手不会主动盯着你的订单。它只在你问的时候去查。想要"状态一变就知道"，靠的是事件流和 webhook 这两样东西。

系统里定义了八种事件类型，名字不翻译：

事件类型	什么时候发生
order.created	订单创建
order.processing	订单进入执行中
order.completed	订单完成
order.partial	订单部分完成
order.canceled	订单被取消
order.updated	订单信息变化
refill.created	补充申请创建
refill.updated	补充申请状态变化

两种消费方式：

拉（list_events）： 助手带着游标去读事件流，从旧到新，可以按类型筛选。适合没有固定公网地址的人，比如在本地开发、家里没有固定 IP、或者压根不想搭服务的。你直接问助手"我上次问过之后有什么变化"，它读一遍事件流就能答。

推（webhook）： 用 create_webhook 注册一个 https 地址，选好要订阅的事件类型（留空就是全部）。之后事件发生时系统会 POST 到那个地址。创建时返回的签名密钥只显示一次，助手把它报给你之后就再也调不出来了，当场存进密码管理器。用 delete_webhook 删除时，还没发出去的推送也会一起丢弃。

两者不冲突，很多人是两个都用：webhook 负责触发自己那一侧的自动化，事件流负责在需要复盘时提供一份完整的时间线。

关于签名密钥再多说一句：它的用途是让你验证收到的推送确实来自面板，而不是别人伪造的。收到推送后按文档描述的方式校验签名，校验不过就丢弃。具体做法写在 /zh/api-docs。

三个内置指令：order_status、find_service、reorder

除了工具，服务器还提供三条预置指令（协议里叫 prompts）。支持这个特性的客户端会把它们显示成可以直接点的快捷命令，通常是一个斜杠菜单或者一排按钮。

指令	做什么	参数
order_status	汇总最近的订单，标出卡住的和没跑满的	count（默认 10）
find_service	针对一个需求比较 3 到 5 个服务并算价，不下单	request（必填）、quantity（可选）
reorder	按一笔历史订单的参数重新下一单，下单前征求确认	order_id（必填）

order_status 展开后是一段指示，让模型去调 list_orders，把订单一条条列出来：编号、服务名、状态、数量、剩余量、金额，并且单独强调没完成的和有供应商错误的那些，还要说明每一笔可以怎么处理（取消、补充，还是继续等）。

find_service 是三条里最实用的一条。它让模型搜出候选服务，把最合理的 3 到 5 个按价格、最小/最大数量、补充保证和平均耗时排成一张对比表。给了数量参数的话，还会顺便对最合适的那个跑一次价格预览。这条指令明确写着不许下单，只出选项和金额，决定权留给你。

reorder 先用 get_order 把原单读出来，用同样的服务、同样的链接、同样的数量跑一次价格预览，把当前的金额给你看（价格可能已经变了），等你确认后再下单。它还带一条提醒：如果同一条链接上还有正在进行的订单，先警告你。

最后这条提醒对应的是面板里一个真实存在的限制：同一条链接同时只能跑一笔单。 供应商那一层按链接加锁，撞上了订单会被拒。所以复制一笔旧单之前，先确认上一单跑完了。

分销商和子面板所有者需要注意什么？

如果你在 Panel Follows 上开了自己的白标面板，MCP 这套东西对你有三层意义。

第一，你自己的客户也能连。 子面板的用户在你的域名上看到同样的 "AI 助手" 页面，走同样的授权流程。这是自动的，你不需要做任何配置。

第二，主面板的地址不会漏出去。 这是设计上专门处理过的：OAuth 的颁发方标识、发现文档里的各个端点地址，全都按请求自身的域名生成。你的客户从 panel.example.com 连过来，他看到的每一个地址都是 panel.example.com，Panel Follows 这个名字不会出现在他的客户端配置里。白标是完整的。

第三，账户绑定在域名上。 子面板的账户只在那个子面板的域名下有效。你的客户如果误把主站的地址填进客户端，会一直登录不上，而错误提示看不出原因。这一点值得写进你给客户的说明里。

对做代理业务的人还有一个更直接的用法：你自己就是那个连助手的人。一个手上有几十个客户账号的代理，日常最花时间的事情是"这个客户的单跑完没有"、"那个客户的补充申请通过了吗"。这些查询用对话来做，比在界面上翻页快得多。想把这类流程理顺，/zh/blog/social-media-agency-scaling 和 /zh/blog/smm-mianban-fenxiao-cong-ling-kaishi 两篇里有更成体系的做法，白标面板本身的商业模式写在 /zh/child-panel。

需要提醒的是：MCP 工具管的是你自己账户里的订单和余额，不是你面板的管理功能。 给客户改加价倍率、审核客户的充值、看你面板的收入，这些都在"我的面板"页面里，不在助手能碰的范围内。

面板所有者那一侧：57 个工具的管理服务器

这一节和普通用户没有关系，写出来只是让你知道同一套协议在另一侧也在用。

管理服务器的地址是 POST /api/mcp，用一把服务端密钥鉴权，提供 57 个工具，覆盖总览与搜索、用户、订单、订单申请、服务、分类、供应商、支付、工单、优惠券和设置。密钥没配置时这个端点完全关闭，返回 HTTP 503。

它有几条内建的保护：最后一个活跃管理员不能被降权也不能被封禁；涉及金额的操作都在事务加行锁里完成，保证原子性；每一次调用同样写审计日志。

对你唯一有意义的信息是：面板的运营方在用一套有记录、有约束的接口管理系统，而不是随手改数据库。你在助手这一侧看到的那些约束（先查价再下单、错误码固定、调用留痕），在管理侧是同一套工程习惯的产物。

MCP、API 还是面板界面？什么时候用哪个

三条路访问的是同一套数据，选哪一条取决于你在做什么。

场景	选哪个	为什么
第一次下单，还不熟悉目录	面板界面	表单会按服务类型自动变化，看得见
想在几个服务之间比价	MCP	一句话拉出对比表，比翻页快
例行查订单状态	MCP	问一句就行，不用登录翻页
一次要下几十上百单	开发者接口或 MCP 批量工具	界面上的批量下单只支持默认表单
要接进自己的系统	开发者接口	能力最全，可编程，/zh/api-docs
想让别人只看不动	MCP 的"仅查看"	唯一能做到只读的方式
充值、提现、开工单	面板界面	另外两条路都没有这些能力
改子面板设置	面板界面	管理功能不在用户工具里

一个常见的组合是：用 MCP 做决策，用界面做敏感操作，用开发者接口做规模化。 助手负责把选项和金额摆清楚，你在对话里确认小额订单；充值和结算这类事情回到面板里点；真正跑量的批处理交给脚本。

如果你的用法更偏向后者，那么值得直接去看 /zh/smm-panel-api 和 /zh/api-docs，MCP 只是那套接口的一层对话式外壳，参数名都是一样的，学一遍两边都能用。

请求限额：600 次是怎么算的

每个账户每分钟 600 次请求。 这个上限和开发者接口共用，也就是说同一个账户从 MCP 打过来的请求和从 HTTP 接口打过来的请求算在同一个池子里。超了返回 HTTP 429，响应头里带 Retry-After: 60。

除此之外，接口层还有一道按 IP 的限制，每分钟 900 次。

日常对话完全碰不到这个数字。一次典型的下单流程也就是四五次调用：搜服务、看详情、算价、下单，加上可能的一次查余额。真正会撞上限额的是脚本，尤其是那种在循环里不停轮询订单状态的写法。

如果你确实在写轮询，正确的做法是用事件流代替轮询：list_events 带游标往前走，只拿变化的部分，比反复调 get_order 省得多，信息还更完整。

故障排查：常见报错和它们的真实含义

现象	原因	怎么办
401 invalid_token	访问令牌的 8 小时到期了	客户端会用刷新令牌自动续；不续的话去面板重新连接
浏览器里打开显示 405	用 GET 试图建立 SSE 流	协议只接受 POST，这是正常行为
429	每分钟 600 次的限额超了	按 Retry-After 的秒数等一等，或者改用事件流
"连接请求无效或已过期，请从客户端重新开始。"	授权码超过 10 分钟，或客户端没注册	回到客户端重新发起授权
令牌端点返回 400	客户端发的是 plain 方式的 PKCE	只接受 S256，这是 OAuth 2.1 的硬要求
回调地址被拒绝	redirect_uri 和注册时登记的对不上	唯一放宽的是回环地址的端口号
端点返回 503	管理服务器没配置服务端密钥	只和面板所有者有关，用户侧不受影响
提示账户不存在	子面板的账户只在那个面板的域名下有效	用你注册时用的那个域名
助手看不到下单工具	这条连接是"仅查看"的	在面板里断开，重新授权时不勾那个复选框
助手说余额不足	preview_order 返回 sufficient_balance 为假	去面板充值，助手没有充值能力

再补两条不算报错但经常被当成报错的情况：

助手报的价格和你心算的不一样。 先确认它调没调 preview_order。那个字段是服务器算的，包含了计价单位、批次数和你账户的价格系数，比任何心算都准。

订单长时间停在"待处理"。 这不是 MCP 的问题，是订单送到供应商那一步出了状况。面板在这种情况下不会自动退款，订单会一直挂着而钱已经扣了。正确的动作是去面板开一张工单，让管理员重新发送或者判定退款。助手在这里能做的只有把状态读给你听，它开不了工单。

第一周的上手路线

如果你现在就想接上，按这个顺序走，一周之内能把它变成日常工具。

1. 先用只读连接。 第一次授权时勾上"仅授予查看权限（不能下单）"。这样即使客户端出什么岔子，最坏的结果也只是它读了一遍你的订单列表。
2. 让它做一遍功课。 问它"帮我比较一下 Instagram 粉丝服务里带补充保证、最小数量低于 500 的那几个"，看它给出的表准不准，和你在 /zh/services 上看到的对不对得上。
3. 让它算一次价。 只读连接照样能用 preview_order。给它一个具体数量，让它报出 charge，然后你自己去面板下同一单，核对两个金额是否一致。
4. 确认无误之后再升级权限。 回到 /zh/dashboard/mcp 断开这条连接，重新授权一次，这次不勾只读。
5. 第一单用最小数量。 目标选一个你不介意的账号或一条不重要的帖子。全流程走一遍：搜、看详情、算价、确认、下单、记订单号。
6. 回面板核对。 在"我的订单"里找到这一单，确认服务、链接、数量、金额都对得上。这一步是在验证助手没有在中间理解错什么。
7. 观察一周。 看订单跑完的情况，试着让助手用 get_order 报进度，和界面上的数字比对。
8. 最后再考虑自动化。 事件流和 webhook 属于第二阶段的事，先把手动对话这一层跑顺。

这个流程会花掉你几天时间和几美元，但它测的不是"MCP 能不能连上"，而是"我能不能信任这条链路上的每一个数字"。这个信任建立起来之后，后面每一次对话都会省事很多。

常见问题

MCP 到底是什么，用一句话说清楚

MCP 是一个开放协议，规定了 AI 助手和外部系统之间怎么互相介绍能力、怎么调用功能、怎么返回结果。在这个面板上，它的具体表现是你把一个地址加进 Claude 或 ChatGPT 这类客户端，助手就获得了 18 个工具，可以帮你搜服务、算价格、查订单、下单和申请补充。你不需要写代码，也不需要看接口文档。

我需要把面板密码告诉 AI 助手吗？

不需要，而且系统结构上也不允许。授权是在面板自己的页面上完成的，你在自己的登录态下点"确认连接"，客户端拿到的是一枚有期限的令牌，不是密码。页面上写得很清楚："授权在本面板完成，密码绝不会交给客户端。"用 API 密钥连接的方式同样不涉及密码，密钥可以随时在面板里重新生成。

助手会在我不知情的情况下下单吗？

正常流程下不会。服务器给模型的指令里明确规定，调用下单工具之前必须先算出金额并取得你的明确同意，因为下单花的是真钱且不可撤销。如果你想要更硬的保证，就在授权时勾上"仅授予查看权限（不能下单）"，这样下单工具在那条连接上根本不存在，不是被禁止调用而是清单里没有。

哪些 AI 客户端能用？

任何支持 MCP 的客户端都可以，面板页面上的原话是"支持 OAuth 2.1 的 MCP 客户端都可使用"。页面里直接给了 Claude Code 的命令行写法和 Cursor、VS Code 的配置片段。不支持 OAuth 但能自定义请求头的客户端，可以改用 API 密钥的方式连接，写法也在同一张卡片里。

怎么断开连接，断开之后会怎样？

去 /zh/dashboard/mcp 页面，在"已连接的助手"卡片里找到那一行，点"断开连接"，在确认框里点继续。断开是立即生效的，那个客户端会立刻失去对你账户的访问权限，已经下过的订单不受影响，照常执行。想重新连的话再走一遍授权流程就行，不需要联系客服。

访问令牌有效期多久，是不是每天都要重新连？

访问令牌 8 小时到期，刷新令牌 90 天有效并且每次使用后轮换。正常情况下客户端会在访问令牌过期时用刷新令牌自动续，你什么都不用做。只有在连续 90 天没用过、或者你自己在面板里断开过的情况下，才需要重新走一次授权。

助手能帮我充值吗？

不能。充值、提现、修改价格和提交工单这四件事在工具层面就不存在，不是权限没开。助手最多能通过 get_account 读出你的可用余额，或者在价格预览返回余额不足时提醒你去充值。真正的充值动作必须你自己在面板的充值页面完成。

我该用 API 密钥还是 OAuth？

有浏览器可用、想随时能一键断开、或者想给出一条只读连接的，用 OAuth。跑在服务器上的脚本、定时任务、没有界面的机器人，用 API 密钥。最关键的区别是权限：密钥连进来的会话永远是完全权限，"仅查看"这个选项只在 OAuth 这条路上存在。

助手下的单能在面板里看到吗？

能，完全一样。助手下的单和你在界面上点出来的单进的是同一套订单系统，在"我的订单"页面里并排显示，状态、退款、补充的逻辑没有任何区别。除此之外每一次工具调用还会写进审计日志，所以事后能查出某一笔订单是通过 AI 助手下的还是在面板里手动下的。

子面板的客户也能连自己的助手吗？

可以，而且流程完全一样，页面在他们自己面板的域名下。系统会按请求的域名生成所有 OAuth 地址，所以他们的客户端配置里只会出现你的域名。需要注意的是账户和域名是绑定的：子面板的账户只在那个子面板的域名下有效，填错地址会一直连不上。

某个工具报错了会发生什么？

工具报错不会让整个连接断掉。服务器把错误当成一个带标记的正常返回值交给模型，模型能读到错误码和消息，然后自己纠正，比如看到数量超范围就去改数量。错误码是固定的（比如 insufficient_balance、quantity_out_of_range），消息是你的语言，模型被要求原样转述而不是自己编一个解决方案。

用 MCP 要另外付钱吗？

不用，除了订单本身的费用之外没有额外收费。通过助手下的单和你在面板上点出来的单价格完全一样，既不加价也不打折。它就是访问同一个账户的另一种方式，和你用手机浏览器还是电脑浏览器打开面板是一个性质的区别。

还有问题的话

这篇讲的是 MCP 这条链路本身。面板的日常操作、充值方式、订单状态的含义这些内容在 /zh/blog/panel-follows-shiyong-zhinan 里；偏商务的问题，比如交付时间和退款规则，/zh/faq 上有一份常年更新的问答。想直接对接程序的话，/zh/api-docs 是完整的开发者文档，参数名和这里的工具参数一一对应。

最后重复三句话：第一次连接就勾上"仅查看"；下单前看清 preview_order 报出来的 charge；不用的连接及时在 /zh/dashboard/mcp 里断掉。做到这三点，把 AI 助手接进账户这件事就只剩下方便，没有额外风险。