Проверка кода с использованием нескольких моделей, ранжированием задач (todo) и отправкой субагентов внутри CLI Claude Code.
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 — включите как минимум 2 провайдера, установив "enabled": true и добавив свой API-ключ (либо в виде ссылки на $ENV_VAR, либо вставив ключ напрямую).
В 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 |
| 0.65 | Порог нечеткого сравнения (0-1). Выше = строже |
| 1000 | Предупреждать перед отправкой файлов больше этого размера |
Примечание о тайм-ауте: Некоторые модели (например, kimi-k2.5 от Kimi) значительно медленнее, чем 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 вам будет предложено отправить субагентов для параллельного исправления найденных проблем. Каждый субагент получает одну задачу, реализует исправление и делает коммит.
Dispatch (Распределение) — compare_run распределяет код + задачу между всеми включенными провайдерами через asyncio.gather. Провайдеры, которые превысили тайм-аут или выдали ошибку, исключаются и не приводят к сбою всего процесса.
Diff (Сравнение) — compare_diff использует rapidfuzz (token sort ratio) для дедупликации выводов между провайдерами. Выводы, замеченные 2+ провайдерами, считаются «общими»; остальные — «уникальными». Коэффициент согласия = общие / общее количество уникальных групп.
Debate (Дебаты, опционально) — compare_debate отправляет выводы каждого провайдера всем остальным для критики. Вызов синтеза объединяет результаты. Ограничено 4 провайдерами для ограничения количества вызовов API (N*(N-1)+1).
Todos (Задачи) — compare_todos записывает ранжированные выводы в SQLite. Сначала высокий приоритет, затем по количеству провайдеров.
Execute (Выполнение) — Навык /compare отправляет параллельных субагентов Claude Code, по одному на задачу. Каждый реализует исправление и делает коммит.
Инструмент | Описание |
| Список настроенных провайдеров (API-ключи не отображаются) |
| Параллельная проверка кода провайдерами |
| Извлечение уникальных и общих выводов с нечеткой дедупликацией |
| Модели критикуют друг друга, затем синтезируют результат |
| Запись ранжированных выводов в SQLite |
| Чтение задач, сгруппированных по статусу |
| Обновление статуса задачи |
multi_mcp хорошо справляется с параллельным распределением. compare-mcp выстраивает поверх него уровень рабочего процесса:
Функция | multi_mcp | compare-mcp |
Параллельное распределение | да | да |
OpenAI-совместимые провайдеры | да | да |
CLI subprocess модели | да | да |
Раунд дебатов / критики | сырой | структурированный + объединенный вывод |
Сравнение выводов (уникальные vs общие) | нет | дедупликация rapidfuzz |
Метрика коэффициента согласия | нет | да |
Хранилище ранжированных задач SQLite | нет | да |
Отправка субагента на задачу | нет | да |
Git-коммит на исправление | нет | да |
Навык CC + /compare | нет | да |
pip install | нет (git clone + make) | да |
Copilot CLI маршрутизирует запросы через API-прокси GitHub — нет возможности использовать свои ключи, нет поддержки 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).
