The mcp-rubber-duck server orchestrates multiple LLMs (OpenAI-compatible APIs and CLI coding agents) for querying, collaboration, and structured AI workflows.
Core Querying
ask_duck: Query a single LLM with optional model/temperature control
chat_with_duck: Multi-turn conversations with persistent context; switch providers mid-conversation
compare_ducks: Send the same prompt to multiple providers simultaneously for side-by-side comparison
duck_council: Get responses from all configured LLMs at once
Collaborative Workflows
duck_vote: Multi-duck voting on 2–10 options with reasoning and confidence scores
duck_judge: One duck evaluates and ranks other ducks' responses using customizable criteria
duck_iterate: Two ducks iteratively refine a response (up to 10 rounds, 'refine' or 'critique-improve' mode)
duck_debate: Structured debates in Oxford, Socratic, or adversarial formats with an optional synthesizer duck
Management & Monitoring
list_ducks: View all configured providers with optional real-time health checks
list_models: Browse available models per provider
get_usage_stats: Track token usage and estimated costs
clear_conversations: Wipe stored conversation history
Additional Features
8 reusable prompt templates (e.g., perspectives, tradeoffs, red_team) for structured analysis
Rich HTML panels for compare, vote, debate, and usage views in supporting clients
Guardrails: rate limiting, token limits, PII redaction
Automatic failover to alternative providers
Vision input support for compatible models
MCP Bridge for connecting to other MCP servers with per-server approval controls
Enables querying Google's Gemini language models (including Gemini 2.5 Flash and Gemini 2.0 Flash) through OpenAI-compatible API endpoints
Enables interaction with locally-hosted language models through Ollama's OpenAI-compatible API endpoint for private AI conversations
Provides direct integration with OpenAI's language models including GPT-4 and GPT-3.5 for AI conversations and queries
Provides access to Perplexity's online language models with web search capabilities through OpenAI-compatible endpoints
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-rubber-duck Can you help me debug this Python function that's returning None unexpectedly?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that acts as a bridge to query multiple LLMs -- both OpenAI-compatible HTTP APIs and CLI coding agents. Just like rubber duck debugging, explain your problems to various AI "ducks" and get different perspectives!
Why direct provider integration? MCP's
samplingprimitive -- a server borrowing the host's model -- was deprecated in the 2026-07-28 spec RC in favor of servers integrating directly with LLM provider APIs. Rubber Duck has always worked this way (it brings its own ducks), so it's aligned with where the protocol is heading -- no migration required.
Universal OpenAI Compatibility -- Works with any OpenAI-compatible API endpoint
CLI Agent Support -- Use CLI coding agents (Claude Code, Codex, Gemini CLI, Grok, Aider) as ducks
Multiple Ducks -- Configure and query multiple LLM providers simultaneously
Conversation Management -- Maintain context across multiple messages
Duck Council -- Get responses from all your configured LLMs at once
Consensus Voting -- Multi-duck voting with reasoning and confidence scores
LLM-as-Judge -- Have ducks evaluate and rank each other's responses
Iterative Refinement -- Two ducks collaboratively improve responses
Structured Debates -- Oxford, Socratic, and adversarial debate formats
MCP Prompts -- 8 reusable prompt templates for multi-LLM workflows
Vision Input -- Send images alongside prompts to vision-capable models (docs)
Automatic Failover -- Falls back to other providers if primary fails
Health Monitoring -- Real-time health checks for all providers
Usage Tracking -- Track requests, tokens, and estimated costs per provider
MCP Bridge -- Connect ducks to other MCP servers for extended functionality (docs)
Guardrails -- Pluggable safety layer with rate limiting, token limits, pattern blocking, and PII redaction (docs)
Granular Security -- Per-server approval controls with session-based approvals
Interactive UIs -- Rich HTML panels for compare, vote, debate, and usage tools (via MCP Apps)
Tool Annotations -- MCP-compliant hints for tool behavior (read-only, destructive, etc.)
Structured Output -- outputSchema on tools returning structured JSON for client-side validation (Cursor, VS Code/Copilot)
Spec-Aligned by Design -- connects directly to provider APIs, the path the MCP 2026-07-28 spec recommends now that server-side sampling is deprecated (SEP-2577)
Related MCP server: mcp-llm
Any provider with an OpenAI-compatible API endpoint, including:
OpenAI
Google Gemini
Anthropic (via OpenAI-compatible endpoints)
Groq (fast inference for open-weight models)
Together AI (broad open-weight model catalog)
Perplexity (online models with web search)
Anyscale, Azure OpenAI, Ollama, LM Studio, Custom
Command-line coding agents that run as local processes:
Claude Code (claude) -- Codex (codex) -- Gemini CLI (gemini) -- Grok CLI (grok) -- Aider (aider) -- Custom
See CLI Providers for full setup and configuration.
# Install globally
npm install -g mcp-rubber-duck
# Or use npx directly in Claude Desktop config
npx mcp-rubber-duckUsing Claude Desktop? Jump to Claude Desktop Configuration. Using Cursor, VS Code, Windsurf, or another tool? See the Setup Guide.
Node.js 20 or higher
npm or yarn
At least one API key for an HTTP provider, or a CLI coding agent installed locally
npm install -g mcp-rubber-duckgit clone https://github.com/nesquikm/mcp-rubber-duck.git
cd mcp-rubber-duck
npm install
npm run build
npm startCreate a .env file or config/config.json. Key environment variables:
Variable | Description |
| OpenAI API key |
| Google Gemini API key |
| Groq API key |
| Default provider (e.g., |
| Default temperature (e.g., |
|
|
| Set to |
| Enable MCP Bridge (ducks access external MCP servers) |
| Custom HTTP providers |
| Enable CLI agents ( |
Full reference: Configuration docs
Four tools -- compare_ducks, duck_vote, duck_debate, and get_usage_stats -- can render rich interactive HTML panels inside supported MCP clients via MCP Apps. Once this MCP server is configured in a supporting client, the UIs appear automatically -- no additional setup is required. Clients without MCP Apps support still receive the same plain text output (no functionality is lost). See the MCP Apps repo for an up-to-date list of supported clients.
Compare multiple model responses side-by-side, with latency indicators, token counts, model badges, and error states.
Have multiple ducks vote on options, displayed as a visual vote tally with bar charts, consensus badge, winner card, confidence bars, and collapsible reasoning.
Structured multi-round debate between ducks, shown as a round-by-round view with format badge, participant list, collapsible rounds, and synthesis section.
Usage analytics with summary cards, provider breakdown with expandable rows, token distribution bars, and estimated costs.
Tool | Description |
| Ask a single question to a specific LLM provider |
| Conversation with context maintained across messages |
| Clear all conversation history |
| List configured providers and health status |
| List available models for providers |
| Ask the same question to multiple providers simultaneously |
| Get responses from all configured ducks |
| Usage statistics and estimated costs |
| Multi-duck voting with reasoning and confidence |
| Have one duck evaluate and rank others' responses |
| Iteratively refine a response between two ducks |
| Structured multi-round debate between ducks |
| MCP Bridge status and connected servers |
| Pending MCP tool approval requests |
| Approve or deny a duck's MCP tool request |
Full reference with input schemas: Tools docs
Prompt | Purpose | Required Arguments |
| Multi-angle analysis with assigned lenses |
|
| Surface hidden assumptions in plans |
|
| Hunt for overlooked risks and gaps |
|
| Structured option comparison |
|
| Security/risk analysis from multiple angles |
|
| Problem reframing at different levels |
|
| Design review across concerns |
|
| Divergent exploration then convergence |
|
Full reference with examples: Prompts docs
npm run dev # Development with watch mode
npm test # Run all tests
npm run lint # ESLint
npm run typecheck # Type check without emitTopic | Link |
Setup guide (all tools) | |
Full configuration reference | |
Claude Desktop setup | |
All tools with schemas | |
Prompt templates | |
CLI coding agents | |
MCP Bridge | |
Guardrails | |
Docker deployment | |
Provider-specific setup | |
Usage examples | |
Architecture | |
Roadmap |
Check API key is correctly set
Verify endpoint URL is correct
Run health check: list_ducks({ check_health: true })
Check logs for detailed error messages
For local providers (Ollama, LM Studio), ensure they're running
Check firewall settings for local endpoints
Verify network connectivity to cloud providers
Configure failover to alternate providers
Adjust max_retries and timeout settings
See Guardrails for rate limiting configuration
__
<(o )___
( ._> /
`---' Quack! Ready to debug!We love contributions! Whether you're fixing bugs, adding features, or teaching our ducks new tricks, we'd love to have you join the flock.
Check out our Contributing Guide to get started.
Quick start for contributors:
Fork the repository
Create a feature branch
Follow our conventional commit guidelines
Add tests for new functionality
Submit a pull request
MIT License - see LICENSE file for details
Inspired by the rubber duck debugging method
Built on the Model Context Protocol (MCP)
Uses OpenAI SDK for HTTP provider compatibility
Supports CLI coding agents (Claude Code, Codex, Gemini CLI, Grok, Aider)
See CHANGELOG.md for a detailed history of changes and releases.
NPM Package: npmjs.com/package/mcp-rubber-duck
Docker Images: ghcr.io/nesquikm/mcp-rubber-duck
MCP Registry: Official MCP server io.github.nesquikm/rubber-duck
Glama Directory: glama.ai/mcp/servers/@nesquikm/mcp-rubber-duck
Awesome MCP Servers: Listed in the community directory
Report issues: https://github.com/nesquikm/mcp-rubber-duck/issues
Documentation: https://github.com/nesquikm/mcp-rubber-duck/wiki
Discussions: https://github.com/nesquikm/mcp-rubber-duck/discussions
Happy Debugging with your AI Duck Panel!
Ask a question to a specific LLM provider (duck)
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Specific model to use (optional, uses provider default if not specified) | |
| images | No | Optional images to include with the prompt (for vision-capable models) | |
| prompt | Yes | The question or prompt to send to the duck | |
| provider | No | The provider name (optional, uses default if not specified) | |
| temperature | No | Temperature for response generation (0-2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the main behavioral traits. Description adds no further details (e.g., response format, rate limits), but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, it is too brief and could include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description does not specify the output or return format. Given no output schema, the agent needs to infer what the tool returns (e.g., text response). Complexity moderate, but description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all 5 parameters, so the schema itself provides clear semantics. Description adds minimal value beyond implying the prompt is the question.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool asks a question to a specific LLM provider. It is specific about the resource and action, but does not differentiate from sibling tools like 'chat_with_duck'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., chat_with_duck, compare_ducks). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Have a conversation with a duck, maintaining context across messages
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Specific model to use (optional) | |
| images | No | Optional images to include with the message (for vision-capable models) | |
| message | Yes | Your message to the duck | |
| provider | No | Provider to use (can switch mid-conversation) | |
| conversation_id | Yes | Conversation ID (creates new if not exists) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that it 'maintain[s] context across messages', indicating statefulness. However, it does not disclose other behavioral traits such as persistence of conversations, side effects of switching provider/model, or how images are handled. The annotation 'openWorldHint: true' signals potential side effects, but the description does not elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Have' and the core purpose. No redundant words; every part is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, multiple providers, optional images) and no output schema, the description is adequate but could be more thorough. It captures the essential chat functionality and context maintenance, but does not mention that the tool supports multiple models or image input (though schema covers it).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already explains each parameter. The description adds minimal semantic value beyond stating that context is maintained (linking to conversation_id). Without schema coverage limitations, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Have a conversation with a duck, maintaining context across messages'. It uses a specific verb ('Have a conversation') and resource ('a duck'), and it implicitly distinguishes from siblings like 'ask_duck' (likely single question) and 'compare_ducks' (comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-turn conversations (by mentioning 'maintaining context') but does not explicitly state when to use this tool versus alternatives like 'duck_council' or 'duck_debate'. No guidance on when not to use it or what preconditions exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all conversation history and start fresh
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint: true, idempotentHint: true, and openWorldHint: false. The description aligns with these (clear = destructive) but adds no new behavioral context beyond what annotations offer, such as permission requirements or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. Every word earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool with clear annotations, the description completely covers the tool's purpose. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so baseline is 3. The description adds no parameter information, which is fine as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clear all conversation history and start fresh' provides a specific verb and resource, clearly stating the tool's action. It distinguishes itself from siblings like chat_with_duck or list_ducks by being the only tool dedicated to clearing conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, consequences, or scenarios where clearing is appropriate, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the same question to multiple ducks simultaneously
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Specific model to use for all providers (optional) | |
| images | No | Optional images to include with the prompt (for vision-capable models) | |
| prompt | Yes | The question to ask all ducks | |
| providers | No | List of provider names to query (optional, uses all if not specified) |
| Name | Required | Description |
|---|---|---|
| responses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=true, so the description adds no extra behavioral context beyond aligning with those traits. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste, perfectly efficient for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given good annotations and full schema coverage, the description covers essential aspects. However, it omits details about the response format or how results from multiple ducks are presented, which could be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with full descriptions for all 4 parameters; the description adds no 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'ask' and resource 'multiple ducks simultaneously', which distinguishes it from siblings like ask_duck (single duck) and duck_debate (debate format).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for parallel queries but does not explicitly state when to use versus alternatives like duck_debate or duck_council, nor provides when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get responses from all configured ducks (like a panel discussion)
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Specific model to use for all ducks (optional) | |
| images | No | Optional images to include with the prompt (for vision-capable models) | |
| prompt | Yes | The question for the duck council |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the panel discussion analogy but no additional behavioral traits beyond that. It does not disclose any side effects or expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (9 words) that is front-loaded with the verb and resource. Every word earns its place; there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should hint at the return format (e.g., combined responses, ordering) but does not. It also fails to explicitly state that all ducks respond simultaneously or how the responses are presented. Gaps exist for a multi-duck tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all three parameters have descriptions). The description does not add meaning beyond the schema—no mention of prompt format, model purpose, or image usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get responses from all configured ducks', specifying both the verb and the resource. It distinguishes from siblings like 'ask_duck' (single duck) and 'duck_debate' (back-and-forth) by emphasizing a collective panel discussion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'panel discussion' analogy implies usage for collective opinions, but no explicit when-to-use or when-not-to-use guidance is provided. It does not list alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structured multi-round debate between ducks. Supports oxford (pro/con), socratic (questioning), and adversarial (attack/defend) formats.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | Debate format: oxford (pro/con), socratic (questioning), adversarial (attack/defend) | |
| prompt | Yes | The debate topic or proposition | |
| rounds | No | Number of debate rounds (default: 3) | |
| providers | No | Provider names to participate (min 2, uses all if not specified) | |
| synthesizer | No | Provider to synthesize the debate (optional, uses first provider) |
| Name | Required | Description |
|---|---|---|
| topic | Yes | |
| format | Yes | |
| rounds | Yes | |
| synthesis | Yes | |
| synthesizer | Yes | |
| totalRounds | Yes | |
| participants | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: multi-round nature and format options. Annotations already declare readOnlyHint=true and openWorldHint=true, so the description complements rather than repeats. Could mention output or side effects, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no filler. Every word earns its place. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, output schema exists), the description covers core functionality. It omits details like provider defaults or output nature, but those are covered by the schema. Nearly complete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage), so baseline is 3. The description adds parenthetical explanations for formats (e.g., 'pro/con'), enhancing understanding beyond the schema's enum labels. Slight value-add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool conducts 'structured multi-round debate between ducks' and lists three distinct formats. It distinguishes from sibling tools like ask_duck, chat_with_duck, and compare_ducks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for debates but provides no explicit guidance on when to use this tool versus alternatives like duck_judge or compare_ducks. No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Iteratively refine a response between two ducks. One generates, the other critiques/improves, alternating for multiple rounds.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | refine: each duck improves the previous response. critique-improve: alternates between critiquing and improving. | |
| prompt | Yes | The initial prompt/task to iterate on | |
| providers | Yes | Exactly 2 provider names for the ping-pong iteration | |
| iterations | No | Number of iteration rounds (default: 3, max: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with refinement. The description adds that it alternates rounds but does not clarify return format (final response vs all steps) or potential side effects (openWorldHint=true is ambiguous).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that captures the essence efficiently. However, it lacks front-loaded key details such as what the tool returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description is insufficient. It does not explain the output format, how results are presented, or the exact behavior of the iteration process (e.g., what the final result is).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters. The description adds no additional parameter-level details beyond the high-level process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool iteratively refines a response between two ducks with generating and critiquing roles. It distinguishes from sibling tools like duck_debate or duck_council by specifying the ping-pong refinement process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for iterative refinement but does not explicitly state when to use versus alternatives like duck_debate or duck_council. No exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Have one duck evaluate and rank other ducks' responses. Use after duck_council to get a comparative evaluation.
| Name | Required | Description | Default |
|---|---|---|---|
| judge | No | Provider name of the judge duck (optional, uses first available) | |
| persona | No | Judge persona (e.g., "senior engineer", "security expert") | |
| criteria | No | Evaluation criteria (default: ["accuracy", "completeness", "clarity"]) | |
| responses | Yes | Array of duck responses to evaluate (from duck_council output) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds no additional behavioral traits beyond stating it evaluates/ranks. No contradictions, but no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence that includes purpose and usage. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Coverage of parameters is complete. Missing output schema or description of return format is a minor gap, but overall context is sufficient for a simple evaluation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The tool description does not add meaning beyond what the schema already provides, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates and ranks duck responses. It differentiates itself from siblings like duck_council by specifying it is used after that step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use after duck_council', giving clear guidance on when to invoke 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.
Have multiple ducks vote on options with reasoning. Returns vote tally, confidence scores, and consensus level.
| Name | Required | Description | Default |
|---|---|---|---|
| voters | No | List of provider names to vote (optional, uses all if not specified) | |
| options | Yes | The options to vote on (2-10 options) | |
| question | Yes | The question to vote on (e.g., "Best approach for error handling?") | |
| require_reasoning | No | Require ducks to explain their vote (default: true) |
| Name | Required | Description |
|---|---|---|
| isTie | Yes | |
| tally | Yes | |
| votes | Yes | |
| winner | Yes | |
| options | Yes | |
| question | Yes | |
| validVotes | Yes | |
| totalVoters | Yes | |
| consensusLevel | Yes | |
| confidenceByOption | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, which cover some behavioral aspects. The description adds return values but does not disclose potential side effects like API costs or network calls beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is clear and front-loaded, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basics but does not explain the voting process (e.g., how many ducks, aggregation logic), though the parameters provide relevant details. Output schema exists, so return value details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the schema (coverage 100%), so the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a voting action involving multiple 'ducks' on options with reasoning, which is specific and distinguishes from other duck tools like 'duck_debate' or 'duck_council'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'duck_debate' or 'duck_council'. The description implies usage for consensus, but lacks exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get usage statistics for a time period. Shows token counts and costs (when pricing configured).
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Time period for stats | today |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| period | Yes | |
| totals | Yes | |
| endDate | Yes | |
| startDate | Yes | |
| costByProvider | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: costs shown only when pricing configured. Annotations already declare readOnlyHint and openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences, front-loaded with purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description sufficiently covers purpose and behavior. Mentions token counts and cost dependence on pricing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema fully describes the 'period' parameter with enum and default. Description doesn't add new param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get usage statistics for a time period', with specific resource and verb. Distinguishes from sibling duck-focused tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for tracking token counts and costs over time, but no explicit when-to-use or alternatives. Sibling tools are mostly duck-related, so context helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available LLM providers (ducks) and their status
| Name | Required | Description | Default |
|---|---|---|---|
| check_health | No | Perform health check on all providers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds 'status' but no further behavioral traits like pagination or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no unnecessary words. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description covers the core functionality adequately. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter well-described. Description does not add extra context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list' and resource 'LLM providers (ducks)' with status. Distinguishes from sibling tools like ask_duck, chat_with_duck, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over siblings like list_models or get_usage_stats. Context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available models for LLM providers
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Provider name (optional, lists all if not specified) | |
| fetch_latest | No | Fetch latest models from API vs using cached/configured |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering safety and variability. The description adds 'available models' scope but does not disclose behavioral details like caching defaults or API interaction beyond what the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets the point across without wasted words. It could be slightly more informative but is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool with only two optional parameters and full schema descriptions, the description adequately covers the purpose. No output schema is needed for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions. The tool description does not add any meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing available models for LLM providers. It uses a specific verb 'List' and resource 'models', and distinguishes itself from sibling tools that focus on duck-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies the tool is for listing models, but does not specify scenarios or alternatives, though no obvious alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct interaction mode: single question, multi-turn conversation, comparing ducks, council, debate, iterative refinement, judging, voting, and administrative tasks. No two tools have overlapping purposes.
Tool names mix patterns: some use verb_duck (ask_duck, chat_with_duck), others use duck_noun (duck_council, duck_debate), and one lacks 'duck' entirely (clear_conversations). While readable, the inconsistency in prefixing and structure is notable.
12 tools perfectly cover the intended domain of multi-LLM interactions without being excessive. Each tool adds a unique capability, and the set feels well-scoped for the server's purpose.
The tool surface covers all major interaction styles (single, chat, compare, council, debate, iterative, judge, vote) plus administration. Minor gaps include lack of per-duck configuration or conversation clearing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server to manage a restaurant menu from AI agents - 39 tools over the DuckHub API.
MCP server for AI dialogue using various LLM models via AceDataCloud
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
An MCP server that gives your AI access to the source code and docs of all public github repos
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nesquikm/mcp-rubber-duck'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
