# Reported issues for rubber-duck

Pod holds 23 of 52 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [rubber-duck](/mcp/rubber-duck).

## Most discussed

### duck_debate 'Failed to retrieve task' error + suggestions for filesystem access and fire-and-forget wrapper

# Bug: duck_debate intermittently fails with "Failed to retrieve task: Task not found"

## Description

`duck_debate` intermittently fails with `MCP error -32602: Failed to retrieve task: Task not found`. This occurs randomly — not related to prompt size or provider selection. When it fails, ALL subsequent tool calls (compare_ducks, ask_duck, etc.) also fail for ~50s (the MCP client's 3-retry cycle).

## Root Cause (traced through source)

`duck_debate` is the only tool using `registerToolTask()

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/127) · 2026-07-19 · closed · external user · 4 comments

### 🚀 Migrate to Bun Runtime

# 🚀 Migrate to Bun Runtime

## Summary

Migrate MCP Rubber Duck from Node.js/npm to Bun as the primary runtime for faster builds, tests, and development experience.

**Approach:** Hybrid migration - Bun for runtime/build/test, Node.js for npm publish (due to [missing provenance support](https://github.com/oven-sh/bun/issues/15601) and [auth bugs in CI](https://github.com/oven-sh/bun/issues/24124)).

## Motivation

- **Speed**: Bun installs packages 20-40x faster than npm
- **Native TypeScript**:

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/41) · 2026-01-24 · open · 3 comments

### feat: Duck Autopilot - Automatic task decomposition & workflows

## 🦆 Duck Enhancement Proposal

```
     __
   <(o )___
    ( ._> /   "Quack! Just tell me your goal, I'll handle the rest!"
     `---'
```

### 💡 The Problem
**What problem would this feature solve?**

Complex tasks currently require manual orchestration:
- Users must decompose tasks into steps themselves
- Manual selection of which duck/tool to use for each step
- No automatic error recovery or replanning
- Can't leverage the full power of multi-duck + MCP tools together

### 🚀 Proposed Soluti

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/12) · 2026-01-08 · open · 3 comments

### feat: Streamable HTTP transport support

## 🦆 Duck Enhancement Proposal

### 💡 The Problem
The server currently only supports stdio transport, limiting deployment to local processes launched by MCP clients. This prevents:
- Remote/cloud deployment
- Horizontal scaling
- Web-based access
- Future Server Cards support (requires HTTP)

### 🚀 Proposed Solution
Add Streamable HTTP transport alongside existing stdio transport.

**Benefits:**
- Deploy as a standalone HTTP service
- Support multiple concurrent clients
- Enable cloud/container 

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/57) · 2026-02-05 · open · 2 comments

### feat: Add human-readable title to all tools

## 🦆 Duck Enhancement Proposal

### 💡 The Problem
Tools only have `name` and `description` fields. The MCP spec now supports a `title` field for human-readable display names, which improves UI presentation in clients.

### 🚀 Proposed Solution
Add `title` field to all tool definitions for better UX in MCP clients.

**Example:**
```typescript
this.server.tool('duck_council', {
  title: 'Duck Council',
  description: 'Convene multiple ducks to discuss a topic and reach consensus',
  // ...
})
```

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/54) · 2026-02-05 · closed · 2 comments

### feat: Add outputSchema to voting/consensus tools

## 🦆 Duck Enhancement Proposal

### 💡 The Problem
Tool results from voting and consensus tools (`duck_vote`, `duck_council`, `duck_judge`, etc.) return structured JSON data, but clients have no way to validate or understand the expected output format without inspecting the response.

### 🚀 Proposed Solution
Add `outputSchema` definitions to tools that return structured data. This is supported in the MCP spec (2025-11-25) and helps:
- Clients validate responses
- LLMs better understand returned d

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/53) · 2026-02-05 · closed · 2 comments

### feat: MCP Prompts - Expose discoverable prompt templates

## Summary
Implement MCP Prompts capability to expose reusable, discoverable prompt templates that clients like Claude Desktop can list, autocomplete, and invoke.

## Background

### What Are MCP Prompts?
Prompts are **reusable, discoverable prompt templates** that MCP servers expose to clients. Think of them as "slash commands" that clients can list, autocomplete, and invoke.

**Key difference from Tools:**
- **Tools** = Actions the LLM executes (functions)
- **Prompts** = Pre-built conversatio

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/23) · 2026-01-13 · closed · 2 comments

### feat: Duck Observability & Tracing

## 🦆 Duck Enhancement Proposal

```
     __
   <(o )___
    ( ._> /   "Quack! I see everything that happens in the pond!"
     `---'
