MCP 连接医生

症状先说清楚

MCP 工具用起来“时好时坏”，往往不是模型抽风，而是连接器会话层出了问题。常见信号有：调用时报 not in index、工具列表突然为空、索引丢失，或者连接器管理页反复弹出本不该出现的 OAuth 自动授权窗。对 dida365、flomo 这类基于 HTTP 的 MCP server，根因通常集中在协议声明、凭证有效性和多设备会话互踢三件事上。

排查顺序与修复动作

本技能按可复现的顺序定位根因。

• 读取配置：解析 ~/.workbuddy/mcp.json，逐条核对出问题连接器的 type 是 http 还是 streamableHttp、是否声明 transport、url 是否带 /mcp 或 /sse 路径，以及 headers.Authorization 是写死的 Bearer token，还是 OAuth 残留。
• 对比稳定参照：flomo 的可用配置是 type: streamableHttp + transport: streamable-http + 裸 Bearer token。若问题连接器只有 type: http，协议声明不匹配通常是首因：服务端按 Streamable HTTP 维护会话，客户端却按老式 HTTP 建连，保活与断线恢复对不上，就会周期性掉会话。
• 直连验证凭证：关闭沙箱走主机网络，用 curl 携带同一个 Bearer token 请求服务端 OpenAPI 或 MCP 端点。返回 200 说明 token 有效，问题在连接层；返回 401/403 说明凭证过期或被踢，需要刷新或改用独立 token。
• 探测端点协议：向 url 发 initialize 请求，看服务端自报协议与响应头。若返回 application/json 和会话头，应按 Streamable HTTP 处理；若带 oauth-protected-resource 元数据，仍可能是声明 OAuth 但接受静态 Bearer 的 token 版端点。
• 修复协议错配：把 type 改为 streamableHttp，补充 transport: streamable-http，url 和 token 保持不变。这一步不会自动生效，需要在连接器管理页点 Trust，再完全退出并重启客户端，而不是只点重连。
• 验证握手与工具列表：重启后按 streamable-http 完成完整握手，用同一会话 cookie 发 tools/list；再开新对话直接调用 list_projects 或 memo_search 这类真实工具，成功返回才算根治。

容易忽略的次因与兜底

协议修好仍偶发断连时，要查是否多个设备或 AI 共用同一个 token。滴答等服务的 OAuth/token 常有单点会话约束，同 token 多端会互踢，应给每个端分配独立 token。另一个判断铁律是：只要还弹 OAuth 窗，就说明仍在走 OAuth，需要删除旧连接、完全重启、重新配 token。

若 MCP 仍不稳定，可暂时绕过 MCP：关闭沙箱直连 https://api.dida365.com/open/v1，用 Bearer token 调 OpenAPI。注意该接口不支持 DELETE、GET /task/{id} 和 /task/{id}/move，移动任务要用“隐藏旧任务 + 目标清单新建”替代。

边界

本技能聚焦配置层、协议层和凭证层的诊断，不负责实现 MCP server 本身，也不覆盖服务端侧的限流或授权策略调整。修改 mcp.json 前应备份现有配置；curl 探测必须设置 dangerouslyDisableSandbox: true，否则会被沙箱拦截。