WorkBuddy 接入 ChatCut：通了，卡在最后一步

你是不是也遇到过

MCP 现在是个热词，但真正动手接的时候，卡点往往不在”填什么”，而在”这个软件的入口长什么样”。

同一件事，千问办公是在设置里填一张表单；WorkBuddy 却是让你直接改一个 JSON 文件。走错一步就找不到北。

这篇拿 ChatCut（一个能用自然语言剪视频的 AI 剪辑工具）当例子，把 WorkBuddy 的 MCP 接入全流程走一遍。全程截图，配置可以直接抄。

先说结论，免得你看到最后：

• 配置、信任、授权三步全部成功——照抄就能连上；
• 但工具没能注册进会话，模型调不到 list_projects，所以”读一个真实项目""做一条 5 秒标题视频”这两项验证没跑通；
• 卡点我查到了确切的日志证据，在文末，不是你的配置写错了。

先认识一下：WorkBuddy 的 MCP 入口在哪

打开 WorkBuddy，左侧导航栏找到 「专家·技能·连接器」，进去后切到顶部的 「连接器」 标签页。

右上角那个 「自定义连接器」 就是入口。注意：这里同时列出的是 WorkBuddy 官方市场里的连接器（腾讯文档、飞书、钉钉……），我们要加的是自己的，所以走”自定义”。

第一步：看清你的 MCP 现状

点「自定义连接器」，弹出 MCP 服务管理 面板。

本次接入前，这台机器上已经有 7 个 MCP（xhs-mcp、douyin-mcp、wechat-mcp、rss-mcp、weibo、gitee、bilibili-mcp），全部是关闭状态。

这一步值得单独截图留档。加新 MCP 时最怕的就是把原有的配置覆盖掉——先看清有几个，加完之后对得上数，就不会出事。

第二步：点「配置 MCP」，你会看到一个 JSON 编辑器

这是 WorkBuddy 和千问办公最大的差别。

千问办公给你一张表单：填服务名、填 URL、选类型。 WorkBuddy 直接把你带到配置文件面前：

注意顶部那行小字——配置文件路径：/Users/你的用户名/.workbuddy/mcp.json。

也就是说，你在界面里填的东西，最终落盘就是这个文件。它的格式是 Claude Desktop 同款的 mcpServers 结构，所以你在别处写好的 MCP 配置可以整段搬过来。

第三步：把 ChatCut 加进 JSON

因为编辑器里显示的是整个文件（包含已有的 7 个 MCP），所以正确做法是：全选 → 用加了新条目的完整 JSON 覆盖 → 保存。

需要新增的条目就这 4 行：

"chatcut-experiment": {
  "type": "http",
  "url": "https://api.chatcut.io/api/external-mcp/mcp"
}

把它插到 mcpServers 里最后一个条目的后面（注意给前一个条目补上逗号）：

看到两个信号就说明填对了：「保存」按钮从灰变黑，路径旁边冒出 「未保存」。

可选：WorkBuddy 没有”粘贴 JSON 配置”的独立入口，但整个编辑器本身就是 JSON 输入框。所以本文的流程反过来更省事——你不需要在别处拼 JSON，直接在这里编辑就行。

第四步：保存后，列表从 7 个变 8 个

保存后回到 MCP 列表，chatcut-experiment 出现在最下面。

注意右上角的状态：「0 启用 · 1 失败」，底部还有一条横幅——

首次连接此 MCP 服务需要您的信任确认。

这是 WorkBuddy 独有的第二道关卡，千问办公没有。它的逻辑是：从外部加进来的 MCP 服务，第一次连接必须由你手动点一次「信任」，否则一直算失败。

点「信任」。

第五步：浏览器弹出 ChatCut 授权页

点了信任之后，WorkBuddy 会识别出这个服务需要 OAuth，自动打开系统浏览器走授权。

页面把权限说得很清楚，值得一读：

• 访问、创建和编辑你的 ChatCut 项目
• 将你提供的媒体上传到这些项目中
• 仅在你请求或批准生成时使用积分

用你自己的 ChatCut 账号登录，确认授权。完成后页面会提示授权成功，并弹一个”要打开 WorkBuddy 吗”的系统询问——点「打开」，让授权码回传给 WorkBuddy。

