Rubber Duck Playground: a hands-on lab for RubberDuck MCP use cases

What the playground is for, and who it is aimed at

Rubber Duck Playground is training material for RubberDuck MCP, not an application you deploy. The README describes it as hands-on training: you launch a real demo app, copy prompts labeled UC-01 through UC-10, and run them in Cursor or Claude with the RubberDuck MCP server connected. The audience is narrow and specific. It is for someone who has already decided to try RubberDuck and now wants to know whether its answers on a real codebase are worth acting on. The repository gives you a pizzeria restaurant admin UI plus a kitchen API, and the code contains deliberate problems. UC-02 expects a security audit to surface SQL injection, XSS, pickle and exec usage, IDOR, command injection, SSTI, and broken access control. That list is published up front, which is the point: you know the right answer before you ask, so you can judge the tool's answer instead of trusting it. The README also notes that an older demoapp, labs, and run-lab.py stack was removed so the repository has one clear path through the demo-projects hub. If you are looking for a general RubberDuck tutorial rather than a graded exercise, this is more structure than you need.

How the hub, the demo app, and MCP fit together

Three pieces, and the README is explicit about each. The demo-projects directory holds the hub dashboard, started by start-hub.bat on Windows or start-hub.sh on Linux and macOS. Inside it, demo-projects/rubberduck_pizzeria-demoapp contains the restaurant admin UI and the kitchen API, with what the README calls intentional lab sinks. The hub itself generates the project-specific prompts and the expected-outcome bullets shown under What to expect for each use case. The data flow in the 60-second start is: clone, start the hub, pick the pizzeria, launch it, and watch a live console plus a health diagram that walks through venv, dependencies, database, API, and UI in that order. Only then do you connect the RubberDuck MCP server through the Connect MCP tab and paste a copied prompt. The dependency story is split deliberately. The top-level requirements.txt installs Flask for the hub control plane only, and a comment there says the pizzeria demo dependencies are installed into its own package/.venv by setup_and_run.py. pyproject.toml confirms the hub is a small Flask project, version 0.3.0, requiring Python 3.10 or newer, with flask>=3.0 as its only declared dependency. The pizzeria app therefore has its own Python environment that the hub creates for you, which is why the health diagram tracks venv as a separate step rather than assuming your shell is already prepared.

Installing it and running your first use case

The README gives a 60-second start, and it begins with a clone. The second command changes into demo-projects, which matters because the launcher and the demo app both live under that directory.

git clone https://github.com/RubberDuck-com/rubberduck-use-case-playground.git
cd rubberduck-use-case-playground/demo-projects

Next, start the hub. On Linux or macOS the README uses the shell script; on Windows it names start-hub.bat. The hub listens on http://127.0.0.1:5055/ according to the README, so that is the address to open.

./start-hub.sh

In the browser, pick Rubber Duck Pizzeria from the welcome screen and launch it. You should see the live console and the health diagram, which the README says walks through venv, dependencies, DB, API, and UI. If a stage does not turn healthy, the console is where the reason appears. With the app running, open the Connect MCP tab and connect RubberDuck MCP. SETUP.md covers connecting Codebase Intelligence and Semantic Intelligence in Cursor. Then go to Generate prompts, choose one of UC-01 through UC-10, read What to expect, and use Copy prompt. The README says to index the pizzeria demo once per session before pasting the prompt. A sensible first run is UC-01, Understand Your Code, because the README says the expected Atlas output is main.py leading to create_app, the routes, /api, and init_db. If the tool reports a different entry structure, you have learned something about the index before you have spent time on the harder use cases. There is also a Dockerfile for the hub. It is based on python:3.12-slim, copies requirements.txt, installs it, copies the repository, sets HUB_HOST to 0.0.0.0 and HUB_PORT to 8000, exposes 8000, and runs demo-projects/launcher.py. The comment in that file says it exists for the RubberDuck runtime-mcp pentest pipeline, which prefers a Dockerfile over buildpack autodetect. Note that the container port is 8000 while the script-based start uses 5055.

The ten use cases are a checklist, not a tour