```

### 💡 The Problem
**What problem would this feature solve?**

Currently, there's limited visibility into:
- Token usage and costs per request/provider
- Latency breakdown across providers
- Cache hit/miss rates
- Historical usage patterns
- Debugging failed or slow requests

### 🚀 Proposed Solution
**What would you like to happen?**

Add comprehensive observab

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/11) · 2026-01-08 · closed · 2 comments

## Most recent

### duck_council: add a synthesis-only output mode (return the final report, not every duck's response)

Motivated by the "fire-and-forget wrapper" suggestion in #127.

`duck_council` currently returns **every duck's full verbose response**. When an agent offloads a whole council workflow, all of that lands in the caller's context.

### Ask
Add a **synthesis-only** output mode (or a verbosity flag) to `duck_council` — return just the final synthesized report instead of each duck's full answer. Optionally a `mode: full | synthesis` param, defaulting to current behavior for back-compat.

### Why this

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/131) · 2026-07-21 · open · 1 comment

### Docs: read-only filesystem MCP Bridge recipe (+ trusted-tools-gates-calls-not-tools caveat)

Requested in #127: give ducks read-only file access (source, configs, PDFs) during code review without manual copy-paste.

This already works today via the MCP Bridge — no code change needed. Any third-party filesystem MCP server plugs in through the existing env vars:

```yaml
MCP_SERVER_FS_TYPE: stdio
MCP_SERVER_FS_COMMAND: npx
MCP_SERVER_FS_ARGS: -y,@modelcontextprotocol/server-filesystem,/path/to/allowed/dir
MCP_SERVER_FS_ENABLED: 'true'
MCP_TRUSTED_TOOLS_FS: '*'
```

### Ask
Add a documente

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/130) · 2026-07-21 · closed · 1 comment

### MCP Bridge: global MCP_TRUSTED_TOOLS='*' ignored + server-name derivation can force approval prompts

Surfaced while investigating #127 (fixed in v1.20.1). The `MCP_APPROVAL_MODE=trusted` + `MCP_TRUSTED_TOOLS_*='*'` bypass works for the common **per-server** case, but two real edge cases can still force an approval prompt. `MCP_APPROVAL_MODE=never` is a working workaround meanwhile.

### 1. Global `MCP_TRUSTED_TOOLS='*'` is silently ignored

- `src/config/config.ts` parses `MCP_TRUSTED_TOOLS='*'` into a literal `Set(['*'])`.
- But the global fallback branch in `src/services/function-bridge.ts` c

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/129) · 2026-07-21 · open · 1 comment

### feat: duck_check — cross-vendor GO/BLOCK/ASK-HUMAN action gate for agents

## 🦆 Duck Enhancement Proposal

```
     __
   <(o )___
    ( ._> /   "Quack! Before you run that migration... let me get a second opinion."
     `---'
```

### 💡 The Problem
**What problem would this feature solve?**

When a coding agent (Claude Code / Cursor / Codex) is about to take a **risky action** — apply a diff, run a DB migration, execute a shell command, delete files — there is no cheap, cross-vendor "second opinion gate" it can consult *before* executing.

A single-model self-check is

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/120) · 2026-06-09 · open · 1 comment

### feat: duck_judge Panel — debiased multi-provider judging (position-bias swap, judge panel, agreement confidence, outputSchema)

## 🦆 Duck Enhancement Proposal

```
     __
   <(o )___
    ( ._> /   "I'll judge fairly... unless you put yourself first in the list."
     `---'
```

### 💡 The Problem

`duck_judge` exists to settle which duck gave the best answer — but today it does so with a **single, position-biased, schema-less** judge. That's exactly the part of the pipeline most vulnerable to silent, systematic error:

1. **One judge, no bias cancellation.** The judge defaults to the *first available provider* (`src/tool

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/119) · 2026-06-09 · open · 0 comments

### feat: Server Card (/.well-known/mcp/server-card.json)

## Summary

Implement Server Card support per draft spec SEP-1649 for auto-discovery by clients and crawlers without establishing a connection.

Split from #100 (Registry publish is done).

## References

- #49
- [SEP-1649: Server Cards](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1649)

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/101) · 2026-04-03 · open · 0 comments

### feat: MCP Registry publish + Server Card

## Summary

Remaining items from #97 — Registry listing and Server Card support.

## Items

- [ ] **Publish to MCP Registry** — namespace `io.github.nesquikm/rubber-duck` is ready. Use `mcp-publisher` CLI to list in the [official registry](https://registry.modelcontextprotocol.io/).
- [ ] **Server Card** (`/.well-known/mcp/server-card.json`) — #49. Draft spec (SEP-1649) for auto-discovery by clients and crawlers without establishing a connection.

## References

- [MCP Registry](https://registry

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/100) · 2026-04-03 · closed · 1 comment

### feat: Server Card (.well-known/mcp/server-card.json) for pre-connection discovery

## Summary

Implement [MCP Server Cards](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1649) (SEP-1649) — expose a `.well-known/mcp/server-card.json` endpoint for pre-connection discovery.

Split from #97 (item 4).

## Blocked by

- #57 — Requires HTTP transport support (currently stdio only)

## Server card contents

- Server name, version, description
- Available tools with descriptions
- Supported capabilities (MCP Bridge, etc.)
- Authentication requirements (if any)
- P

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/98) · 2026-04-03 · open · 0 comments