这里有个不能省的习惯：不要把账号密码、Cookie、访问令牌或刷新令牌粘贴进任何 AI 对话、共享文档或截图。ChatCut 官方也要求在其浏览器授权页面上完成登录与授权，老老实实走正门。

第六步：检查连接状态

回到 MCP 列表，chatcut-experiment 的开关已经打开，显示 1 启用。

想确认得更硬一点，可以去看 WorkBuddy 的凭据文件（只看结构，别把内容复制到任何地方）。凭据是加密存储的，你能看到的只有服务名和过期时间：

python3 -c "
import json
d=json.load(open('~/.workbuddy/connectors/你的连接器ID/.credentials.v3.json'.replace('~','$HOME')))
print([k for k in d['mcpOAuth'] if 'chatcut' in k])
"

本次实测拿到了这条：

chatcut-experiment|73f9d7645bee80c7
  serverUrl  https://api.chatcut.io/api/external-mcp/mcp
  tokenType  Bearer
  scope      openid profile email offline_access
  expiresAt  1789309493275      # 带 refreshToken，可自动续期

offline_access 拿到了，说明离线刷新令牌也一并签发，不用每次重新授权。

工具验证测试

配置走完了，接下来才是真正的考验。按参考文章的做法，把验证拆成小步——先发现工具，再只读读取，最后才动手做作品，这样一失败就能立刻知道坏在哪一层。

测试 A：工具发现

在 MCP 管理页展开连接卡片看工具清单。

通过标准：客户端成功列出来自 ChatCut 的工具。

本次实测：服务端这一层是通的。 日志里连续 7 次探测都拿到同样的结果：

MCP-Inspect end configId=custom-mcp:chatcut-experiment
    totalMs=28191 openMs=769 toolsMs=25223
    tools=60 prompts=0 resources=2

tools=60——服务端确实吐出了 60 个工具，数量和参考文章里千问办公拿到的完全一致。

测试 B：真实读取项目

新建一个任务，发送这段只读测试指令：

请做一次 ChatCut 只读连接测试，使用已配置的 chatcut-experiment MCP。

实际调用 list_projects，显示最近最多 3 个项目的名称；如果有项目，
再用 read_project 读取最新一个项目的基本信息，报告名称、时间线数量
和素材数量。

请使用工具实际返回的参数格式，不要猜测字段；不支持的字段标为未知。
不要创建、切换、修改或删除项目，不要上传素材、调用生成或导出。

最后说明实际调用了哪些工具、哪些成功或失败；没有项目也可以如实报告。
不要用网页浏览或本地配置检查代替这次 MCP 工具调用。

本次实测结果：卡住了。 模型非常老实地报告了每一层：

#	调用	结果
1	ListMcpResources { server: "chatcut-experiment" }	✅ 成功，返回 3 个资源
2	mcp__chatcut-experiment__list_projects	❌ 失败：Tool not found
3	mcp__chatcut-experiment__read_project	❌ 未执行（工具不在索引里）
4	工具索引检索（多种关键词 + 精确工具名）	❌ 检索不到任何 chatcut 工具

关键在于第 1 项成功了——ListMcpResources 是真实打到 ChatCut 服务器上的调用，返回了 chatcut-followup-questions、chatcut-editor-ui 等资源。

所以连接是通的。 失败发生在第 2、3 项，而且原因不是网络也不是鉴权：本次会话的工具清单里根本没有这 60 个工具，请求压根没发出去。

三个要报告的字段，模型一个都没编：

• 项目名称：未知（未取到项目列表）
• 时间线数量：未知
• 素材数量：未知

这一点值得点名表扬。它完全可以猜一个”看起来合理”的数字糊过去，但它写的是「我不会用任何推测值填充这三项」。验收 AI 的时候，肯说”未知”比给个漂亮答案更可信。

我不死心，把 WorkBuddy 完全退出重启，又跑了一遍——结果一样：

这次它连”等一会儿再试”都做了：

