Tools to investigate a bug report and work toward a reproducible test case.
Built for: Whoever picks up the report that says it happens sometimes, and has to decide within an hour whether it is real.
The button opens the checkout, where the 5 servers and 5 skills are listed one by one. Every member is free, so the checkout lists them and asks for no card.
The reason to buy a stack rather than five listings: each line below needs more than one member connected at the same time.
Pull the error, its stack trace and its frequency out of Sentry, and say how many people it reached.
Replay the path in a real browser with Puppeteer and stop when the page does not fail the way the report says it does.
Read the rows behind the report against a read-only Postgres connection with row caps and a statement timeout.
Write the reproduction down as a markdown note with a diagram, so the next person starts where this one stopped.
What each part contributes, and why it was picked over the obvious alternative. Prices and permissions are read from the listings, so nothing here can disagree with the catalogue.
The report as the system recorded it: the event, the release and how often it happened, which is what decides whether this is worth an hour.
A local log server the app posts structured events to, with a live tail — the missing half when the stack trace stops at the boundary.
Read-only Postgres with row caps and statement timeouts, so checking the data behind a bug cannot become an incident of its own.
Drives a real browser through the reported path, which is the only way to tell a broken page from a misremembered one.
Views and edits the files the reproduction lives in — the failing script, the fixture, the note — without giving the agent a shell.
Holds the desk to root cause: reproduce, isolate, then explain — rather than the first plausible change that makes the symptom go away.
Screenshots, console and performance traces through Puppeteer scripts, so 'it is slow' turns into a number from the profile.
Researches the codebase and the schema before writing the end-to-end case, which is how a reproduction ends up in the suite instead of in a comment.
Writes the reproduction up with the sequence diagram attached, so the handover is a document rather than a paragraph of chat.
Finds the incident learning or workaround that explains the odd code, which is often the bug's actual origin.
Every member is free, so the monthly figure is $0 whatever you do with the stack: nothing here is billed by the call, and only adding a paid member could change it.
| Part | What you are paying for | Monthly, as quoted |
|---|---|---|
| Sentry | Free | — |
| Logsafe | Free | — |
| Database Postgres | Free | — |
| Puppeteer | Free | — |
| Filesystem | Free | — |
| Skills | ||
| Debugging and Error Recovery | Free · context cost only | — |
| Chrome DevTools | Free · context cost only | — |
| E2E Test | Free · context cost only | — |
| Markdown and Mermaid Writing | Free · context cost only | — |
| Keep the Why | Free · context cost only | — |
| Everything above | $0 of servers plus $0 of skills, the same in a quiet month and a busy one | $0/mo |
Subscriptions at their monthly plan price; one-off licences spread over 12 months.
Install only these and the bill is nothing: 5 servers and 5 skills, and all 8 tools.
Nothing in this stack carries a call allowance, so nothing here can run out before the month does. The bill is decided when you install it, not when you use it.
The spend cap is one figure for the whole account, set in your dashboard and checked when an order is placed. On the call path what stops a retry loop is the plan's call allowance and its rate limit, and a refused call is never billed.
The steps below come before the install lines: what to decide and scope before connecting anything, in the order it matters. The lines themselves follow, part by part, for the client you pick.
npx mcprush@latest stack add bug-repro writes all 5 servers into Claude Code’s config in one go — or run the lines below one by one. The 5 skills are not included — add them with lines 06–10.
SENTRY_ACCESS_TOKEN — Your Sentry user authentication tokenPOSTGRES_HOST — Database hostPOSTGRES_USER — Database user (a read-only user is recommended)POSTGRES_PASSWORD — Database password (or use POSTGRES_PASSWORD_FILE)POSTGRES_DATABASE — Database nameSet them where you start Claude Code — export SENTRY_ACCESS_TOKEN=… in your shell profile on macOS and Linux, setx SENTRY_ACCESS_TOKEN "…" on Windows, then open a new terminal. Claude Code reads them at start; the config keeps only the names.
# 01 · Sentry
claude mcp add --scope user --env 'SENTRY_ACCESS_TOKEN=${SENTRY_ACCESS_TOKEN}' --transport stdio getsentry-sentry-mcp '--' npx -y @sentry/mcp-server
# 02 · Logsafe
claude mcp add --scope user logsafe-mcp '--' npx -y @coglet/logsafe mcp
# 03 · Database Postgres
claude mcp add --scope user --env 'POSTGRES_HOST=${POSTGRES_HOST}' --env 'POSTGRES_USER=${POSTGRES_USER}' --env 'POSTGRES_PASSWORD=${POSTGRES_PASSWORD}' --env 'POSTGRES_DATABASE=${POSTGRES_DATABASE}' --transport stdio database-postgres-mcp '--' npx -y @database-mcp/postgres
# 04 · Puppeteer
claude mcp add --scope user puppeteer-mcp '--' npx -y puppeteer-mcp-server
# 05 · Filesystem
claude mcp add --scope user filesystem-mcp '--' npx -y filesystem-mcp
# 06 · Debugging and Error Recovery
npx mcprush@latest skill add addyosmani/debugging-and-error-recovery
# 07 · Chrome DevTools
npx mcprush@latest skill add mrgoonie/chrome-devtools
# 08 · E2E Test
npx mcprush@latest skill add coleam00/e2e-test
# 09 · Markdown and Mermaid Writing
npx mcprush@latest skill add k-dense-ai/markdown-and-mermaid-writing
# 10 · Keep the Why
npx mcprush@latest skill add oliver-zehentleitner/keep-the-whynpx).Set-ExecutionPolicy -Scope CurrentUser RemoteSigned once, or type npx.cmd instead of npx (codex.cmd, gemini.cmd, grok.cmd likewise). PowerShell 7 needs neither.Nothing is connected until you approve it in Claude Code. mcprush is not in the path and meters nothing here.
Installed together, these tool surfaces add up. It is the first thing a security reviewer asks for, so what has been counted — and what nobody has counted yet — is on the page rather than in a PDF.
| Member | Tool surface | Write tools |
|---|---|---|
| Filesystem | imported | 3 |
| Database Postgres | not imported | not recorded |
| Puppeteer | not imported | not recorded |
| Sentry | not imported | not recorded |
A stack's blast radius is the union of its members, not the worst of them. That union cannot be taken here, because 3 members of 5 have no imported tool surface — so the figure a review asks for is missing rather than low, and a member marked not imported is one nobody has counted rather than one that cannot write.
1 skill in this stack instructs the agent to write — Markdown and Mermaid Writing. A skill holds no permission of its own; it can only ask a server that already has the scope, and the approval gate still applies.
A stack is a default, not a verdict. These are the substitutions the maintainer would make, and what each one costs or saves.
Where the flow needs an agent that decides its own next click instead of a script that repeats yours, take the browser-use server and give up the step-by-step replay.
The same read-only guardrails, row caps and statement timeouts against MySQL, for the half of the estate that never moved to Postgres.
Written by the maintainer, kept on the page rather than in a support thread.
It cannot fix the bug in your repository. Nothing here has write access to code — the desk hands over a reproduction, not a patch.
Postgres access is read-only by design, so a data-level bug can be found here but never corrected here.
The browser member is an experimental Puppeteer server. A flow behind a login wall or a CAPTCHA is where it stops, and the desk should say so rather than keep clicking.
A stack has an owner: whoever keeps it re-checks the combination when a member changes, and the members themselves are published by the people named on each row.
Tools to inspect code changes, run checks and prepare a pull request review.
Tools to investigate alerts, check recent changes and follow the runbook.
Tools to prepare database changes and review their effects before rollout.