在 Claude Code CLI 中进行带有待办事项排名和子代理派遣的多模型代码审查。
Claude Code 非常擅长代码审查，但它只能与一个模型对话。Copilot CLI 最近推出了多模型调试功能，允许一次性向 GPT、Claude 和 Gemini 抛出问题。Claude Code 原生不支持此功能。此 MCP 服务器添加了该功能：使用您自己的 API 密钥，分发到任意模型组合，并获取它们各自发现的差异化、排名列表。
将任何错误或任务同时分发给多个 LLM，对比它们的独特见解，可选运行模型互相批评的辩论环节，然后派遣并行子代理来实施综合后的最佳修复方案——每个修复方案都有其对应的 git 提交。
https://github.com/user-attachments/assets/8990dabb-bc61-4625-8930-c914cffe75da
/compare models→/compare review config.py for security issues→/compare --debate→/compare status
Related MCP server: Multi-Agent Council Review
pip install compare-mcp
claude mcp add -s user compare-mcp -- python -m compare_mcp然后获取 /compare 技能和示例配置：
git clone https://github.com/carolinacherry/compare-mcp.git --depth 1
mkdir -p ~/.claude/skills ~/.compare
cp -r compare-mcp/.claude/skills/compare ~/.claude/skills/
cp compare-mcp/.compare/config.example.json ~/.compare/config.json编辑 ~/.compare/config.json — 通过设置 "enabled": true 并添加您的 API 密钥（作为 $ENV_VAR 引用或直接粘贴密钥）来启用至少 2 个提供商。
在 Claude Code 中：
/compare memory leak in the tile rendering loop
/compare race condition in the connection pool --debate --providers claude,openai
/compare status
/compare models配置位于 ~/.compare/config.json。API 密钥使用 $ENV_VAR 语法 — 在加载时展开。
类型 | SDK | 用途 |
| anthropic-python | 直接使用 Claude 模型 |
| openai-python (带自定义 | OpenAI、Kimi、Minimax、Gemini、Ollama API 或任何兼容端点 |
| subprocess stdin/stdout | Ollama CLI、Codex CLI 或任何二进制文件 |
键 | 默认值 | 描述 |
| 2048 | 每个提供商响应的最大 token 数 |
| 120 | 每个提供商的超时时间（见下文说明） |
|
| SQLite 待办事项存储位置 |
| 0.65 | 模糊匹配阈值 (0-1)。越高越严格 |
| 1000 | 在发送超过此行数的文件前发出警告 |
超时说明： 某些模型（例如 Kimi 的 kimi-k2.5）在处理大型提示词时比 GPT-4o 慢得多，在 60 秒时会超时。我们默认设置为 120 秒。如果某个提供商持续超时，请尝试更快的模型变体 — 对于 Kimi，moonshot-v1-auto 比 kimi-k2.5 更快，并会自动选择正确的上下文窗口。
{
"my_provider": {
"enabled": true,
"type": "openai_compat",
"api_key": "$MY_API_KEY",
"model": "model-name",
"base_url": "https://api.example.com/v1"
}
}适用于：OpenAI、Kimi (api.moonshot.ai)、Minimax (api.minimax.io)、Gemini (generativelanguage.googleapis.com/v1beta/openai/)、Ollama API (localhost:11434/v1)、OpenRouter、Together AI、Groq 等。
{
"ollama_local": {
"enabled": true,
"type": "cli",
"cli_command": "ollama",
"cli_args": ["run", "codellama"],
"cli_parser": "text"
}
}cli_parser 选项："text" (原始 stdout)、"json" (解析为 JSON)、"jsonl" (最后一行完整的 JSON)。
在 Claude Code 中，输入以下任一命令：
命令 | 功能 |
| 分发给所有已启用的模型，对比发现，保存排名后的待办事项 |
| 同上，外加一个模型互相批评的辩论环节 |
| 仅比较特定提供商 |
| 显示已配置的提供商及其状态 |
| 显示按状态分组的所有待办事项 (pending/in_progress/done) |
| 更改待办事项的状态 |
在 /compare 运行后，系统会询问是否派遣子代理并行修复发现的问题。每个子代理负责一个待办事项，实施修复并提交。
分发 — compare_run 通过 asyncio.gather 将代码和问题分发给所有已启用的提供商。超时或出错的提供商会被排除，不会导致整个运行崩溃。
对比 — compare_diff 使用 rapidfuzz (token sort ratio) 对跨提供商的发现进行去重。被 2 个以上提供商发现的问题为“共享”；其余为“独特”。一致性比率 = 共享 / 总独特组。
辩论 (可选) — compare_debate 将每个提供商的发现发送给其他所有提供商进行批评。综合调用会合并结果。限制为最多 4 个提供商以限制 API 调用 (N*(N-1)+1)。
待办事项 — compare_todos 将排名后的发现写入 SQLite。按严重程度优先，然后按提供商数量排序。
执行 — /compare 技能派遣并行的 Claude Code 子代理，每个待办事项一个。每个子代理实施修复并提交。
工具 | 描述 |
| 列出已配置的提供商（不暴露 API 密钥） |
| 并行分发代码审查给提供商 |
| 使用模糊去重提取独特与共享的见解 |
| 模型互相批评，然后进行综合 |
| 将排名后的发现写入 SQLite |
| 读取按状态分组的待办事项 |
| 更新待办事项的状态 |
multi_mcp 在并行分发方面做得很好。compare-mcp 在其之上构建了工作流层：
功能 | multi_mcp | compare-mcp |
并行分发 | 是 | 是 |
OpenAI 兼容提供商 | 是 | 是 |
CLI 子进程模型 | 是 | 是 |
辩论 / 批评环节 | 原始 | 结构化 + 合并输出 |
见解对比 (独特 vs 共享) | 否 | rapidfuzz 去重 |
一致性比率指标 | 否 | 是 |
SQLite 排名待办事项存储 | 否 | 是 |
每个待办事项的子代理派遣 | 否 | 是 |
每个修复的 Git 提交 | 否 | 是 |
CC 技能 + /compare | 否 | 是 |
pip 安装 | 否 (git clone + make) | 是 |
Copilot CLI 通过 GitHub 的 API 代理路由 — 不支持自带密钥 (BYO)，不支持 Kimi/Minimax/本地模型。compare-mcp 直接调用提供商 API：拥有完整的上下文窗口、您自己的速率限制，以及任何带有 HTTP 端点或 CLI 二进制文件的模型。
git clone https://github.com/carolinacherry/compare-mcp.git
cd compare-mcp
pip install -e ".[dev]"
pytest
ruff check .Run a debate round where each model critiques others' findings, then synthesize.
Args: responses: Output from compare_run. rounds: Number of debate rounds (default 1).
| Name | Required | Description | Default |
|---|---|---|---|
| rounds | No | ||
| responses | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the process (critique and synthesize) but does not disclose side effects, permissions, or whether the tool modifies state. Given the lack of annotations, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a parameter list. Information is front-loaded, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (debate round with multiple models and a synthesis step), the description is too brief. It does not explain what 'synthesize' produces, how rounds affect output, or any return value semantics despite an existing output schema. The presence of siblings suggests more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add value. It explains that 'responses' is output from compare_run, which provides useful context, and 'rounds' is the number of rounds (restating the name). This partially compensates but lacks detail on the structure of 'responses'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a debate round where models critique each other and synthesize, distinguishing it from sibling tools like compare_run and compare_diff. The verb 'Run' and resource 'debate round' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It only mentions that 'responses' come from compare_run, implying a prerequisite but no explicit context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diff provider responses: extract unique vs shared insights using fuzzy matching.
Args: responses: Output from compare_run.
| Name | Required | Description | Default |
|---|---|---|---|
| responses | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions 'fuzzy matching' but lacks details on matching thresholds, side effects, or whether operation is read-only. The term 'diff' suggests comparison but no mutation disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus args line. Front-loaded with purpose, every sentence adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values not needed. But given 1 complex parameter and fuzzy matching behavior, more detail on output interpretation or matching process would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds 'Output from compare_run' for the 'responses' parameter, giving context. However, it doesn't describe the nested object structure or expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'extract unique vs shared insights using fuzzy matching' - specific verb and resource. It distinguishes from sibling tools like compare_run that produce the input, and compare_debate which likely has different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates input is 'Output from compare_run', implying usage after that tool, but no explicit when-to-use or alternatives guidance. Sibling tools not mentioned as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured providers with their enabled status, type, and model. Does not expose API keys.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly notes it does not expose API keys, a key safety trait. However, it omits other behavioral details like read-only nature; annotations are absent but the output schema may cover return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main function, and a critical security note. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool with an output schema, the description covers what is listed and a key safety constraint (no API keys). It is complete for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100%), so the baseline is 4. The description adds no param info, which is acceptable as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all configured providers with their enabled status, type, and model. It distinguishes from sibling tools which focus on debates, diffs, runs, or todos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for viewing provider configurations without parameters. While no explicit when-to-use or alternatives are given, the context and sibling names make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fan out a code review to all enabled providers (or a subset) in parallel.
Args: code: The source code to review. issue: Description of the bug or task. providers: Optional list of provider names to query. Defaults to all enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| issue | Yes | ||
| providers | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses parallel execution and provider targeting, but does not mention side effects, safety, or return format. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear action statement and structured Args list. No unnecessary words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but description does not mention what the tool returns. Given low complexity and sibling tools that likely compare outputs, this is a minor gap but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description clearly explains each parameter: code is source code, issue is bug description, providers is optional list defaulting to all. Adds meaningful context beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fans out a code review to providers in parallel, using specific verbs and resource. It distinguishes from sibling tools like compare_debate or compare_models by focusing on sending code for review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like compare_diff or compare_status. The description implies it is for code review, but lacks when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current todos grouped by status (pending, in_progress, done).
Args: code_file: Optional filter by file path.
| Name | Required | Description | Default |
|---|---|---|---|
| code_file | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It implies a read-only operation ('return'), but lacks explicit statements about no side effects, permissions, or performance impacts. Adequate for a simple query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence captures the main purpose, the second describes the parameter. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. It covers the input adequately. However, ambiguity about the grouping format could be clarified, but the output schema likely handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the schema provides no description for 'code_file'. The tool description adds 'Optional filter by file path.', which gives meaningful context beyond the schema's type and name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'return' and the resource 'current todos grouped by status', which is specific. It distinguishes from sibling 'compare_todos' by mentioning grouping, but could be more explicit about how grouping differs from a flat list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like 'compare_todos'. The purpose implies it's for grouped status views, but no exclusionary language is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write ranked findings to the SQLite todo store.
Args: findings: List of {title, description, severity, source_providers}. code_file: Optional file path the findings relate to.
| Name | Required | Description | Default |
|---|---|---|---|
| findings | Yes | ||
| code_file | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'write' but doesn't specify whether findings are appended or replaced, or any side effects. Critical details like idempotency or permission requirements are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for the purpose followed by parameter explanations. Every sentence adds information without redundancy, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple enough, but completeness is moderate. While the output schema exists, the description does not mention return values or behavior on multiple calls. The lack of behavioral details (e.g., whether writing is destructive) leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly names the expected keys in the findings array (title, description, severity, source_providers), which the input schema does not specify (it uses additionalProperties: true). It also clarifies code_file's purpose as an optional file path, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes ranked findings to the SQLite todo store, specifying the action and target resource. However, it does not differentiate from siblings like compare_debate or compare_todo_update, which might also write but with different logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. The description only states what it does, without any contextual hints about prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a todo's status.
Args: todo_id: The todo ID to update. status: New status — one of 'pending', 'in_progress', 'done'.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| todo_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry full burden. Only states it updates status; fails to disclose that it is a destructive write operation, idempotency, returned data, or required permissions. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence for purpose, followed by succinct argument descriptions. No unnecessary words. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (update with two params) and presence of an output schema, the description covers the essentials. It specifies both parameters and allowed values. However, it omits edge cases, error handling, and confirmation that only status is updated (not other fields). Still, largely adequate for a straightforward mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by explaining both parameters: todo_id as the ID to update, and status with explicit allowed values ('pending', 'in_progress', 'done'). This adds useful meaning beyond the bare schema types. Could be slightly improved by noting that status is required or enumerating exact values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update a todo's status' – a specific verb and resource. However, the tool name prefix 'compare_' is not explained and could cause confusion with sibling tools like 'compare_todos' (which likely lists). Despite this, the purpose is unambiguous for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'compare_todos' or 'compare_status'. It lacks context about prerequisites or workflow integration, leaving the agent to infer usage from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1compare_debatecompare_diffcompare_modelscompare_runcompare_statuscompare_todo_updatecompare_todosScored across 7 tools
Each tool has a clear, distinct purpose: running comparisons, diffing results, debating, listing models, and managing todos. No overlap or ambiguity.
All tools share the 'compare_' prefix and follow a verb_noun pattern (e.g., compare_run, compare_diff). The only minor deviation is 'compare_todo_update' which includes an extra verb, but it remains readable.
With 7 tools, the server is well-scoped for its purpose: running comparisons, analyzing results, and managing follow-up tasks. Neither too few nor excessive.
The core workflow (run comparison, analyze results, manage todos) is covered. Minor gaps exist, such as no tool to retrieve all results or delete todos, but agents can work around this.
Multi-LLM council: 25+ frontier models in parallel, consensus scoring, verdict-first code review.
Assign Linear, Jira or GitHub issues to an AI coding agent team that plans, builds, reviews, tests.
Coordination hub for AI coding agents: message teammates, ask humans, audit every event.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