The use cases are ordered by ambition, and that ordering is the most useful thing in the repository. UC-01 is comprehension: Atlas should map main.py to create_app, the routes, /api, and init_db. UC-02 is the security audit with the known sink list. UC-03 narrows to a specific defect the README calls the discount / get_aggregation mask bug. UC-04 asks for a hostile review of order_by near raw SQL in search. UC-05 asks for the blast radius of renaming config_values. UC-06 and UC-07 move from analysis to planning and generation: plan a parameterized safe_search_customers, then implement safe search with tests. UC-08 is a logic question, whether include_discount=True actually applies. UC-09 compares the raw SQL search against the parameterized search. UC-10 is a short check on what get_aggregation returns, with evidence. Read as a sequence, UC-01 and UC-10 are cheap sanity checks, UC-02 through UC-05 test whether the tool can be trusted on a codebase it has indexed, and UC-06 through UC-09 test whether it can produce changes you would keep. That is a reasonable progression, and it is more honest than a feature list. The weakness is that the expected outcomes are written by the same people who wrote the demo app, so the lab measures agreement with a script rather than agreement with reality. UC-09 in particular compares two versions of search that the repository authors chose; a tool that prefers one style for defensible reasons would be marked down.

Where this playground stops being useful

The first limitation is scope. The README states the older demoapp, labs, and run-lab.py stack was removed, leaving a single path. That is cleaner, but it also means there is one demo application and one language stack. Everything you learn about RubberDuck here is learned on a Flask pizzeria app. If your codebase is Go, Java, or a large monorepo with generated code, the playground tells you nothing about how the index behaves at that scale or in that language. The second limitation is that the bugs are intentional and the answers are published. A tool that has memorized nothing still gets credit for finding a pickle call that a human planted. The playground cannot tell you how the tool behaves on the ambiguous cases that make up most real review work, because the repository does not contain any. The third is maintenance cost. The repository is not archived, and the last push was on 2026-09-08, so it is current as of this writing, but there are no releases retrieved, and the version in pyproject.toml is 0.3.0 with flask>=3.0 as the only declared hub dependency. The demo app's own requirements live in its package directory and are installed into a local virtual environment, which means the environment is rebuilt per machine rather than pinned centrally. If the pizzeria app's dependencies drift, the health diagram is where you will find out. Finally, the hub is a Flask control plane that runs a local server and launches subprocesses. That is fine on a laptop and is why the Dockerfile exists, but nothing in the README describes authentication or isolation for the hub itself.

How it differs from reading your own repository with an AI assistant

The obvious alternative is to skip the playground and point RubberDuck MCP, or any assistant with repository access, at a codebase you already know. That approach has one real advantage: your codebase is the thing you care about, and any finding is immediately actionable. The playground's advantage is the opposite one. Because the pizzeria app has known defects and published expected outcomes, a wrong answer is visible as wrong. On your own repository you often cannot tell whether a reported SQL injection is real without doing the work of verifying it, which is the same work you were trying to delegate. The playground front-loads the verification. It is the difference between a driving lesson in a lot and a driving lesson on the highway. The trade-off is that a lab environment rewards tools that do well on lab problems. UC-02's sink list is a catalogue of textbook vulnerabilities; a tool tuned to find those may look stronger here than it does on a codebase where the security problems are design-level rather than line-level. If your goal is to evaluate RubberDuck for a specific migration or refactor, the playground will not simulate it. If your goal is to find out whether the tool's claims survive contact with running code, the playground is a cheaper way to find out than indexing a production repository.

Licence and what upgrading costs you

The repository is MIT licensed, and the README points to the LICENSE file. For a training repository that is about as permissive as it gets: you can copy the demo app, modify it, and use it inside a company without a licence negotiation. Two practical notes rather than legal ones. First, the repository bundles a demo application with deliberate vulnerabilities, including pickle and exec usage and command injection. MIT covers the code, not the consequences of running it. If you fork the pizzeria app into anything reachable from a network, you own that decision. Second, the RubberDuck MCP server that the playground is built around is a separate product with its own terms; the MIT licence here covers the playground, not the tool it trains you on. On upgrade cost, there is nothing to upgrade along. No releases were retrieved, the version is 0.3.0, and the README describes a removal of the previous demoapp and labs stack rather than a compatibility path. If you have notes or scripts built against run-lab.py, the README says that stack is gone. The hub dependency is a single Flask floor, so the hub itself is unlikely to break, but the pizzeria demo's environment is created by setup_and_run.py and is not pinned at the top level.

Editorial conclusion

Adopt it if you are evaluating RubberDuck MCP and want a controlled codebase where wrong answers are obvious, since the pizzeria demo contains intentional sinks and a known discount bug to check against. Do not adopt it if you need a maintained application or a library: the repository is a training harness, the README states the older demoapp/labs stack was removed, and there is no release history to upgrade along. Before relying on it, clone the repository, run start-hub.sh, open http://127.0.0.1:5055/, and confirm the UC-03 discount bug is what a fresh index of the pizzeria app actually reports.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. RubberDuck-com/rubberduck-use-case-playground on GitHub