Claude Code CLI 내에서 순위가 매겨진 할 일(todo) 목록과 서브 에이전트 파견 기능을 갖춘 다중 모델 코드 리뷰 도구입니다.
Claude Code는 코드 리뷰에 탁월하지만, 단일 모델과만 대화할 수 있습니다. 최근 Copilot CLI는 다중 모델 디버깅 기능을 출시하여 GPT, Claude, Gemini에 한 번에 문제를 던져볼 수 있게 되었습니다. Claude Code는 기본적으로 이 기능을 지원하지 않습니다. 이 MCP 서버가 그 기능을 추가합니다: 직접 API 키를 가져와 원하는 모델 조합으로 배포하고, 각 모델이 발견한 내용을 비교(diff)하여 순위가 매겨진 목록으로 받아보세요.
버그나 작업을 여러 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 할 일 저장소 위치 |
| 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에서 다음 중 하나를 입력하세요:
명령어 | 기능 |
| 활성화된 모든 모델에 배포, 결과 비교, 순위가 매겨진 할 일 저장 |
| 위와 동일하며, 모델들이 서로를 비판하는 토론 라운드 추가 |
| 특정 제공자만 비교 |
| 구성된 제공자 및 상태 표시 |
| 상태별로 그룹화된 모든 할 일 표시 (대기 중/진행 중/완료) |
| 할 일의 상태 변경 |
/compare가 실행된 후, 발견된 문제를 해결하기 위해 서브 에이전트를 병렬로 파견할지 묻는 메시지가 표시됩니다. 각 서브 에이전트는 하나의 할 일을 맡아 수정 사항을 구현하고 커밋합니다.
배포(Dispatch) — compare_run은 asyncio.gather를 통해 코드와 문제를 모든 활성화된 제공자에게 배포합니다. 타임아웃되거나 오류가 발생한 제공자는 제외되며 전체 실행을 중단시키지 않습니다.
비교(Diff) — compare_diff는 rapidfuzz(토큰 정렬 비율)를 사용하여 제공자 간의 중복된 결과를 제거합니다. 2개 이상의 제공자가 발견한 내용은 "공유"로, 나머지는 "고유"로 분류됩니다. 합의율 = 공유 / 전체 고유 그룹.
토론(Debate) (선택 사항) — compare_debate는 각 제공자의 결과를 다른 모든 제공자에게 보내 비판하게 합니다. 합성 호출을 통해 결과를 병합합니다. API 호출 제한을 위해 4개 제공자로 제한됩니다 (N*(N-1)+1).
할 일(Todos) — compare_todos는 순위가 매겨진 결과를 SQLite에 기록합니다. 심각도가 높은 순, 그 다음 제공자 수 순으로 정렬됩니다.
실행(Execute) — /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).