### feat: MCP spec quick wins — SDK upgrade, outputSchema, Registry, Server Card

## Summary

Bundle of low-effort, high-value improvements to align with the latest MCP ecosystem (Nov 2025 spec, Registry GA).

## Items

- [ ] **Upgrade MCP TypeScript SDK to ^1.27.x** — currently on ^1.24.0. Unlocks Tasks improvements, structured tool outputs, latest auth primitives, and extensions framework support.
- [ ] **outputSchema for voting/consensus tools** — #53
- [ ] **Publish to MCP Registry** — namespace `io.github.nesquikm/rubber-duck` is ready. Use `mcp-publisher` CLI to list in

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/97) · 2026-04-03 · closed · 1 comment

### feat: support image URLs in multimodal input

## Summary

Currently, image input for tools like `ask_duck`, `compare_ducks`, `duck_council`, and `chat_with_duck` only accepts base64-encoded data (`ImageInput.data` + `ImageInput.mimeType`). This requires callers to handle encoding themselves, which is awkward — especially from CLI tools like Claude Code where inline images can't easily be converted to base64.

## Proposal

Add `url` support to `ImageInput`, so callers can pass an image URL instead of base64:

```typescript
export interface I

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/87) · 2026-03-17 · closed · 1 comment

### feat: multimodal audio support (input + MCP Bridge)

## Summary

Add audio support across the full pipeline — both user-initiated audio input to ducks and audio content flowing back from MCP Bridge tool results.

## Context

The MCP protocol supports `AudioContent` (`{ type: "audio", data: base64, mimeType }`) as a first-class content type. Major providers now support audio input:

- **OpenAI**: GPT-4o-audio-preview and newer models accept audio via a separate `audio` parameter (not inline content parts like vision)
- **Gemini**: Supports inline a

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/79) · 2026-03-06 · open · 0 comments

### feat: multimodal MCP Bridge — pass image tool results to LLM conversations

## Summary

When ducks use MCP Bridge to call external MCP server tools, those tools can return `ImageContent` (`{ type: "image", data: base64, mimeType }`) in their results. Currently, `EnhancedDuckProvider.handleToolCalls()` (line 268) stringifies ALL tool results to JSON text via `JSON.stringify(result.data)`, so vision-capable models never actually "see" the images.

## Real-world MCP servers that return ImageContent

This is not theoretical — many popular MCP servers return `type: "image"` 

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/78) · 2026-03-06 · open · 1 comment

### feat: Multimodal support - Vision input and image/audio responses

## Summary

Add multimodal capabilities to ducks — allow sending images/audio to providers (vision input) and returning image/audio content in tool responses.

## Motivation

MCP already supports multimodal content types (`ImageContent`, `AudioContent` since protocol 2025-06-18), and most OpenAI-compatible providers support vision input. This is a natural extension that would enable ducks to analyze screenshots, diagrams, UI mockups, and other visual content.

## MCP Spec Support

The MCP protoc

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/76) · 2026-03-06 · closed · 1 comment

### Add multi-round tool calling loop for MCP Bridge ducks

## Problem

`EnhancedDuckProvider.handleToolCalls()` only executes **one round** of tool calls. After executing tools and feeding results back to the LLM, it strips the `tools` parameter from the follow-up call:

```typescript
// duck-provider-enhanced.ts lines 277-283
delete followUpParams.tools;
delete followUpParams.tool_choice;
```

This means ducks can never chain tool calls — they get one shot, then must respond with text.

## Why it matters

Useful debugging workflows require multi-step t

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/69) · 2026-02-26 · closed · 1 comment

### feat: Elicitation - Human-in-the-loop for interactive duck tools

## Summary

MCP [Elicitation](https://modelcontextprotocol.io/specification/2025-06-18/client/elicitation) (spec June 2025) allows servers to ask users structured questions mid-execution. This enables interactive, iterative workflows where ducks can pause and request user input before continuing.

## Client Support

| Client | Support |
|--------|---------|
| Cursor (1.5+) | ✅ |
| VS Code / GitHub Copilot | ✅ |
| Claude Desktop | ❌ |
| Claude Code | ❌ |
| Zed | ❌ |

## Use Cases

- **Duck Hypoth

[Read the thread](https://github.com/nesquikm/mcp-rubber-duck/issues/60) · 2026-02-08 · open · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/nesquikm/mcp-rubber-duck/issues).