Zen MCP Server

为什么要用

核心特性

跨模型对话：每个工具可以选择不同的模型
工作流工具：thinkdeep、planner、debug、codereview、consensus、refactor
供应商支持：Gemini、OpenAI、Grok、OpenRouter、Ollama、Azure OpenAI
Continuation ID 保持跨模型上下文存活
内置每供应商的费用追踪

实时演示

实际使用效果

zen-mcp-server.replay ▶ 就绪

0/0

安装

选择你的客户端

~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "zen-mcp-server": {
      "command": "uvx",
      "args": [
        "zen-mcp-server"
      ]
    }
  }
}

打开 Claude Desktop → Settings → Developer → Edit Config。保存后重启应用。

~/.cursor/mcp.json · .cursor/mcp.json

{
  "mcpServers": {
    "zen-mcp-server": {
      "command": "uvx",
      "args": [
        "zen-mcp-server"
      ]
    }
  }
}

Cursor 使用与 Claude Desktop 相同的 mcpServers 格式。项目级配置优先于全局。

VS Code → Cline → MCP Servers → Edit

{
  "mcpServers": {
    "zen-mcp-server": {
      "command": "uvx",
      "args": [
        "zen-mcp-server"
      ]
    }
  }
}

点击 Cline 侧栏中的 MCP Servers 图标，然后选 "Edit Configuration"。

~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "zen-mcp-server": {
      "command": "uvx",
      "args": [
        "zen-mcp-server"
      ]
    }
  }
}

格式与 Claude Desktop 相同。重启 Windsurf 生效。

~/.continue/config.json

{
  "mcpServers": [
    {
      "name": "zen-mcp-server",
      "command": "uvx",
      "args": [
        "zen-mcp-server"
      ]
    }
  ]
}

Continue 使用服务器对象数组，而非映射。

~/.config/zed/settings.json

{
  "context_servers": {
    "zen-mcp-server": {
      "command": {
        "path": "uvx",
        "args": [
          "zen-mcp-server"
        ]
      }
    }
  }
}

加入 context_servers。Zed 保存后热重载。

claude mcp add zen-mcp-server -- uvx zen-mcp-server

一行命令搞定。用 claude mcp list 验证，claude mcp remove 卸载。

使用场景

实战用法： Zen MCP Server

从 3 个不同模型获取对某个架构决策的共识

👤 做高风险决策的技术负责人 ⏱ ~20 min intermediate

何时使用： 单靠 Claude 的意见感觉像一家之言；你想要多元视角。

前置条件

至少 2 个备用供应商的 API key — 设置 GEMINI_API_KEY、OPENAI_API_KEY、OPENROUTER_API_KEY

步骤

明确问题

Use zen.consensus. Question: should we move our queue from Redis to NATS Jetstream? Stakes: 50M msgs/day, 99.99% uptime. Ask Gemini Pro and o3.✓ 已复制

→ 两个模型均回复，Claude 总结两方分歧
深入分析分歧

Where do they disagree? Use zen.chat to push back on each model's weakest point.✓ 已复制

→ 每个模型的反驳轮次
综合结论

Give me a final recommendation with the strongest argument from each side surfaced.✓ 已复制

→ 合并后的决策文档

结果： 一个可以用跨模型证据支撑的架构决策。

注意事项

各模型对 API 细节的幻觉方式不同——形成虚假共识 — 事实性声明务必用实际文档/源码验证

搭配使用： context7 · git-mcp-idosal

用 Gemini Pro 的 thinkdeep 规划，再由 Claude 执行

👤 在大型任务上达到 Claude 规划上限的开发者 ⏱ ~40 min intermediate

何时使用： 任务规模太大，即使扩展思考也会丢失主线。

步骤

交接简报

Use zen.thinkdeep with gemini-2.5-pro. Plan the migration from monolith to 3 microservices. Identify all sequencing risks.✓ 已复制

→ Gemini 返回长篇计划，格式为结构化文档
审查计划

Now you (Claude) review that plan. What's missing? What's risky?✓ 已复制

→ 缺口分析
执行第一步

Implement the first phase of the plan in this repo.✓ 已复制

→ 实际代码修改

结果： 因两个模型对方案达成共识而值得信赖的计划。

搭配使用： desktop-commander-mcp

用与写代码不同的模型运行 zen.codereview

👤 想要对抗性审查的独立开发者 ⏱ ~25 min intermediate

何时使用： 你用 Claude 完成了一个功能，想要一双新鲜眼睛（另一个模型）来审查。

步骤

暂存 diff

Save the current branch's diff. Pass it to zen.codereview with o3.✓ 已复制

→ 按文件组织的审查意见
接受或拒绝

Show me each suggestion. Apply only the ones I approve.✓ 已复制

→ 逐条建议的接受/拒绝提示

结果： 由具有不同先验知识的模型审查的代码。

搭配使用： git-mcp-idosal

组合

与其他 MCP 搭配，撬动十倍杠杆

zen-mcp-server + desktop-commander-mcp

用 Gemini 规划，用 Claude+desktop-commander 执行

zen-mcp-server + git-mcp-idosal

通过 gitmcp 拉取仓库，再用 zen 和 o3 进行代码审查

工具

此 MCP 暴露的能力

工具	输入参数	何时调用	成本
chat	prompt, model?, continuation_id?	向备用模型进行通用问答	1 API call to chosen model
thinkdeep	problem, model?	规划复杂问题	Heavy — uses thinking budget
codereview	files[], model?	全新视角的 PR 审查	1 API call
debug	error, context, model?	遇到 Claude 看不到的 bug	1 API call
consensus	question, models[]	高风险决策	N API calls
precommit	diff, model?	提交前最终检查	1 API call

成本与限制

运行它的成本

API 配额: 按供应商计费；每个供应商单独付费
每次调用 Token 数: 因工具而异——thinkdeep 可能达到 30k+ token
费用: server 免费；直接向各 LLM 供应商付费
提示: 日常对话设置 DEFAULT_MODEL=ollama:llama3.1，只在需要时升级到付费模型

安全

权限、密钥、影响范围

最小权限： outbound:llm-providers

凭据存储： 供应商 key 存在环境变量中

数据出站： 你配置的所有供应商

将你的代码发送给多个供应商意味着多套数据处理政策——请审查每个供应商的条款

故障排查

常见错误与修复

模型不可用

检查该供应商的环境变量；只有已配置的供应商才会出现

验证： 列出 zen 工具——模型默认值显示在其中

Continuation ID 丢失

每个工具都会返回 continuation_id；将其传回以保持跨模型上下文

thinkdeep 费用失控

在环境变量中设置 MAX_THINKING_TOKENS；默认值可能很高

替代方案

Zen MCP Server 对比其他方案

替代方案	何时用它替代	权衡
context-mode-mcp	你想要的是上下文整形，而非多模型路由	解决的是不同的问题
Direct OpenAI/Gemini MCPs	你只需要一个备用模型，不需要编排	流程更简单，但没有 consensus/thinkdeep 工作流