Multi-Modell-Code-Review mit priorisierten Aufgaben und Sub-Agenten-Dispatch innerhalb der Claude Code CLI.
Claude Code ist großartig für Code-Reviews – aber es kommuniziert nur mit einem Modell. Die Copilot CLI hat kürzlich ein Multi-Modell-Debugging eingeführt, mit dem man ein Problem gleichzeitig an GPT, Claude und Gemini weiterleiten kann. Claude Code kann das nativ nicht. Dieser MCP-Server fügt diese Funktion hinzu: Verwenden Sie Ihre eigenen API-Schlüssel, verteilen Sie Anfragen an eine beliebige Kombination von Modellen und erhalten Sie eine differenzierte, priorisierte Liste der Ergebnisse.
Verteilen Sie jeden Bug oder jede Aufgabe gleichzeitig an mehrere LLMs, vergleichen Sie deren einzigartige Erkenntnisse, führen Sie optional eine Debattenrunde durch, in der sich die Modelle gegenseitig kritisieren, und entsenden Sie dann parallele Sub-Agenten, um die kombinierten besten Korrekturen zu implementieren – jeweils mit einem eigenen Git-Commit.
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_mcpHolen Sie sich dann den /compare-Skill und die Beispielkonfiguration:
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.jsonBearbeiten Sie ~/.compare/config.json – aktivieren Sie mindestens 2 Anbieter, indem Sie "enabled": true setzen und Ihren API-Schlüssel hinzufügen (entweder als $ENV_VAR-Referenz oder durch direktes Einfügen des Schlüssels).
In Claude Code:
/compare memory leak in the tile rendering loop
/compare race condition in the connection pool --debate --providers claude,openai
/compare status
/compare modelsDie Konfiguration befindet sich unter ~/.compare/config.json. API-Schlüssel verwenden die $ENV_VAR-Syntax – diese wird beim Laden aufgelöst.
Typ | SDK | Verwendung für |
| anthropic-python | Claude-Modelle direkt |
| openai-python mit benutzerdefiniertem | OpenAI, Kimi, Minimax, Gemini, Ollama API, jeder kompatible Endpunkt |
| subprocess stdin/stdout | Ollama CLI, Codex CLI, jede Binärdatei |
Schlüssel | Standard | Beschreibung |
| 2048 | Maximale Token pro Anbieterantwort |
| 120 | Timeout pro Anbieter (siehe Hinweis unten) |
|
| Speicherort der SQLite-Aufgabenliste |
| 0.65 | Schwellenwert für Fuzzy-Matching (0-1). Höher = strenger |
| 1000 | Warnung vor dem Senden von Dateien, die größer als dieser Wert sind |
Timeout-Hinweis: Einige Modelle (z. B. Kimis kimi-k2.5) sind bei großen Prompts deutlich langsamer als GPT-4o und erreichen bei 60s ein Timeout. Wir verwenden standardmäßig 120s. Wenn ein Anbieter konsistent ein Timeout verursacht, versuchen Sie eine schnellere Modellvariante – für Kimi ist moonshot-v1-auto schneller als kimi-k2.5 und wählt automatisch das richtige Kontextfenster aus.
{
"my_provider": {
"enabled": true,
"type": "openai_compat",
"api_key": "$MY_API_KEY",
"model": "model-name",
"base_url": "https://api.example.com/v1"
}
}Funktioniert mit: OpenAI, Kimi (api.moonshot.ai), Minimax (api.minimax.io), Gemini (generativelanguage.googleapis.com/v1beta/openai/), Ollama API (localhost:11434/v1), OpenRouter, Together AI, Groq, etc.
{
"ollama_local": {
"enabled": true,
"type": "cli",
"cli_command": "ollama",
"cli_args": ["run", "codellama"],
"cli_parser": "text"
}
}cli_parser-Optionen: "text" (rohes stdout), "json" (als JSON parsen), "jsonl" (letzte vollständige JSON-Zeile).
Geben Sie in Claude Code einen der folgenden Befehle ein:
Befehl | Was er bewirkt |
| An alle aktivierten Modelle verteilen, Ergebnisse abgleichen, priorisierte Aufgaben speichern |
| Wie oben, plus eine Debattenrunde, in der sich die Modelle gegenseitig kritisieren |
| Nur bestimmte Anbieter vergleichen |
| Konfigurierte Anbieter und deren Status anzeigen |
| Alle Aufgaben gruppiert nach Status anzeigen (pending/in_progress/done) |
| Status einer Aufgabe ändern |
Nachdem /compare ausgeführt wurde, werden Sie gefragt, ob Sub-Agenten entsandt werden sollen, um die Ergebnisse parallel zu beheben. Jeder Sub-Agent erhält eine Aufgabe, implementiert die Korrektur und führt einen Commit durch.
Dispatch — compare_run verteilt den Code + das Problem über asyncio.gather an alle aktivierten Anbieter. Anbieter, die ein Timeout verursachen oder Fehler melden, werden ausgeschlossen und bringen den gesamten Vorgang nicht zum Absturz.
Diff — compare_diff verwendet rapidfuzz (Token Sort Ratio), um Ergebnisse über Anbieter hinweg zu deduplizieren. Ergebnisse, die von 2+ Anbietern gesehen wurden, sind "geteilt"; der Rest ist "einzigartig". Übereinstimmungsrate = geteilt / gesamte eindeutige Gruppen.
Debate (optional) — compare_debate sendet die Ergebnisse jedes Anbieters zur Kritik an jeden anderen Anbieter. Ein Synthese-Aufruf führt die Ergebnisse zusammen. Begrenzt auf 4 Anbieter, um API-Aufrufe zu limitieren (N*(N-1)+1).
Todos — compare_todos schreibt priorisierte Ergebnisse in SQLite. Hohe Priorität zuerst, dann nach Anzahl der Anbieter.
Execute — Der /compare-Skill entsendet parallele Claude Code-Sub-Agenten, einen pro Aufgabe. Jeder implementiert die Korrektur und führt einen Commit durch.
Tool | Beschreibung |
| Konfigurierte Anbieter auflisten (keine API-Schlüssel offengelegt) |
| Code-Review parallel an Anbieter verteilen |
| Einzigartige vs. geteilte Erkenntnisse mit Fuzzy-Deduplizierung extrahieren |
| Modelle kritisieren sich gegenseitig und synthetisieren dann |
| Priorisierte Ergebnisse in SQLite schreiben |
| Aufgaben gruppiert nach Status lesen |
| Status einer Aufgabe aktualisieren |
multi_mcp beherrscht den parallelen Dispatch gut. compare-mcp baut die Workflow-Ebene darüber auf:
Feature | multi_mcp | compare-mcp |
Paralleler Dispatch | ja | ja |
OpenAI-kompatible Anbieter | ja | ja |
CLI-Subprozess-Modelle | ja | ja |
Debatten- / Kritikrunde | roh | strukturiert + zusammengeführte Ausgabe |
Erkenntnis-Diff (einzigartig vs. geteilt) | nein | rapidfuzz-Deduplizierung |
Übereinstimmungsraten-Metrik | nein | ja |
SQLite priorisierter Aufgaben-Speicher | nein | ja |
Sub-Agenten-Dispatch pro Aufgabe | nein | ja |
Git-Commit pro Korrektur | nein | ja |
CC-Skill + /compare | nein | ja |
pip install | nein (git clone + make) | ja |
Copilot CLI leitet über den API-Proxy von GitHub – keine BYO-Schlüssel, keine Kimi/Minimax/lokalen Modelle. compare-mcp ruft Anbieter-APIs direkt auf: volle Kontextfenster, Ihre eigenen Ratenbegrenzungen, jedes Modell mit einem HTTP-Endpunkt oder einer CLI-Binärdatei.
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).
