consult-mcp

by oblogin

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.10.1
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness5/5
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.
Average 3.8/5 across 18 of 18 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![consult-mcp MCP server](https://glama.ai/mcp/servers/oblogin/consult-mcp/badges/card.svg)](https://glama.ai/mcp/servers/oblogin/consult-mcp)

Score Badge

Copy to your README.md:

[![consult-mcp MCP server](https://glama.ai/mcp/servers/oblogin/consult-mcp/badges/score.svg)](https://glama.ai/mcp/servers/oblogin/consult-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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