#	工具	结果
1	ToolSearch（含精确名 + 多种关键词变体）	❌ 全部未命中
2	ListMcpResources	✅ 成功——服务器已连接
3	DeferExecuteTool → list_projects	❌ “Tool not found in the defer…“
4	等待重试（8s + 20s 后再次搜索）	❌ 仍无变化

测试 C：制作一个 5 秒标题作品

只读测试没通过，这一项就没有继续做——按参考文章的规矩，先证明读取，再动手做作品，不然连”坏在哪一层”都说不清。

请使用 chatcut-experiment，新建一个名为「WorkBuddy 接入实验」的 ChatCut 项目，
制作一段 5 秒、16:9 的黑底白字视频，居中显示「WorkBuddy × ChatCut 测试成功」。

在 ChatCut 时间线上完成制作，并打开项目供我播放检查。
不要修改已有项目，不使用付费 AI 生成，暂时不要导出。

通过标准（留给你在工具注册修好后自测）：

• ChatCut 中确实出现指定测试项目
• 时间线包含作品内容，播放长度为 5 秒
• 画面为 16
  ，黑底、白字、居中，文字内容正确
• 实际结果与任务要求一致，不能只凭聊天里的一句”已完成”验收

卡点在哪：日志给了确切答案

配置没错、授权没错、连接也没错。那问题在哪？

看 WorkBuddy 的握手日志（~/.workbuddy/logs/），7 次探测的记录摆在一起，规律非常明显：

探测次序	建连耗时 openMs	工具列表耗时 toolsMs	拿到工具数
1	3049 ms	23091 ms	60
2	8391 ms	43786 ms	60
3	1560 ms	31658 ms	60
4	6974 ms	14290 ms	60
5	769 ms	25223 ms	60
6	6995 ms	20619 ms	60
7	1095 ms	14765 ms	60

每一次，WorkBuddy 都打了一行 tools/list SLOW 警告。

根因一句话说清：ChatCut 这个 MCP 服务器的 tools/list（拉取工具清单）要花 14～44 秒，而 WorkBuddy 在会话启动时等不了这么久——连接建好了，工具清单却没赶在注册窗口内返回，这 60 个工具就没能注入会话。

所以模型看到的是一个”连上了但没工具”的服务器，它连尝试调用的资格都没有。这也解释了为什么同一套配置在千问办公那边能跑通——两家客户端的注册超时策略不一样。

顺便把这句也说清：WorkBuddy 目前没有给用户留调节这个超时的开关（settings.json 里没有相关项，mcp-disabled-tools.json 也是空的，排除了”工具被误禁用”）。所以这一层不是改配置能解决的，得等服务端把 tools/list 提速，或客户端放宽注册窗口。

用 WorkBuddy 接 MCP，特别提醒你三句

1. 先分清是”哪一层”断了。

MCP 出问题有三层：配置层（JSON 写错）、连接层（网络/鉴权）、工具层（工具没注册进会话）。 本次三层里前两层全绿，只有第三层挂了。如果你一上来就反复改 JSON，纯属白费功夫——JSON 没错。

2. 服务端返回 60 个工具 ≠ 你能用这 60 个工具。

界面上显示”已启用”、日志里写着 tools=60，都不等于模型真的调得到。唯一可信的验收是让模型实际调一次，并且要它报告”调了哪些工具、哪些成功、哪些失败”。本次就是靠这条规矩，才把问题精确锁到工具层。

3. 别把令牌贴进对话里。

OAuth 就该在浏览器授权页完成。凭据文件是加密存的，你去读也只能读到服务名和过期时间——这是正确设计，不需要你手动搬运令牌。

---

本次实测：配置、信任、OAuth 授权三步全部成功并通过凭据验证（scope 含 offline_access，带 refreshToken）；服务端 7 次探测均正常返回 60 个工具；但 tools/list 耗时 14.3～43.8 秒，超出会话启动的注册窗口，导致 60 个工具未注入会话工具索引，测试 B / 测试 C 未能完成。全程只做了读取，未创建、切换、修改、删除任何项目，未上传素材，未调用生成或导出。

如果你的 ChatCut MCP 在 WorkBuddy 里也卡在同一处，欢迎在评论区报一下你的 toolsMs——这个数字是不是普遍偏大，值得一起验一验。

【欢迎评论区交流你的实测体验】