Ducklab MCP server

Ducklab

A self-hosted harness that runs a project's full development cycle with several LLMs in fixed roles, under test gates that only you sign.

In one block: self-hosted development harness (Go engine + CLI + desktop, Linux first) · brief → requirements → spec → plan → build → review → release · verdicts are exit codes, never model opinions · local models first (llama.cpp, vLLM) beside any OpenAI-compatible or Anthropic endpoint · operable by humans or by other agents over MCP with recorded, attributed decisions · Apache-2.0 · develops itself (the run records in .ducklab/ are the receipts). Agents: start at AGENTS.md and llms.txt.

You give it a brief. It writes requirements, a spec and a plan; builds tasks with one model or several arguing; runs your project's real test gate; and stops for you before anything is committed. Every model call is logged. No model ever decides a verdict.

A real council intake, recorded live and sped up: the architect streams the draft, a different model reviews it, the budget ticks in cents — and the run stops at your gate. Total cost of what you just watched: $0.07.

It was built for local models first. Two of the seats that built most of it are a vLLM box on the LAN and a llama.cpp server on localhost, both priced at zero; hosted models sit beside them in the same roster, measured by the same evidence.

Why this exists

Most agentic coding tools assume one strong model and trust it. Ducklab assumes several cheap models and trusts none of them:

A test-first run measures a green baseline before any test is written, the red over the new test after, and every accept reproduces the gate from a clean checkout of the committed sha — nothing lands that did not reproduce, and an accept whose reproduction fails takes its own commit back.

• The gate decides, never a model. A verdict is a command's exit code.

learns who wrote the code (absent from the payload, not hidden in the UI); tournament judges choose blind; council critics read the draft, not each other.

• Decorrelation everywhere. A different model reviews; a reviewer never

numbered checklist; it reports on each by number, the reviewer checks each against the diff, and an undelivered item summons the rubber duck — an advisor seat that wakes only on measured distress (brake refusals, failure streaks, red gates) and answers none, a note that sends the implementer straight back to work, or stop.

• Work is a contract. A task's deliverables are the implementer's

in-seat pass rate from your own runs, cost per run, coding index — and the roster board suggests seats from it, with the ranking criteria yours to reorder. Suggestions are rare and justified: pass rates rank by their Wilson lower bound, three runs minimum, locals never win on a $0 price.

• Seats are chosen on evidence. Every duckling carries a scorecard —

shell commands — every ceiling visible and liftable mid-run, on the record.

• Nothing is unbounded. Turns, tokens, cost, wallclock, tool output,

to a stage and a big seat reads it whole; a small seat gets each document digested to fit, the full text one ref_read call away, and the gate names any document nobody opened. A 32k local model can be briefed by a quarter-million characters of reference material — the harness carries the working memory.

• Your documentation is not bounded by the model's window. Attach a wiki

Shortened. The full README is on GitHub.