Allows consulting the Google Gemini CLI for parallel responses, specialized analysis, and web-enhanced lookups.
Allows consulting the OpenAI Codex CLI for cross-validation, implementation tasks, and code review.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@consult-mcp Ask Gemini for a second opinion on my sorting algorithm"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server orchestrating local CLI agents (Claude Code, OpenAI Codex, Google Gemini) for cross-validation, second opinions, and persona-driven prompting.
When you're working in Claude Code (or any MCP client), consult-mcp lets you ask other LLM CLIs for their take — without leaving the conversation. Use cases:
Second opinion: "Claude wrote this — what does Gemini think?"
Cross-validation: send the same question to claude/codex/gemini in parallel and compare
Variant generation: pass ["claude", "claude"] for two independent responses to the same prompt
Specialized framing: apply a persona (architect, reviewer, researcher, coder) to focus the model
Eighteen MCP tools ship in v0.10:
Read-only single-shot (no file mutation, return immediately):
consult(agent, prompt, persona?, timeout_seconds?) — single agent
consult_parallel(agents, prompt, persona?, timeout_seconds?) — fan-out to N agents
codereview(agents, files, focus?, timeout_seconds?) — multi-agent code review with structured findings
consensus(agents, question, stances?, synthesizer?, timeout_seconds?) — multi-agent verdict with optional stance steering
challenge(agent, claim, timeout_seconds?) — anti-sycophancy single-agent pushback
Async debate (returns debate_id immediately, runs in background):
debate_start(agents, topic, max_turns?, history_window?, terminator?, ...) — kick off round-robin debate
debate_status(debate_id) — poll progress + transcript
debate_cancel(debate_id) — request soft cancellation
debate_list(active_only?, limit?) — list active + archived debates
debate_replay(debate_id) — full transcript from memory or SQLite archive
debate_export(debate_id, format?, truncate_body_chars?) — render archived debate as portable markdown (default) or stable v1 JSON for Obsidian/Notion/programmatic consumers
Synchronous streaming debate (foreground call with progress notifications):
debate_run(agents, topic, max_turns?, ...) — returns when the loop terminates; pushes per-turn progress to MCP clients that honour progressToken (e.g. Claude Code). Non-resumable — for long debates use debate_start + poll instead
Atomic deliberation (3-stage in one call):
council(agents, question, chairman?, persona?, timeout_seconds?) — independent → cross-rank (anonymized) → synthesis
Niche (focused single-purpose tools):
planner(agent, problem, depth?, timeout_seconds?) — structured task decomposition (JSON tasks with dependencies)
diff_review(agents, diff_text?|git_ref?, cwd?, focus?, ...) — review a git diff for risks/regressions
apilookup(query, agent?, timeout_seconds?) — current docs lookup with web search (default agent: gemini)
File-mutating (activates CLI permission/sandbox bypass flags):
implement(agent, plan, base_path, constraints?, timeout_seconds?) — delegate code changes; returns diff
delegate_implementation(task, base_path, planner_agent?, implementer_agent?, reviewer_agents?, ...) — composite plan→implement→review in one call. Plan via planner_agent, write code via implementer_agent (mutation rights, same CONSULT_MCP_ALLOWED_BASE guard), then fan-out to reviewer_agents (auto-routes to diff_review for git diffs or codereview for mtime-mode workspaces). Default reviewers exclude the implementer.
Related MCP server: personal-mcp
Python 3.10+ (the server itself)
uv for installation (pipx install uv or follow astral.sh/uv)
At least one of these CLI tools installed and authenticated:
Claude Code CLI — install via claude.com/code, then claude login
OpenAI Codex CLI — npm install -g @openai/codex, set OPENAI_API_KEY
Google Gemini CLI — install via geminicli.com, authenticate per docs
You don't need all three — consult-mcp reports per-agent status and skips missing CLIs.
Each CLI handles its own auth. Common env-var setup:
Platform | Set env var |
Windows (PowerShell, persistent) |
|
Windows (current shell) |
|
macOS / Linux (current shell) |
|
macOS / Linux (persistent) | append |
Replace OPENAI_API_KEY with GEMINI_API_KEY for Gemini. Claude Code uses interactive login (claude login); no env var.
Add this to your MCP client's configuration. For Claude Code, that's .mcp.json (project-local) or ~/.claude.json (global):
{
"mcpServers": {
"consult": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/oblogin/consult-mcp.git",
"consult-mcp"
]
}
}
}Restart your MCP client. All six tools (consult, consult_parallel, codereview, consensus, challenge, implement) should appear.
A copy-pasteable snippet is in examples/.mcp.json.
// Single-agent consultation:
consult({
"agent": "gemini",
"prompt": "Should we use GAS for an inventory system in Unreal Engine?",
"persona": "architect"
})
// → {
// "status": "success",
// "agent": "gemini",
// "persona": "architect",
// "response": "GAS overkill for simple inventory; trade-offs ...",
// "metadata": { "duration_seconds": 8.4, "returncode": 0 }
// }
// Parallel cross-validation:
consult_parallel({
"agents": ["claude", "codex", "gemini"],
"prompt": "Reply with just the digit: what is 2+2?",
"persona": "default"
})
// → {
// "status": "success",
// "responses": [
// { "agent": "claude", "status": "success", "response": "4", ... },
// { "agent": "codex", "status": "success", "response": "4", ... },
// { "agent": "gemini", "status": "success", "response": "4", ... }
// ],
// "summary": { "total": 3, "succeeded": 3, "failed": 0, "wall_time_seconds": 9.1, "max_duration_seconds": 8.4 }
// }codereview({
"agents": ["codex", "gemini"],
"files": ["src/auth.py", "src/auth_test.py"],
"focus": "auth and session handling"
})
// → { "status": "success",
// "reviews": [
// { "agent": "codex", "status": "success", "response": "...",
// "findings": [
// {"severity": "high", "location": "src/auth.py:42",
// "title": "Missing CSRF check", "description": "..."}
// ]},
// { "agent": "gemini", ... }
// ],
// "summary": { "succeeded": 2, ... } }Each agent is invoked with the reviewer persona, which instructs it to return JSON {summary, findings: [{severity, location, title, description}]}. The tool parses that JSON; on parse failure, the raw response stays in reviews[i].response with a metadata.findings_parse_error flag.
consensus({
"agents": ["claude", "codex", "gemini"],
"question": "Should we adopt SQLite WAL mode for our writes?",
"stances": ["for", "against", "neutral"],
"synthesizer": "claude"
})
// → { "votes": [{...}, {...}, {...}],
// "synthesis": { "agent": "claude", "response": "Both sides agree..." } }Stances (for/against/neutral) prefix each agent's prompt. Optional synthesizer runs once more after the votes to produce a verdict.
challenge({
"agent": "claude",
"claim": "Premature optimization is always wrong; ignore performance until benchmarks fail."
})
// → { "agent": "claude", "persona": "skeptic",
// "response": "Counter: in real-time loops, even microseconds matter; ..." }Persona is hardcoded to skeptic. The agent is instructed to find weaknesses and counter-arguments rather than agree.
implement({
"agent": "codex",
"plan": "Add a /healthz endpoint to api/server.py returning {\"ok\": true}.",
"base_path": "F:/repos/my-app",
"constraints": "Don't modify tests/. Use existing FastAPI app."
})
// → { "status": "success",
// "mode": "git",
// "files_modified": ["api/server.py"],
// "files_created": [],
// "diff": { "text": "...", "stat": "1 file changed, 5 insertions(+)", ... } }This tool activates CLI mutation flags (--permission-mode acceptEdits, --dangerously-bypass-approvals-and-sandbox, --yolo). If base_path is a git repo → unified diff returned. If not → file list only (mtime detection). See Security & Limitations below before using.
For long deliberation between 2-6 agents — round-robin, runs in the background, transcript persists to SQLite for replay.
council
|
| |
Latency | Sync, ~min wait | Async, runs minutes-to-hours |
Stages | 3 (independent → rank → synthesis) | N round-robin turns |
Cancel | n/a |
|
Persistence | Transcript in response | Auto-saved to |
Best for | Quick verdict with explicit ranking | Open-ended debate where agents react to each other |
// Start a debate; returns id immediately:
debate_start({
"agents": ["claude", "codex", "gemini"],
"topic": "Should we move our analytics from PostgreSQL to ClickHouse?",
"max_turns": 10,
"history_window": 6,
"terminator": "any"
})
// → { "status": "success", "debate_id": "abc123...", "started_at": "..." }
// Poll progress (call as often as you like):
debate_status({ "debate_id": "abc123..." })
// → { "state": "running", "turn_count": 3, "transcript": [...] }
// When state == "completed":
// → { "state": "completed", "terminated_by": "done", "turn_count": 7, "transcript": [...] }
// Or cancel early:
debate_cancel({ "debate_id": "abc123..." })
// → { "already_finished": false, "requested_at": "..." }
// List debates (memory + archive):
debate_list({ "limit": 20 })
// Replay an old debate from SQLite:
debate_replay({ "debate_id": "abc123..." })
// Export as portable markdown (Obsidian-friendly frontmatter + transcript):
debate_export({ "debate_id": "abc123..." })
// → { "status": "success", "format": "md", "content": "---\nschema_version: 1\n..." }
// Or as stable JSON for programmatic consumers:
debate_export({ "debate_id": "abc123...", "format": "json" })
// → { "status": "success", "format": "json", "content": { "schema_version": 1, "turns": [...] } }
// Long transcripts: truncate per-turn bodies to fit MCP transport limits:
debate_export({ "debate_id": "abc123...", "truncate_body_chars": 2000 })debate_export returns either markdown (default, copy-pasteable into Obsidian/Notion) or stable JSON. The JSON shape is versioned via schema_version: 1; future breaking changes bump the version. Markdown frontmatter is generated through yaml.safe_dump, so user-controlled fields (topic, agent_name, error_message) cannot break it through :, \n or ---. Total response size is capped at 5 MiB — pass truncate_body_chars=N to fit larger transcripts. All five debate states (pending, running, completed, cancelled, error) are exportable; running snapshots are explicitly marked.
The terminator controls soft early-stop (DONE marker emitted by the agent). Hard caps (max_turns, external cancel, all_slots_down) are unconditional.
Spec | Behavior |
| OR(max_turns, done) — stops on either |
| Ignore DONE; always run to max_turns |
| Stop only on DONE (still bounded by max_turns hard cap) |
| Custom JSON expression |
DONE detection is word-boundary aware: "abandoned" does NOT match, "...DONE" does.
Single MCP call, ~min latency. Pattern from llm-council-mcp:
council({
"agents": ["claude", "codex", "gemini"],
"question": "Should we move analytics to ClickHouse?",
"chairman": "claude" // default = first agent
})
// → { "status": "success",
// "stage1": [...], // independent answers (parallel)
// "stage2": [...], // each agent ranks the anonymized responses
// "stage3": { ... }, // chairman synthesizes
// "stage2_parse_summary": { "json": 2, "fuzzy": 1, "unparseable": 0 } }Stage 2 anonymizes responses as Response A, Response B, etc. so agents rank by content quality, not by author.
planner({
"agent": "claude",
"problem": "Migrate the API from REST to gRPC, keeping the existing auth flow.",
"depth": "tree"
})
// → { "status": "success", "agent": "claude",
// "plan": {
// "summary": "Phased migration, 8 tasks",
// "tasks": [
// {"id":"T1","title":"Define proto schema","depends_on":[],"estimated_size":"M"},
// {"id":"T2","title":"Generate stubs","depends_on":["T1"],"estimated_size":"S"},
// ...
// ]
// },
// "depth": "tree" }Pass depth="flat" to force depends_on=[] for every task. On JSON parse failure, the tool returns parse_error: true with raw_response preserved.
// With raw diff text:
diff_review({
"agents": ["claude", "gemini"],
"diff_text": "diff --git a/auth.py b/auth.py\n@@ ...",
"focus": "security regressions"
})
// Or pulling from a git repo directly:
diff_review({
"agents": ["claude"],
"git_ref": "HEAD~3..HEAD",
"cwd": "F:/repos/my-app"
})Mutually exclusive: pass either diff_text (raw) OR git_ref + cwd. The reviewer persona is hardcoded.
apilookup({
"query": "Latest Anthropic Python SDK version + breaking changes vs 1.x"
})
// → { "agent": "gemini", "persona": "researcher_current",
// "response": "As of 2026-04, the SDK is at 2.x ..." }Default agent is gemini (web search built into the headless CLI). Other agents fall back to training-data answers and flag the staleness.
Eight built-in system prompts ship in v0.4:
Persona | Use case |
| Neutral helpful assistant |
| Design, trade-offs, system structure |
| Bugs, edge cases, security — returns severity-tagged JSON findings |
| Surveys alternatives, best practices, reference implementations |
| Same focus + emphasizes current docs / web sources / dates |
| Minimal practical code, no over-engineering |
| Anti-sycophancy — finds weaknesses, edge cases, counter-arguments |
| Structured task decomposition — outputs JSON task tree |
Create a markdown file at ~/.consult-mcp/personas/<name>.md:
---
name: security_reviewer
description: Focuses on auth, crypto, and OWASP top 10
---
You are a security-focused code reviewer. Concentrate on auth flaws,
crypto misuse, injection vectors, and OWASP top-10 risks. Skip generic
style feedback. Output severity-tagged findings as JSON.It's available immediately after the next server restart: consult({"agent":"claude","prompt":"...","persona":"security_reviewer"}).
The full file format, length limits, naming policy and parser-error matrix are
documented in Docs/persona-file-contract.md.
User personas in ~/.consult-mcp/personas/ override built-ins on name
collision — be explicit if that's what you want.
A small curated set of ready-to-copy personas lives in
examples/personas/community/ — currently
security_reviewer, perf_reviewer, and regex_explainer. Pick what you want
and cp it into ~/.consult-mcp/personas/. Names are guaranteed not to clash
with built-ins. New PRs welcome — see the community
README for contributing rules and the
validator (python -m scripts.validate_personas examples/personas/community)
that runs in CI.
Built-in CLI configs live in the package (read-only). To override the command, args, or timeout for any agent — drop a JSON file at ~/.consult-mcp/agents/<name>.json matching the schema:
{
"name": "claude",
"command": ["claude"],
"internal_args": ["--print", "--model", "opus"],
"timeout_seconds": 180,
"agent_class": "consult_mcp.agents.claude.ClaudeAgent"
}User overrides replace the built-in entirely (no merging). Restart the MCP client to pick up changes.
Symptom | Likely cause | Fix |
| CLI binary not in PATH |
|
| CLI took longer than 120s | pass |
| Missing | set the env var (see API keys section) |
| Claude Code not authenticated | run |
| Account/CLI version mismatch | upgrade the CLI: |
Server starts but no tools shown | Restart MCP client after install or | full restart (not just reload) |
| Python too old |
|
Read-only by default. consult, consult_parallel, codereview, consensus, and challenge invoke CLIs without mutation/sandbox-bypass flags. Agents return text answers; they do not edit files or execute commands.
implement is the only mutation-capable tool (v0.2). It activates --permission-mode acceptEdits (Claude), --dangerously-bypass-approvals-and-sandbox (Codex), and --yolo (Gemini). A malicious or careless prompt can delete files, exfiltrate secrets, or run arbitrary commands. Run implement in isolated repositories and code-review the resulting diff before trusting it. Mutation flags are kept in a separate mutation_args field per agent config and only applied when implement is called — they cannot leak into other tools.
Local-only. consult-mcp runs as a single process on a single machine. No cross-machine coordination, no daemon, no shared state.
Privacy. Prompts and responses pass through whichever LLM provider you've configured per CLI (Anthropic, OpenAI, Google). Don't send data you wouldn't paste into the respective web UIs. The persona system prompt is appended to every request.
Restart loss. Active debates (state in {pending, running}) live only in memory. Restarting the MCP client kills any in-flight debate — the asyncio task is gone, no resume, the transcript up to that point is NOT archived (archive only writes on terminal state). Completed debates are persisted to ~/.consult-mcp/archive.db and replayable via debate_replay.
Resource limits. debate_start rejects new starts when ≥ 5 debates are already active (override via CONSULT_MCP_MAX_ACTIVE_DEBATES env). This is a guard against accidental fork-bomb when multiple chained tool calls trigger debate creation.
Privacy of archive. ~/.consult-mcp/archive.db is plain SQLite, not encrypted. Anyone with file-system access can read transcripts. Don't run debates on data you wouldn't write to a plain file.
Iteration | Focus | Status |
IT-001 | MVP — | ✅ shipped (v0.1) |
IT-002 | Specialized — | ✅ shipped (v0.2) |
IT-003 | Async debate — | ✅ shipped (v0.3) |
IT-004 | Niche — | ✅ shipped (v0.4) |
IT-006 | Markdown export — | ✅ shipped (v0.6) |
IT-007 | Community personas pack + persona-file contract + validator | ✅ shipped (v0.7) |
IT-008 | Streaming — | ✅ shipped (v0.8) |
IT-010 | Composite — | ✅ this release (v0.10) |
Streaming progress notifications for async debates (MCP SSE)
Web UI / dashboard for archived debate replay
Community personas (PRs welcome)
Documentation site (Sphinx/MkDocs) once tool count > 15 or README > 800 lines
Detailed iteration plans live in Docs/plans/iterations/.
MIT — see LICENSE.
Look up current documentation for an API/library/SDK using web-capable CLI.
Use cases:
Verify an SDK's current version + breaking changes before upgrading
Find the canonical doc URL for a feature you only half-remember
Spot deprecations introduced in the last 12 months
Default agent is gemini (web search built in via the headless CLI). Other
agents will answer from training data and flag the staleness in their response.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| agent | No | gemini | |
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It reveals that the tool uses a headless CLI with web search capability (via the gemini agent) and that other agents answer from training data while flagging staleness. This is transparent and sets expectations appropriately for a lookup tool, though it does not mention potential side effects or rate limits.
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 and well-structured. It opens with a clear one-line statement of purpose followed by bullet-pointed use cases. Every sentence adds value, and the overall length is appropriate for the tool's complexity. There is no redundant or extraneous information.
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 that there is no output schema, the description would ideally explain what the tool returns. It does not mention the return value format or content. While the use cases and agent guidance are helpful, the agent may need to infer the output structure. The description provides adequate context for basic usage but lacks completeness on the result shape.
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 input schema has 0% description coverage for parameters, meaning the schema provides no documentation. The description compensates partially by explaining the 'agent' parameter's default and behavior, but it does not describe the 'query' parameter format (e.g., what kind of query is expected) or the 'timeout_seconds' parameter's purpose. This leaves significant gaps for the agent to infer.
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's purpose: 'Look up current documentation for an API/library/SDK using web-capable CLI.' It provides specific use cases that further clarify the intended actions. However, it does not explicitly differentiate from sibling tools, though the distinct verb and resource make it stand out among the provided siblings.
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 includes three concrete use cases that illustrate when to use the tool, such as verifying version changes or finding canonical URLs. It also offers guidance on agent selection, noting that the default 'gemini' provides web search via the CLI while other agents may return stale results. This provides context for usage, though it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push back on a claim — agent with skeptic persona finds counter-arguments.
Use cases:
Anti-sycophancy: counterweight to consultations that always seem to agree
Sanity-check a design before committing to it
Surface failure modes you might have missed
The persona is fixed to skeptic; passing a different persona is not allowed
(would defeat the tool's purpose).
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | ||
| claim | Yes | ||
| timeout_seconds | No |
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 discloses that the tool engages a skeptic persona to generate counter-arguments, indicating a non-destructive, analytical behavior. However, it does not explicitly state whether any state is modified or if there are side effects.
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, front-loads the purpose, lists use cases in bullet format, and ends with a constraint. Every sentence adds value and is easy to scan.
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 description lacks information about the return value (no output schema) and does not cover all parameters. Given the complexity (3 params, no annotations), more detail is needed for an agent to use it correctly without guessing.
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?
Input schema has 0% description coverage; the description does not explain the 'agent' or 'timeout_seconds' parameters. Only 'claim' is implicitly clear. The description mentions a fixed persona, which may conflict with the 'agent' parameter, causing confusion.
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 ('Push back') and resource ('a claim'), specifies the agent persona ('skeptic') and outcome ('finds counter-arguments'). It effectively distinguishes from siblings like 'consult' and 'consensus'.
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?
Explicit use cases are provided (anti-sycophancy, sanity-check, surface failure modes), and a clear constraint is given (persona fixed to skeptic). This tells when to use and when not to, aiding correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-agent code review.
Pattern: 'Claude implemented → Codex and Gemini review the code'.
Sends file contents to N agents in parallel with reviewer persona.
Each agent's response is parsed into severity-tagged findings; raw text is
preserved in response for any unparseable cases.
Use cases:
Validate Claude's code via Codex + Gemini perspectives
Surface bugs / edge cases / security issues
Identify regressions before merging
| Name | Required | Description | Default |
|---|---|---|---|
| agents | Yes | ||
| files | Yes | ||
| focus | No | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses parallel execution and parsing behavior, but does not mention whether the tool is read-only (likely), required permissions, or any limitations. More detail on behavioral traits would be helpful.
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 front-loaded with the core purpose, then adds behavior and use cases in a structured way. It is concise without being overly terse, though the pattern line could be integrated more smoothly.
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 4 parameters, no output schema, and no annotations, the description reasonably covers the tool's functionality and use cases. It mentions parsing, severity tags, and raw text fallback, which is sufficient for basic understanding.
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 has 0% description coverage, so the description adds some value by implying agents as 'reviewer personas' and files as 'file contents'. But it doesn't explicitly define each parameter beyond the naming. Focus and timeout_seconds remain vague.
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 'Cross-agent code review' and explains it sends file contents to N agents in parallel with reviewer personas, parsing responses into severity-tagged findings. This distinguishes it from siblings like consult or debate_run.
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?
Explicit use cases are given: validate Claude's code via Codex + Gemini perspectives, surface bugs/edge cases/security issues, identify regressions. This provides clear guidance on when to use, though it doesn't explicitly state when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-agent verdict with optional stance assignment + optional synthesis.
Use cases:
Force productive disagreement: stances=["for", "against", "neutral"]
Lightweight cross-validation when debate is overkill (one round per agent)
Explicitly named perspectives instead of implicit consensus
Distinct from consult_parallel because each agent can get a stance-steered
prompt; distinct from debate (IT-003) because it's one round, not round-robin.
| Name | Required | Description | Default |
|---|---|---|---|
| agents | Yes | ||
| question | Yes | ||
| stances | No | ||
| persona | No | default | |
| synthesizer | No | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the one-round nature and stance-steering per agent, but lacks details on side effects, return format, or state modifications. Adequate but not thorough.
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 well-structured with use cases and differentiation, concise with no redundant sentences. Every part adds value, though it could be slightly more compact.
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 (6 params, no output schema, no annotations), the description covers purpose, usage, and key behaviors fairly well. It lacks return value details but is still reasonably complete.
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 description must compensate. It explains the 'stances' parameter with an example, but does not describe agents, question, persona, synthesizer, or timeout_seconds. Partial compensation.
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 it produces a 'multi-agent verdict' with optional stances and synthesis, which is a specific verb and resource. It also differentiates from sibling tools like consult_parallel and debate, enhancing clarity.
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?
Explicit use cases are provided (force disagreement, lightweight cross-validation, explicit perspectives) along with clear distinction from two sibling tools, telling the agent when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a prompt to one CLI agent (claude/codex/gemini) and return its response.
Use cases:
Quick second opinion on an idea or design
Ask a specific model for its take on a problem
Get help from an agent specialized via persona
Available agents: claude, codex, gemini. Available personas: default, architect, reviewer, researcher, coder.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | ||
| prompt | Yes | ||
| persona | No | default | |
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions sending prompt and returning response, and lists agents/personas, but does not disclose rate limits, costs, idempotency, or error behavior. The timeout parameter is not explained.
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?
Very concise: 3 sentences plus bullet list. No fluff. Clear structure with sections for description, use cases, and available values.
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?
Description covers purpose and valid parameter values for agent/persona, but lacks details on return format, error handling, and timeout behavior. Output schema not provided, so return value info is minimal.
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 has 0% description coverage. Description adds value by listing valid agents and personas, which are not enum constrained in schema. However, it does not describe timeout_seconds or prompt format. Partially compensates for schema gaps.
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: 'Send a prompt to one CLI agent and return its response.' It lists use cases and available agents/personas. However, it does not explicitly differentiate from sibling tools like consult_parallel, which could cause confusion about when to use which.
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?
Provides use cases (quick second opinion, ask specific model, get help from specialist). Does not include when NOT to use or explicitly mention alternatives among siblings (e.g., consult_parallel for parallel queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fan-out the same prompt to multiple CLI agents in parallel.
Use cases:
Cross-validate: ask claude, codex, and gemini the same question
Variant generation: pass ["claude", "claude"] for two independent responses
Collect diverse perspectives on a design or claim
Wall time = max(per-agent latency), not sum. Duplicates are NOT deduplicated — each entry runs independently (intentional, supports variant generation).
| Name | Required | Description | Default |
|---|---|---|---|
| agents | Yes | ||
| prompt | Yes | ||
| persona | No | default | |
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behavioral traits: parallel execution, wall time equals max per-agent latency, and no deduplication of duplicates. This gives the agent important understanding of the tool's behavior, though it omits details like authentication or error handling.
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 and front-loaded with the core action. Use cases are presented as a bullet list, making them scannable. Every sentence adds value, though adding parameter explanations would improve structure without sacrificing brevity.
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 complexity of parallel CLI agents and the absence of an output schema and annotations, the description partially compensates by explaining use cases and wall time behavior. However, it lacks parameter details, error handling, and return value description, leaving gaps for a fully informed agent.
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 input schema has 0% description coverage, and the description text does not elaborate on any of the four parameters (agents, prompt, persona, timeout_seconds). The description focuses on use cases and behavior, leaving the agent to infer parameter meanings from names alone. This is insufficient.
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 'fan-outs the same prompt to multiple CLI agents in parallel', with explicit use cases (cross-validate, variant generation, diverse perspectives). It distinguishes itself from siblings like 'consult' (single agent) and 'council' by emphasizing parallelism and independent duplicate execution.
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 provides clear context for when to use the tool: for cross-validation, variant generation, and collecting diverse perspectives. It also notes that duplicates run independently. However, it does not explicitly mention when not to use or provide alternative tools, though the context is sufficient for an informed choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
3-stage council: independent → cross-rank (anonymized) → synthesis.
Use cases:
Atomic deliberation when you don't want to manage poll/cancel state
3-perspective review with explicit ranking step (reduces first-mover bias)
Quick consensus that's stronger than consult_parallel but lighter than debate
council_id registers a cancellation watermark with
CancellationRegistry. To cancel an in-flight council, the caller must
supply the id upfront and then bump the counter via
CancellationRegistry.request_cancel(id) from another in-process caller.
The MCP-exposed debate_cancel tool does NOT cover council ids — it
looks up DebateStore which has no council entries. Cancellation is
honoured between stages only; running subprocesses are never killed
mid-stage.
ctx is the FastMCP-injected context. When the client supports progress
notifications it sees three events (one per stage); otherwise emit is a
silent no-op.
Returns a dict with status ∈ {success, cancelled, failed}
plus partial: True when results are degraded (some stage1 vote failed,
or stage3 chairman failed). failed is reserved for "all stage1 voters
failed" — the council had nothing to deliberate on.
| Name | Required | Description | Default |
|---|---|---|---|
| agents | Yes | ||
| question | Yes | ||
| chairman | No | ||
| persona | No | default | |
| timeout_seconds | No | ||
| council_id | No | ||
| ctx | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It details the three stages, cancellation mechanism (between stages only), progress notifications, return status values (success, cancelled, failed, partial), and limitations regarding mid-stage cancellation.
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 detailed and front-loaded with the core process and use cases. It uses bullet points effectively. Some redundancy exists, but overall each sentence serves a purpose. Slightly longer than necessary but well-structured.
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 (3-stage, cancellation, progress) and lack of output schema, the description covers all essential aspects: stages, cancellation, progress, and return values. Minor gap in explaining the chairman role, but overall complete.
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 compensate. It adds significant value for council_id (cancellation watermark with CancellationRegistry) and ctx (FastMCP progress events). Other parameters (agents, question, etc.) are not elaborated beyond schema titles, but the context is inferable.
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 explicitly states the 3-stage council process (independent → cross-rank → synthesis) and distinguishes from sibling tools like consult_parallel and debate, making the tool's specific verb and resource clear.
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?
Provides explicit use cases (atomic deliberation, 3-perspective review, quick consensus) and compares with alternatives (consult_parallel, debate). Also notes that debate_cancel does not cover council ids, guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request cancellation of a running debate. Returns immediately.
If the debate is already finished (completed / cancelled / error), this is a
no-op and returns already_finished=true. The loop polls the cancellation
flag between turns, so cancellation may take up to one turn-latency to land.
| Name | Required | Description | Default |
|---|---|---|---|
| debate_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior: immediate return, idempotency (no-op for finished debates), and potential one-turn-latency. This is thorough and beyond minimal requirements.
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, with two short paragraphs covering purpose and behavior. Every sentence provides value, and there is no redundant information.
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 (one required parameter, no output schema), the description adequately covers all needed aspects: purpose, behavior, idempotency, and latency. No gaps remain.
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 description coverage, the description adds no extra meaning to the debate_id parameter beyond its name. Although the parameter is self-explanatory, the description does not compensate for the lack of schema details.
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 'Request cancellation of a running debate', using a specific verb and resource. It distinguishes from sibling tools like debate_start, debate_run, and debate_status, which are about starting or monitoring, not cancellation.
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 explains that cancellation applies to a running debate and that it is a no-op if already finished. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an archived/active debate as portable markdown or JSON.
format:
"md" — YAML-frontmatter + transcript markdown (default)
"json" — stable ExportPayload v1 dict
truncate_body_chars shortens per-turn body to at most N characters
(suffix "... (truncated)" added). Use to keep response under MCP transport
limits when transcripts are large.
| Name | Required | Description | Default |
|---|---|---|---|
| debate_id | Yes | ||
| format | No | md | |
| truncate_body_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavior: it explains format defaults and truncation mechanism. However, it does not mention whether the operation is read-only, required permissions, or any side effects.
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 well-structured: front-loaded main purpose, then separate sections for each parameter. No redundant sentences, though the backtick formatting for parameter names is slightly inconsistent.
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 no output schema and three parameters, the description covers the key aspects: what the tool does, format options, and a transport-related feature. However, it does not describe the return value structure or any error conditions, leaving some 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?
Schema coverage is 0%, but the description adds significant meaning to two of three parameters: explains 'format' values and default, and describes 'truncate_body_chars' purpose and behavior. Only 'debate_id' lacks elaboration, which is self-explanatory.
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 uses a specific verb 'render' and resource 'debate' and clearly distinguishes itself from sibling tools like debate_replay or debate_list by focusing on export to markdown/JSON.
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 usage for exporting debates, but provides no explicit guidance on when to use this tool over alternatives like debate_replay or debate_list, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List debates, sorted by started_at desc.
With active_only=True: only in-memory debates in pending/running state.
Otherwise: merge in-memory + archive (memory wins on id collision), then sort.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains behavioral details: sorting order, active_only filtering, and the merge logic with archive (memory wins on id collision). Since no annotations exist, this provides necessary transparency for an agent.
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—two clear sentences. The first states the primary purpose, the second adds behavior details. No unnecessary words or 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?
While the description covers core behavior, it lacks information about the output format (e.g., what fields are returned) and does not explain the limit parameter's role or pageination. Given no output schema, this is a gap.
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 adds meaning for the active_only parameter by specifying its effect, but it does not explain the limit parameter beyond its default in the schema. With 0% schema description coverage, the description only partially compensates.
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 debates sorted by started_at descending, providing a specific verb and resource. However, it does not explicitly differentiate this listing tool from siblings like debate_cancel or debate_export, which slightly reduces clarity.
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 vs. alternatives. It does not mention any prerequisites, when to use active_only, or contrast with other debate-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return full transcript for a debate (memory first, then archive).
| Name | Required | Description | Default |
|---|---|---|---|
| debate_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions a two-step retrieval strategy (memory then archive) but omits key details: potential side effects (none expected), authentication needs, error behavior for invalid debate IDs, or response format. Minimal transparency for a read operation.
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?
A single, front-loaded sentence with no extraneous words. Every part adds value: the verb, resource, and caching strategy. Ideal length for a straightforward retrieval tool.
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 has one parameter and no output schema, so the description should explain what 'full transcript' includes (e.g., turns, metadata, timestamps). It fails to specify return value details, error responses, or limitations (e.g., archive availability). An agent lacks full information to verify correct usage or handle failures.
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 only parameter debate_id has no description in the schema (0% coverage). The tool description does not explain what debate_id is, how to obtain it (e.g., from debate_list), expected format, or constraints. The agent receives no semantic help beyond the parameter name and type.
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 'Return full transcript for a debate', specifying the verb (return), resource (transcript), and scope (full, for a debate). It distinguishes from siblings like debate_list (lists debates) and debate_export (likely export format). The caching hint 'memory first, then archive' adds specificity.
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 such as debate_export or debate_status. The caching hint is about execution, not selection criteria. The description does not address prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an async round-robin debate to completion, streaming progress.
Same arguments as debate_start plus the FastMCP-injected ctx. Returns
when the loop terminates (max_turns / done / cancel / all_slots_down /
error). Per-turn progress is emitted via ctx.report_progress if the
client supports it (silently no-op otherwise).
Return shape (IT-008/C-01 taxonomy):
status: "success" — debate completed normally
status: "cancelled" — external debate_cancel honoured between turns
status: "failed" — agent registry not initialised, all slots down,
zero successful turns, or unhandled exception in the loop
| Name | Required | Description | Default |
|---|---|---|---|
| agents | Yes | ||
| topic | Yes | ||
| max_turns | No | ||
| history_window | No | ||
| persona | No | default | |
| terminator | No | any | |
| timeout_seconds_per_turn | No | ||
| ctx | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: streaming via ctx.report_progress, termination conditions (max_turns, done, cancel, etc.), and return status taxonomy. This is highly transparent.
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 with a front-loaded purpose, a single sentence for arguments, and bullet points for return statuses. Every sentence adds value without 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?
Given no output schema, the description explains return shapes and streaming. It covers termination conditions and statuses but lacks details on error handling or side effects. Reasonably complete for a complex tool.
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 compensate. It adds that arguments are same as debate_start plus ctx (injected). While this links to another description for details, it doesn't elaborate on each parameter's meaning. The added value is moderate.
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 an async round-robin debate to completion with streaming progress, and distinguishes from siblings by noting it shares arguments with debate_start. It covers termination conditions and return statuses, making the purpose very 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?
The description implies use for completing a debate, referencing same arguments as debate_start. However, it doesn't explicitly state when to use this vs alternatives like debate_start or debate_cancel. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an async round-robin debate. Returns debate_id immediately.
The loop runs in the background; poll debate_status(debate_id) for progress
and final transcript. Use debate_cancel(debate_id) to abort early.
Use cases:
Long deliberation between 2-6 agents (each round ≈ per-agent latency)
When you want to step away and check back later
Need a transcript saved for replay (auto-archived in SQLite on completion)
| Name | Required | Description | Default |
|---|---|---|---|
| agents | Yes | ||
| topic | Yes | ||
| max_turns | No | ||
| history_window | No | ||
| persona | No | default | |
| terminator | No | any | |
| timeout_seconds_per_turn | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses async behavior (returns immediately, background loop), polling requirement, cancellation capability, and auto-archiving in SQLite. However, it doesn't mention needed permissions or potential destructive actions.
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 with three short paragraphs. It front-loads the action and return value, then explains background processing, and ends with use cases. Every sentence adds value without 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?
Given 7 parameters, no output schema, and no parameter descriptions, the description fails to cover inputs. It does explain the async pattern and return of debate_id, but the lack of parameter guidance makes it incomplete.
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%, yet the description does not explain any parameters. The 7 parameters (e.g., agents, topic, max_turns) are only named in the schema, leaving the agent to infer meaning from names alone.
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 'Start an async round-robin debate' with a specific verb and resource. It distinguishes from sibling tools like debate_status and debate_cancel by explicitly mentioning polling and cancellation. The use cases further clarify its 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?
The description provides explicit use cases for long deliberation, stepping away, and needing a transcript. It mentions polling and cancellation as alternatives. While it doesn't explicitly say when not to use it, the context implies it's for non-immediate results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current status of a debate (pending/running/completed/cancelled/error).
| Name | Required | Description | Default |
|---|---|---|---|
| debate_id | Yes |
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 correctly indicates a read operation (get status) and enumerates possible statuses. However, it does not disclose the return format, latency expectations, or any side effects (none expected). For a simple read tool, this is minimally adequate.
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 a single, well-structured sentence with no unnecessary words. It front-loads the core action and includes specific examples of statuses.
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, the description is adequate but not thorough. It lacks mention of the return value (e.g., just a status string or full debate object) and does not set expectations for error cases like invalid debate_id. With no output schema, more detail would be helpful.
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 input schema has 0% description coverage. The description does not add any information about the debate_id parameter beyond its implicit purpose. No format or constraints are given, so the agent must rely entirely on the schema's title and type.
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 action ('Get current status') and the resource ('a debate'). It lists possible statuses, which helps distinguish from action-oriented siblings like debate_run or debate_cancel. However, it does not explicitly differentiate it from other query tools like debate_list, which returns all debates.
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 provides no guidance on when to use this tool versus alternatives (e.g., debate_list for listing debates, or debate_export for exporting). No prerequisites or context for when to invoke are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan → implement → review in one MCP call.
The composite tool runs three stages sequentially:
Plan via the planner tool (planner_agent).
Implement via the implement tool (implementer_agent;
mutation flags enabled). base_path must be allow-listed via
CONSULT_MCP_ALLOWED_BASE exactly as for implement.
Review via diff_review or codereview (reviewer_agents,
in parallel). Choice is automatic based on implement's output:
a unified git diff routes to diff_review; otherwise the list of
modified files routes to codereview.
Returns one of:
{"status": "success", ...} — all three stages ok
{"status": "partial_success", ...} — implement ok, ≥1 reviewer
failed or review skipped
{"status": "partial_error", "stage_failed": "implement", ...} —
implement failed; review run best-effort against any partial diff
{"status": "error", "stage_failed": "plan", ...} — planner failed,
downstream stages skipped
The tool never raises — all errors are surfaced as structured fields.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| base_path | Yes | ||
| planner_agent | No | claude | |
| implementer_agent | No | codex | |
| reviewer_agents | No | ||
| plan_depth | No | tree | |
| plan_timeout | No | ||
| implement_timeout | No | ||
| review_timeout | No | ||
| constraints | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures include all possible return statuses with structured fields, that it never raises, the auto-selection of review based on output, and mutation flags for implement. No annotations provided, so description carries full burden. Lacks explicit mention of authorization or side effects beyond mutation.
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?
Well-structured with bullet points and code blocks for return types. Efficiently conveys complex workflow without redundancy. Slightly lengthy but justified by complexity.
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 10 parameters, no output schema, and no annotations, the description covers workflow and error handling well but lacks parameter guidance. Incomplete for full parameter understanding.
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 description must compensate. Only base_path's allow-listing is mentioned; task, agent selections, timeouts, plan_depth, constraints are not explained. Users must infer most parameter meanings from context or external knowledge.
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 the tool's purpose as a three-stage pipeline (plan → implement → review) in one MCP call. It distinguishes itself from sibling tools like planner, implement, diff_review, and codereview that handle individual stages.
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?
Provides explicit context: when you want a complete pipeline, notes that base_path must be allow-listed, explains automatic routing between diff_review and codereview, and states that it never raises errors. Could be more explicit about when to use composite vs individual tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review a git diff for risks, regressions, and breaking changes.
Pass either diff_text (raw unified diff) OR git_ref + cwd
(the tool runs git diff <ref> in cwd for you). Mutually exclusive.
Use cases:
Pre-merge sanity check on a PR's diff
Spot accidental breaking changes when refactoring
Cross-validate a branch against multiple reviewer agents
| Name | Required | Description | Default |
|---|---|---|---|
| agents | Yes | ||
| diff_text | No | ||
| git_ref | No | ||
| cwd | No | ||
| focus | No | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose read-only behavior, side effects, or limitations. It implies a review operation but does not confirm no mutable actions. Basic but insufficient.
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?
Very concise, front-loaded purpose, efficient bullet points. No unnecessary 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?
Despite good explanation of core functionality, the description omits details about required parameter 'agents', output format, and other optional parameters. Incomplete for a 6-param tool with no output schema.
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 has 0% description coverage. The description explains diff_text and git_ref+cwd relationship but does not describe required 'agents' parameter or 'focus' and 'timeout_seconds'. Only partial compensation.
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 reviews git diffs for risks, regressions, and breaking changes, using a specific verb and resource. It distinguishes from sibling tools like codereview by focusing on git diffs and specific risk detection.
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?
Provides explicit use cases (pre-merge sanity check, spotting breaking changes, cross-validation) and explains the mutually exclusive input modes. Does not explicitly state when not to use or compare with siblings, but covers main scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delegate implementation to a CLI agent that can edit files in base_path.
Use cases:
'Claude designs → Codex implements → Claude+Gemini review' workflow
Apply a refactor proposal across files without manual edits
Hand off boilerplate work to a different model
Activates the agent's mutation flags (e.g. --permission-mode acceptEdits for
Claude). The tool returns a diff of files the agent created/modified/deleted.
base_path MUST be an absolute path. A relative path is resolved against the
MCP server process's cwd (NOT the calling user's terminal cwd), which is rarely
what the caller intends and may land in an unexpected directory.
If base_path is a git repo: full unified diff is returned.
If not: only the list of changed files (mtime-detected, no diff text).
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | ||
| plan | Yes | ||
| base_path | Yes | ||
| constraints | No | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool activates mutation flags, returns a diff, and differentiates behavior between git and non-git repositories. It also warns about the path resolution context. Missing details on failure modes or missing base_path behavior.
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 well-structured with a clear lead sentence, use cases, and detailed notes. It is slightly longer than necessary but every sentence serves a purpose. Could be slightly more concise by removing redundant phrasing.
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 complexity (5 parameters, 3 required, no output schema, no annotations), the description covers the core purpose and behavior well but lacks parameter-level documentation for most parameters. It does not describe return details beyond the diff summary, nor error handling or edge cases. An output schema 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 description coverage is 0% (no parameter descriptions in schema). The description only explains the 'base_path' parameter in detail (absolute path requirement, relative resolution, git behavior). Other parameters ('agent', 'plan', 'constraints', 'timeout_seconds') receive no explanation in the description, failing to compensate for the lack of schema documentation.
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's purpose: delegating implementation to a CLI agent that edits files in a base path. The verb 'delegate' and resource 'implementation to a CLI agent' are specific, and the tool is distinguished from siblings like 'delegate_implementation' by the detailed behavioral notes.
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 provides explicit use cases (e.g., 'Claude designs → Codex implements' workflow) and important usage notes (absolute path requirement, relative path resolution behavior). However, it does not explicitly state when not to use this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decompose a problem into atomic tasks with optional dependencies.
Use cases:
Break a feature request into ordered work items before implementation
Surface parallelizable branches in a multi-step task
Get a starting structure that the orchestrator can iterate on
depth="flat" returns a flat list (depends_on=[] always); depth="tree"
(default) lets the agent model dependencies for parallel execution.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | ||
| problem | Yes | ||
| depth | No | tree | |
| timeout_seconds | No |
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 explains the two depth modes and that dependencies are optional, but does not disclose any behavioral traits like side effects, permissions, or limits. This is acceptable for a read-like planning tool, but leaves some transparency gaps.
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, using bullet points and inline code formatting. It front-loads the core purpose in the first sentence, then provides use cases and parameter details without unnecessary 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?
There is no output schema and no annotations, so the description needs to explain the return format and behavior thoroughly. It only mentions that depth=flat returns a flat list and depth=tree models dependencies, but does not specify the structure of the tasks (e.g., fields like id, description, depends_on). Several parameters lack explanation, making the description incomplete for an agent to fully understand the tool's behavior.
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 compensate. It adds meaning for the depth parameter by explaining its modes. However, agent and problem parameters are not elaborated beyond their names, and timeout_seconds is not mentioned. The description partially covers the parameter semantics but not fully.
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's purpose: 'Decompose a problem into atomic tasks with optional dependencies.' It provides specific use cases like breaking feature requests and surfacing parallelizable branches, which distinguish it from sibling tools such as implement or codereview.
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 gives concrete use cases and explains when to use different depth modes (flat vs tree). It does not explicitly state when not to use the tool, but the use cases effectively guide appropriate contexts, making the usage fairly clear.
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. Dates show when Glama detected each change.
v0.10.1apilookupchallengecodereviewconsensusconsultconsult_parallelcouncildebate_canceldebate_exportdebate_listdebate_replaydebate_rundebate_startdebate_statusdelegate_implementationdiff_reviewimplementplannerEach tool targets a distinct workflow or function, from single-agent consult to multi-stage debate and code implementation. Descriptions clarify nuances between similar tools (e.g., consult_parallel vs. consensus vs. council), leaving no ambiguity.
All tool names follow a consistent snake_case verb_noun pattern (e.g., consult_parallel, debate_run, delegate_implementation). The convention is uniform and predictable across all 18 tools.
At 18 tools, the server is ambitious but well-scoped for its domain of multi-agent orchestration and code assistance. While extensive, each tool earns its place with specific use cases; the count does not feel excessive for the breadth of functionality.
The tool surface covers the full lifecycle of agent interactions: quick consult, parallel fan-out, structured consensus, multi-round debate with replay/export, planning, implementation, and code review. No obvious gaps exist for the stated purpose of MCP-based consulting.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/oblogin/consult-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
