Claude Code CLI内で、ランク付けされたTODOとサブエージェント派遣機能を備えたマルチモデルコードレビューツールです。
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 | プロバイダーの応答ごとの最大トークン数 |
| 120 | プロバイダーごとのタイムアウト（以下の注記を参照） |
|
| SQLite TODOストアの場所 |
| 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で、以下のいずれかを入力します：
コマンド | 動作 |
| 有効な全モデルに分散し、結果を比較し、ランク付けされたTODOを保存 |
| 上記に加え、モデル同士が批判し合う議論ラウンドを実行 |
| 特定のプロバイダーのみを比較 |
| 設定されたプロバイダーとそのステータスを表示 |
| ステータス別にグループ化された全TODOを表示 (pending/in_progress/done) |
| TODOのステータスを変更 |
/compareの実行後、結果を修正するためにサブエージェントを並列で派遣するかどうか尋ねられます。各サブエージェントは1つのTODOを受け取り、修正を実装してコミットします。
Dispatch (分散) — compare_runはasyncio.gatherを介して、コードと問題を有効な全プロバイダーに分散させます。タイムアウトやエラーが発生したプロバイダーは除外され、実行全体がクラッシュすることはありません。
Diff (比較) — compare_diffはrapidfuzz (token sort ratio)を使用して、プロバイダー間の結果を重複排除します。2つ以上のプロバイダーが発見した内容は「共有」、残りは「ユニーク」とみなされます。合意率 = 共有 / 全ユニークグループ。
Debate (議論 - オプション) — compare_debateは、各プロバイダーの発見内容を他のすべてのプロバイダーに送信して批判させます。合成呼び出しによって結果が統合されます。API呼び出しを制限するため、4プロバイダーまでに制限されています (N*(N-1)+1)。
Todos — compare_todosは、ランク付けされた発見内容をSQLiteに書き込みます。重要度が高い順、次にプロバイダー数順に並べられます。
Execute (実行) — /compareスキルは、TODOごとに1つずつ、並列のClaude Codeサブエージェントを派遣します。それぞれが修正を実装し、コミットします。
ツール | 説明 |
| 設定されたプロバイダーを一覧表示 (APIキーは非表示) |
| コードレビューをプロバイダーに並列分散 |
| ファジー重複排除を使用してユニークな洞察と共有された洞察を抽出 |
| モデル同士が批判し合い、その後統合 |
| ランク付けされた発見内容をSQLiteに書き込み |
| ステータス別にグループ化されたTODOを読み取り |
| TODOのステータスを更新 |
multi_mcpは並列分散をうまく行います。compare-mcpはその上にワークフロー層を構築します：
機能 | multi_mcp | compare-mcp |
並列分散 | はい | はい |
OpenAI互換プロバイダー | はい | はい |
CLIサブプロセスモデル | はい | はい |
議論 / 批判ラウンド | 生データ | 構造化 + 統合出力 |
洞察の比較 (ユニーク vs 共有) | いいえ | rapidfuzz重複排除 |
合意率メトリクス | いいえ | はい |
SQLiteランク付けTODOストア | いいえ | はい |
TODOごとのサブエージェント派遣 | いいえ | はい |
修正ごとのGitコミット | いいえ | はい |
CCスキル + /compare | いいえ | はい |
pip install | いいえ (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).
