MCP Rubber Duck

Official

by HoziMurayama

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.20.1
Disambiguation3/5
Most tools have distinct purposes, but compare_ducks and duck_council both retrieve responses from multiple ducks, creating potential confusion. The other multi-duck tools (vote, judge, iterate, debate) are well-separated, but the overlap between these two is notable.
Naming Consistency2/5
Tool naming is inconsistent: list_ducks, list_models, ask_duck, chat_with_duck, clear_conversations, and get_usage_stats follow a verb_noun pattern, while duck_council, duck_vote, duck_judge, duck_iterate, and duck_debate use a 'duck_' prefix with the action as a suffix. compare_ducks also breaks the pattern by placing the verb first. This mixed style makes tool names less predictable.
Tool Count5/5
12 tools is a well-scoped count for this server's purpose of managing and interacting with multiple LLM providers. It covers basic listing, single queries, conversations, multi-duck collaboration modes, and usage tracking without feeling bloated.
Completeness4/5
The toolkit covers the core workflow well: listing providers and models, asking questions, maintaining conversations, running multi-duck scenarios, and tracking usage. A minor gap is the lack of a tool to fetch or manage individual conversation histories, but this is not critical for the primary use cases.
Average 3.9/5 across 12 of 12 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 24 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.
This repository includes a glama.json configuration file.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the basic safety profile. The description adds that this targets a specific provider ('duck'), but it doesn't disclose whether conversations are stateful, how errors are handled, or what the returned response looks like. With annotations present, the bar is lower, and the description is acceptable but minimal.
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, concise sentence that directly states the core function without any fluff. It is appropriately sized for a simple querying 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?
With no output schema and only a minimal description, the tool is incomplete for an agent. It doesn't mention the return format, whether conversation context is maintained, or how it differs from chat_with_duck. The schema and annotations are rich, but the description should clarify these behavioral aspects to be fully contextual.
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 100%, with every parameter (model, images, prompt, provider, temperature) having a clear description. The tool description adds little beyond the schema, only reinforcing that the provider is specific. Baseline 3 is appropriate because the schema already carries the semantic weight.
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 verb 'ask' and the resource 'a specific LLM provider (duck)', which is precise about the action. However, it does not distinguish this from sibling tools like chat_with_duck or duck_council, which could also involve asking questions.
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 versus alternatives such as chat_with_duck or compare_ducks. The description does not mention exclusions, prerequisites, or typical use cases beyond a generic 'ask a question'.
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?
The description adds the behavioral detail of context maintenance, which goes beyond the openWorldHint annotation. It does not disclose other potential behaviors such as persistence, returns, or side effects beyond what openWorldHint indicates.
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 concise sentence with no filler words, efficiently conveying the core function.
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?
The tool is relatively simple, but with no output schema and minimal annotations, the description could elaborate on the expected response format or the role of the duck. The mention of context maintenance is helpful, but overall the description 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 descriptions cover 100% of parameters, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides.
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 function as having a conversation with a duck and explicitly mentions maintaining context across messages. However, it does not differentiate from sibling tools like ask_duck or duck_debate, which may also involve interaction.
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?
The description implies the tool is for multi-turn interactions due to 'maintaining context across messages'. It does not provide explicit guidance on when to use this versus alternatives like ask_duck or duck_council.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows it is a safe read operation. The description adds value by stating the output includes vote tally, confidence scores, and consensus level, but it does not disclose details like how votes are aggregated, whether the operation is stochastic, or what happens when no voters are specified (though that is in the schema). It is adequate but not rich.
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 sentence that front-loads the action and then lists the key returns. Every word earns its place with no waste or redundancy. It is concise and well-structured.
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 presence of an output schema (though not shown in the input schema chunk), the description need not explain return details beyond what it states. The description covers the essential purpose and primary outcomes for a voting tool. It is slightly brief but sufficient for the tool's complexity, so a 4 rather than a 5.
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 100%, so parameters are already well-documented. The description adds minimal new meaning, only referencing 'options' and 'reasoning' which are already in the schema. The baseline of 3 is appropriate since the schema does the heavy lifting.
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: 'Have multiple ducks vote on options with reasoning.' It specifies the action (vote), the subject (multiple ducks), and the object (options). It also distinguishes from siblings like ask_duck (single duck) and list_ducks (listing), and uniquely mentions returning vote tally, confidence scores, and consensus level.
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?
The description implies usage for multi-duck voting, which differentiates it from single-duck tools, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. For example, it doesn't say 'For a single duck's opinion, use ask_duck instead.' The context is inferred rather than explicitly guided.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds that status is included in the result, but does not disclose any additional behavioral details such as health check behavior or output format. No contradiction with annotations.
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?
Single sentence, front-loaded with the verb and resource, no wasted words.
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?
The description accurately captures the core listing function and the status inclusion. However, it does not mention the optional health check capability, and there is no output schema, so a bit more detail on return shape could be beneficial.
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 covers 100% of the parameter description, so the description adds no additional meaning. It doesn't mention the check_health parameter, but the schema already specifies it.
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?
States clearly it lists all available LLM providers (ducks) and their status. Distinguishes from siblings like list_models and compare_ducks by specifying the resource and action.
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 the primary use case (listing providers) but does not explicitly compare to alternatives like list_models, nor state when not to use it. The use case is implied rather than spelled out.
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?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds the scope 'all' and the concept of 'start fresh', which is mildly informative. However, it does not disclose any side effects or irreversibility beyond what the annotation implies, so it adds limited value on top of annotations.
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 concise sentence ('Clear all conversation history and start fresh') that front-loads the verb and resource. It contains no fluff or redundancy, earning every word.
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?
For a simple tool with no parameters, no output schema, and clear annotations, the description fully covers the required context. It states exactly what the tool does, and the destructive and idempotent hints cover the operational caveats.
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?
The tool has zero parameters and schema coverage is trivially 100%, so there is nothing for the description to explain. The baseline for 0 parameters is 4, and the description correctly avoids inventing parameter 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 uses the specific verb 'Clear' and names the resource 'conversation history', making the tool's function immediately obvious. It distinguishes from sibling tools like chat_with_duck or ask_duck, which are about interacting with conversations rather than clearing them.
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. It does not mention prerequisites, exceptions, or contrast with other conversation-related tools, leaving the agent to infer context from the name alone.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not burdened with safety disclosure. It adds the behavioral detail of simultaneous multi-duck queries, but does not elaborate on concurrency behavior, error handling, or provider limits. This is adequate but not rich.
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, concise sentence that immediately conveys the core function. Every word is purposeful, with no filler or 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 the tool's moderate complexity (4 parameters, one required), the provided output schema, and the annotations, the description is largely complete for a simple comparative tool. It does not explain what 'ducks' represents or how providers are selected, but the schema and tool naming cover this. Slight gap: no mention of default provider behavior when providers is omitted.
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 100%, so all four parameters (prompt, model, images, providers) are already well documented in the schema. The description adds the conceptual 'same question' mapping to the prompt but offers no extra semantic value beyond the schema, warranting the baseline score.
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 function: asking the same question to multiple ducks simultaneously. It specifies the verb ('ask'), resource ('ducks'), and scope ('same question', 'multiple... simultaneously'), distinguishing it from siblings like ask_duck (single duck) and duck_council.
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: when you want multiple answers to the same question in parallel. However, it does not explicitly mention when not to use it or name alternatives like duck_debate or duck_council, which could be useful for differentiation.
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 adds behavioral context beyond the annotations (readOnlyHint, openWorldHint) by describing the tool as a structured multi-round process with specific formats. It clearly communicates that the tool orchestrates a debate, which involves multiple turns or rounds. Since annotations already cover safety, this additional process-level detail is valuable and non-contradictory.
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, front-loaded sentence: 'Structured multi-round debate between ducks.' It immediately conveys the core action and then efficiently lists the three supported formats. Every word earns its place; no filler or 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 the comprehensive schema (100% coverage, enums, defaults) and presence of an output schema, the description adequately covers essential context: it names the tool's primary function and format options. It does not explicitly mention multi-provider support or synthesizer handling, but those are fully documented in the schema, so the description need not repeat them. The one-sentence explanation is sufficient for a read-only, well-specified 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 100%, so the baseline is 3. The description repeats the format enum values and their meanings already present in the schema (e.g., 'oxford (pro/con)'), adding no additional semantic value. It does not explain rounding behavior or provider selection beyond what the schema provides.
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: 'Structured multi-round debate between ducks.' It specifies the action (debate), the resource (ducks), and differentiates from siblings like ask_duck (Q&A) and duck_vote (voting) by naming three distinct debate formats (oxford, socratic, adversarial). This makes the tool's function unambiguous.
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?
The description implies usage for debate scenarios but does not explicitly state when to use this tool versus alternatives like duck_council or duck_judge. It lacks direct 'use when' or 'instead of' guidance, though the format list gives some context for selecting debate styles. No exclusions or alternative tools are mentioned.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds behavioral context about alternating rounds and the division of roles (generate vs critique/improve). This enriches understanding without contradicting annotations.
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 two concise sentences, front-loaded with the core action and role structure. It contains no wasted words and is easy to parse.
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 moderate complexity, full schema coverage, and annotations, the description is largely complete. It covers the essential iterative mechanic and role alternation, though it could mention what the final output looks like.
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 100%, so the lack of explicit parameter details in the description is acceptable. The schema fully documents all parameters, including enums, defaults, and constraints, so the description adds no extra semantic meaning.
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 refines responses via two ducks alternating roles, with one generating and the other critiquing/improving. This distinguishes it from sibling tools like duck_debate or duck_council, which involve different interaction patterns.
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?
The description implies usage for iterative response refinement between two ducks but does not explicitly state when to choose this over alternatives such as duck_debate or duck_council. No exclusions or alternative comparisons are provided.
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?
The annotations already provide readOnlyHint=true and openWorldHint=true, establishing the safety profile. The description adds no additional behavioral context, such as whether a cached list is used by default or any potential side effects. It does not contradict the annotations but also does not enrich them.
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, concise sentence that front-loads the action and resource. Every word earns its place, with zero redundancy or filler.
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?
For a simple read-only listing tool, the description is adequate. The annotations and schema cover safety and parameter semantics, leaving no obvious gaps. However, without an output schema, the description does not explicitly state what a 'list' returns, though it is implied.
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 input schema documents both parameters with descriptions and covers 100% of parameters. The description does not add any semantic detail beyond the schema, so the baseline score of 3 is appropriate.
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 ('List') and resource ('available models for LLM providers'), clearly indicating the tool's function. It is easily distinguished from sibling tools, which are all duck-related.
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 implicitly indicates when to use the tool (whenever a list of available models is needed), but it does not explicitly mention any alternatives or exclusions. Since sibling tools are unrelated, this clarity is sufficient, though it lacks explicit guidance on provider selection or fetch_latest behavior.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate safety. It adds useful behavioral context: the panel discussion metaphor implies multiple responses from each duck, possibly in a coordinated manner. It does not contradict annotations. This goes beyond the structured fields.
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, efficiently worded sentence. It uses an analogy to convey meaning without unnecessary detail. Every word earns its place, making it highly concise and well-structured.
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 simplicity (3 well-described params, read-only, no output schema), the description covers the core purpose and usage context adequately. It doesn't detail the exact response format, but that is mitigated by the clear schema and the read-only annotation. The panel discussion analogy provides enough context for an agent to decide when to use it.
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 100%, with each parameter (prompt, model, images) already documented in detail. The description adds no extra parameter semantics beyond what the schema provides, so baseline score of 3 is appropriate.
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: 'Get responses from all configured ducks.' The analogy 'like a panel discussion' further clarifies the intent, and the phrase 'all configured ducks' distinguishes it from sibling tools like ask_duck, which likely targets a single duck. This provides specific verb+resource+scope.
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 clear context for when to use the tool—when you want a panel-style collection of responses from all ducks. It implicitly contrasts with ask_duck (single duck) and other debate/vote tools, but does not explicitly list when not to use or name alternatives. This matches 'clear context, no 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?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds the notable behavioral detail that costs are shown only when pricing is configured, which is useful context beyond the annotations. No contradictions.
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 sentence, front-loaded with the primary action, and every word contributes to understanding the tool. No fluff or 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?
For a simple tool with one optional parameter, an output schema, and read-only annotations, the description adequately covers purpose and the key output detail (token counts/costs). It does not specify scope, but that is not a critical gap given the tool's simplicity.
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 input schema fully documents the only parameter 'period' with a description and enum, so the schema provides complete parameter semantics. The description's mention of 'time period' aligns with the schema but adds no additional parametric meaning.
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 retrieves usage statistics for a time period, using the specific verb 'get' and resource 'usage statistics'. It also specifies the content (token counts and costs), distinguishing it from sibling tools about models/ducks.
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 clear context: this tool is used when you need usage statistics over a time period. It does not explicitly name alternatives or exclusions, but the sibling list and purpose make the usage context obvious.
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 annotations already declare readOnlyHint and openWorldHint, and the description adds the core comparative ranking behavior. It does not contradict the annotations. However, it doesn't elaborate on how the ranking is returned or whether it involves external model calls beyond the schema's judge enum, leaving some behavioral detail implicit.
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 exactly two sentences, front-loaded with the key verb ('evaluate and rank') and includes a usage instruction. No filler or repetition; every word earns its place.
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?
The description is adequate given the comprehensive schema and annotations: it states the action, the workflow position, and the purpose. The only gap is the lack of detail on the output format of the ranking (since no output schema exists), but the word 'rank' implies a comparative result, which is likely sufficient for an agent.
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 coverage is 100% with clear descriptions for all four parameters (judge, persona, criteria, responses). The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 a specific action ('evaluate and rank') on a specific resource ('other ducks' responses'). The phrase 'after duck_council' anchors its role relative to sibling tools like duck_council, compare_ducks, and duck_vote, making it unambiguous.
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?
It gives explicit guidance: 'Use after duck_council to get a comparative evaluation.' This tells the agent when to use it (following duck_council) and the purpose, distinguishing it from alternatives like compare_ducks or duck_vote that may serve different comparison workflows.
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:

[![Multi-LLM-Debugging-Bridge MCP server](https://glama.ai/mcp/servers/HoziMurayama/Multi-LLM-Debugging-Bridge/badges/card.svg)](https://glama.ai/mcp/servers/HoziMurayama/Multi-LLM-Debugging-Bridge)

Score Badge

Copy to your README.md:

[![Multi-LLM-Debugging-Bridge MCP server](https://glama.ai/mcp/servers/HoziMurayama/Multi-LLM-Debugging-Bridge/badges/score.svg)](https://glama.ai/mcp/servers/HoziMurayama/Multi-LLM-Debugging-Bridge)

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/HoziMurayama/Multi-LLM-Debugging-Bridge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server