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 "Deploy 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 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.
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.
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.
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.
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.
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.
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, 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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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=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.
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.19.6ask_duckchat_with_duckclear_conversationscompare_ducksduck_councilduck_debateduck_iterateduck_judgeduck_voteget_usage_statslist_duckslist_modelsv1.19.5ask_duckchat_with_duckclear_conversationscompare_ducksduck_councilduck_debateduck_iterateduck_judgeduck_voteget_usage_statslist_duckslist_modelsv1.2.3ask_duck4 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / imagesAdded value: +{
+ "description": "Optional images to include with the prompt (for vision-capable models)",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "data": {
+ "description": "Base64-encoded image data",
+ "type": "string"
+ },
+ "mimeType": {
+ "description": "MIME type (e.g., \"image/png\") — required for base64 data, optional for URLs",
+ "type": "string"
+ },
+ "url": {
+ "description": "Image URL — passed directly to the LLM provider",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Input schema / properties / provider / enumAdded value: +[
+ "openai",
+ "google",
+ "groq",
+ "ollama"
+]chat_with_duck4 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / imagesAdded value: +{
+ "description": "Optional images to include with the message (for vision-capable models)",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "data": {
+ "description": "Base64-encoded image data",
+ "type": "string"
+ },
+ "mimeType": {
+ "description": "MIME type (e.g., \"image/png\") — required for base64 data, optional for URLs",
+ "type": "string"
+ },
+ "url": {
+ "description": "Image URL — passed directly to the LLM provider",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Input schema / properties / provider / enumAdded value: +[
+ "openai",
+ "google",
+ "groq",
+ "ollama"
+]compare_ducks5 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / imagesAdded value: +{
+ "description": "Optional images to include with the prompt (for vision-capable models)",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "data": {
+ "description": "Base64-encoded image data",
+ "type": "string"
+ },
+ "mimeType": {
+ "description": "MIME type (e.g., \"image/png\") — required for base64 data, optional for URLs",
+ "type": "string"
+ },
+ "url": {
+ "description": "Image URL — passed directly to the LLM provider",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Input schema / properties / providers / items / enumAdded value: +[
+ "openai",
+ "google",
+ "groq",
+ "ollama"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "responses": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "content": {
+ "type": "string"
+ },
+ "error": {
+ "type": "string"
+ },
+ "latency": {
+ "type": "number"
+ },
+ "model": {
+ "type": "string"
+ },
+ "nickname": {
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "tokens": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "completion": {
+ "type": "number"
+ },
+ "prompt": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "prompt",
+ "completion",
+ "total"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "provider",
+ "nickname",
+ "model",
+ "content",
+ "latency",
+ "tokens"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "responses"
+ ],
+ "type": "object"
+}duck_council3 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / imagesAdded value: +{
+ "description": "Optional images to include with the prompt (for vision-capable models)",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "data": {
+ "description": "Base64-encoded image data",
+ "type": "string"
+ },
+ "mimeType": {
+ "description": "MIME type (e.g., \"image/png\") — required for base64 data, optional for URLs",
+ "type": "string"
+ },
+ "url": {
+ "description": "Image URL — passed directly to the LLM provider",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}duck_debate5 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / providers / items / enumAdded value: +[
+ "openai",
+ "google",
+ "groq",
+ "ollama"
+]Input schema / properties / synthesizer / enumAdded value: +[
+ "openai",
+ "google",
+ "groq",
+ "ollama"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "format": {
+ "enum": [
+ "oxford",
+ "socratic",
+ "adversarial"
+ ],
+ "type": "string"
+ },
+ "participants": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "nickname": {
+ "type": "string"
+ },
+ "position": {
+ "enum": [
+ "pro",
+ "con",
+ "neutral"
+ ],
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "provider",
+ "nickname",
+ "position"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "rounds": {
+ "items": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "content": {
+ "type": "string"
+ },
+ "nickname": {
+ "type": "string"
+ },
+ "position": {
+ "enum": [
+ "pro",
+ "con",
+ "neutral"
+ ],
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "round": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "round",
+ "provider",
+ "nickname",
+ "position",
+ "content"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "type": "array"
+ },
+ "synthesis": {
+ "type": "string"
+ },
+ "synthesizer": {
+ "type": "string"
+ },
+ "topic": {
+ "type": "string"
+ },
+ "totalRounds": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "topic",
+ "format",
+ "totalRounds",
+ "participants",
+ "rounds",
+ "synthesis",
+ "synthesizer"
+ ],
+ "type": "object"
+}duck_iterate3 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / providers / items / enumAdded value: +[
+ "openai",
+ "google",
+ "groq",
+ "ollama"
+]duck_judge4 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / judge / enumAdded value: +[
+ "openai",
+ "google",
+ "groq",
+ "ollama"
+]Input schema / properties / responses / items / additionalPropertiesAdded value: +falseduck_vote4 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / voters / items / enumAdded value: +[
+ "openai",
+ "google",
+ "groq",
+ "ollama"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "confidenceByOption": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "type": "object"
+ },
+ "consensusLevel": {
+ "enum": [
+ "unanimous",
+ "majority",
+ "plurality",
+ "split",
+ "none"
+ ],
+ "type": "string"
+ },
+ "isTie": {
+ "type": "boolean"
+ },
+ "options": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "question": {
+ "type": "string"
+ },
+ "tally": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "type": "object"
+ },
+ "totalVoters": {
+ "type": "number"
+ },
+ "validVotes": {
+ "type": "number"
+ },
+ "votes": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "choice": {
+ "type": "string"
+ },
+ "confidence": {
+ "type": "number"
+ },
+ "nickname": {
+ "type": "string"
+ },
+ "reasoning": {
+ "type": "string"
+ },
+ "voter": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "voter",
+ "nickname",
+ "choice",
+ "confidence",
+ "reasoning"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "winner": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "question",
+ "options",
+ "winner",
+ "isTie",
+ "tally",
+ "confidenceByOption",
+ "votes",
+ "totalVoters",
+ "validVotes",
+ "consensusLevel"
+ ],
+ "type": "object"
+}get_usage_statslist_ducks2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falselist_models3 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / provider / enumAdded value: +[
+ "openai",
+ "google",
+ "groq",
+ "ollama"
+]Scored across 12 tools
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.
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
