feat: 支持临时禁用单个 MCP 工具

[cindy-issue]

提交人: fujiachao
客户端版本: 0.1.28

---

使用场景 / Use case

在使用 CINDY 的 MCP 工具列表时，用户可能希望在当前会话或一段时间内避免某个特定 MCP 工具被模型调用，例如：该工具暂时不可用、可能产生不希望的副作用、与其他工具结果冲突，或用户只想聚焦在一组工具上。

当前问题 / Current limitation

当前 MCP 工具列表缺少针对单个工具的启用/禁用控制。用户只能保留全部工具可用，或通过移除/修改 MCP 配置来避免调用；后者操作成本高，也不适合临时切换。

期望方案 / Proposed solution

在 MCP 工具列表中为每个工具增加独立的启用/禁用开关。被禁用的工具应在当前作用域内不再暴露给模型调用，界面保留该工具及禁用状态以便快速恢复。

默认保持现有行为（全部启用）。建议明确开关的作用域和持久化策略，例如仅当前会话、按对话持久化或全局持久化。

已考虑的替代方案 / Alternatives considered

• 直接删除或修改 MCP 配置：适合永久变更，不适合临时开关，恢复成本较高。
• 通过提示词要求模型不调用某工具：不能可靠保证工具不会被调用。

---

版本区域: CN
OS: win32 x64 (10.0.19045)
界面语言: zh-CN

[dash-s-cindy]

判断

Issue 描述部分准确，值得处理。 当前 main@fe9dd69a 确实没有“按单个 MCP 工具临时禁用”的产品能力，相关历史 Issue/PR 中也未发现已经修复或待合入的同类实现。

需要修正的一点是：Cindy 并非只能通过删除配置来停用能力——内置能力已有按插件/服务器启停的入口。当前真正缺少的是更细粒度的 MCP server + tool 级控制，以及适合临时切换的作用域。

行动

建议接受为功能需求，并先将 MVP 定义为：

• 按“本任务/本对话”持久化；
• 默认全部启用；
• 修改后在下一次 Agent runtime 启动或重启时生效；
• 暂不加入全局禁用，也不先承诺运行中热切换。

在进入实现前，需要先确认上述作用域和生效时机。

核实结果

• 自定义 MCP 当前采用“配置存在即注入，删除即停用”的语义。CustomMcpConfig 只有 id、name、transport、url、headers，没有 server 或 tool 的启停字段：
  • apps/desktop/src/shared/customMcp.ts
  • apps/desktop/src/main/localDb/schema.ts
• 设置页的 McpServersSection 每行代表一个 MCP server，仅提供编辑和删除，没有 server 开关，也没有展开后的单工具开关：
  • apps/desktop/src/renderer/components/settings/McpServersSection.tsx
• /context 已经能够展示 runtime 实际发现的 serverName/toolName 清单，因此现有产品里已经有可复用的工具清单来源；但它目前只是只读展示。
• 自定义 MCP 配置刷新明确采用“下一次新建会话生效，进行中的会话不受影响”的生命周期：
  • apps/desktop/src/main/mcp-integrations/custom-mcp-registry.ts
• Claude 底层链路已有 allowedTools / disallowedTools 参数，但 Cindy 尚未提供跨 Claude Code、Codex、Pi 的统一单工具禁用能力。只接入 Claude 不能视为完成。
• PR #668 处理的是插件整体 readiness、发现和启停，不是单个 MCP 工具禁用，不能替代本 Issue。

建议实现

1. 稳定标识

   • 使用 serverId + toolName 作为 override 键，不要只存展示名。
   • 只保存显式禁用项；没有 override 时默认启用，保证新增工具自然保持现有行为。

2. MVP 作用域

   • 按本任务/本对话持久化，与会话一起恢复。
   • 修改后明确提示“重启 Agent 后生效”。这与当前工具面在 runtime 创建时冻结的生命周期一致，也避免在尚未验证各 harness 热更新能力前改变运行中行为。

3. 界面入口

   • 可以复用 /context 已展示的实际 MCP 工具清单。
   • 被禁用的工具继续保留在 Cindy UI 中并显示禁用状态，但下一 runtime 不再向模型暴露。

4. 统一执行语义

   • “模型可见工具面”和“调用准入”必须消费同一份会话级快照。
   • 禁用工具既应从定义/发现层移除，也应在派发层拒绝绕过调用。
   • 不能只依赖提示词，也不能只保留工具定义、等调用后再返回禁用错误。

5. 保持现有能力

   • 现有内置插件或 server 级开关继续保留，单工具 override 作为更细的一层。
   • 本需求不应顺带改变现有插件启停或正在运行会话的生命周期语义。

验收建议

• 分别覆盖 Claude Code、Codex、Pi：
  • 禁用工具不出现在新 runtime 的模型工具面；
  • 直接点名或伪造调用也被拒绝；
  • 同一 MCP server 的其他工具仍可正常使用。
• 关闭后重启应用或恢复会话仍保持；新建其他对话不继承；恢复启用并重启 runtime 后可再次调用。
• MCP server 更新后，已经删除的工具对应旧 override 应安全忽略；新增加的工具默认启用。
• 覆盖内置 MCP、自定义 HTTP MCP，以及 Issue 报告中的 Windows 场景。
• 验证 Codex 共享 app-server/thread 隔离，确保一个对话的禁用状态不会影响其他对话。
• 检查工具定义变化对 prompt/tool-definition 缓存前缀的影响。

待确认的产品决策

• 是否必须在点击开关后立即影响正在运行的 Agent。若必须即时生效，需要另行验证三个 harness 的安全重建或热更新能力，不能直接假设支持。
• 是否后续增加“所有新对话默认”或全局作用域。建议不与本次 MVP 同时扩面。