The repository side of the desk — projects, branches and merge requests over the GitLab API, which is where a review has to land to be read.
Code review
Tools to inspect code changes, run checks and prepare a pull request review.
Built for: The engineer who keeps four tabs open to finish one ticket: the repository, the error tracker, the build log and the board.
The button opens the checkout, where the 5 servers and 6 skills are listed one by one. Every member is free, so the checkout lists them and asks for no card.
What your agent can do with this
The reason to buy a stack rather than five listings: each line below needs more than one member connected at the same time.
- 01
Read a merge request and its diff on GitLab and leave the review as comments, rather than as a chat message somebody has to copy across.
- 02
Run the changed code in an E2B sandbox instead of on your laptop, and throw the box away with the session.
- 03
Match a new error in Sentry to the release that introduced it, so the review names the commit instead of guessing.
- 04
Open the branch preview on Netlify and move the Shortcut story when the branch merges.
The assembly, part by part
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.
Errors, issues and releases, so the review can say which release started the crash rather than inferring it from the diff.
E2B's own server runs the branch in an isolated cloud sandbox, which is what keeps generated code off the machine you are reading it on.
Creates and reads the branch deploy through Netlify's API and CLI — the thing a reviewer opens before approving a front-end change.
The story the branch belongs to, from Shortcut's official server, so the board and the merge request stop drifting apart.
Fixes the order of a review — behaviour, then tests, then style — which is the difference between a review and a rewrite request.
Requires the failing test before the fix, so a closed bug is a proven one rather than an unreproduced one.
Turns a failed dependency audit into a specific upgrade, so the red check is a task instead of a wall of advisories.
Reads the failed GitHub Actions job for the branch and names the cause, instead of rerunning the job to see if it passes this time.
Writes the description and the diagram that go on the merge request, in the markdown the repository already uses.
Recovers the reasoning behind the code being changed — the rejected alternative, the workaround — so a review does not quietly undo a deliberate decision.
What it costs, and on what assumption
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 |
|---|---|---|
| GitLab | Free | — |
| Sentry | Free | — |
| E2B (official) | Free | — |
| Netlify | Free | — |
| Shortcut (official) | Free | — |
| Skills | ||
| Code Review and Quality | Free · context cost only | — |
| Test-Driven Development | Free · context cost only | — |
| Audit Dependencies | Free · context cost only | — |
| Fix CI Failures | 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 6 skills, and all 2 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.
Setting it up, in order
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 pr-desk writes all 5 servers into Claude Code’s config in one go — or run the lines below one by one. The 6 skills are not included — add them with lines 06–11.
- GitLab
GITLAB_PERSONAL_ACCESS_TOKEN— GitLab personal access token for local stdio use- Sentry
SENTRY_ACCESS_TOKEN— Your Sentry user authentication token- E2B (official)
E2B_API_KEY— Your E2B API key (e2b.dev/dashboard)- Shortcut (official)
SHORTCUT_API_TOKEN— Your Shortcut API token
Set them where you start Claude Code — export GITLAB_PERSONAL_ACCESS_TOKEN=… in your shell profile on macOS and Linux, setx GITLAB_PERSONAL_ACCESS_TOKEN "…" on Windows, then open a new terminal. Claude Code reads them at start; the config keeps only the names.
# 01 · GitLab
claude mcp add --scope user --env 'GITLAB_PERSONAL_ACCESS_TOKEN=${GITLAB_PERSONAL_ACCESS_TOKEN}' --transport stdio zereight-gitlab-mcp '--' npx -y @zereight/mcp-gitlab
# 02 · Sentry
claude mcp add --scope user --env 'SENTRY_ACCESS_TOKEN=${SENTRY_ACCESS_TOKEN}' --transport stdio getsentry-sentry-mcp '--' npx -y @sentry/mcp-server
# 03 · E2B (official)
claude mcp add --scope user --env 'E2B_API_KEY=${E2B_API_KEY}' --transport stdio e2b-official-mcp '--' npx -y @e2b/mcp-server
# 04 · Netlify
claude mcp add --scope user netlify-mcp '--' npx -y @netlify/mcp
# 05 · Shortcut (official)
claude mcp add --scope user --env 'SHORTCUT_API_TOKEN=${SHORTCUT_API_TOKEN}' --transport stdio shortcut-official-mcp '--' npx -y @shortcut/mcp
# 06 · Code Review and Quality
npx mcprush@latest skill add addyosmani/code-review-and-quality
# 07 · Test-Driven Development
npx mcprush@latest skill add addyosmani/test-driven-development
# 08 · Audit Dependencies
npx mcprush@latest skill add payloadcms/audit-dependencies
# 09 · Fix CI Failures
npx mcprush@latest skill add streamlit/fix-ci-failures
# 10 · Markdown and Mermaid Writing
npx mcprush@latest skill add k-dense-ai/markdown-and-mermaid-writing
# 11 · Keep the Why
npx mcprush@latest skill add oliver-zehentleitner/keep-the-whyRequirements and Windows tips
- Node.js — the current LTS (24) is the safe choice (for
npx). - Windows PowerShell says 'running scripts is disabled on this system'? Run
Set-ExecutionPolicy -Scope CurrentUser RemoteSignedonce, or typenpx.cmdinstead ofnpx(codex.cmd,gemini.cmd,grok.cmdlikewise). PowerShell 7 needs neither.
Nothing is connected until you approve it in Claude Code. mcprush is not in the path and meters nothing here.
- 2 members want an API key, set in your own client’s config on your machine — this marketplace never holds it.
- 3 members have not declared what credential they need — check each one’s own page before you start.
- What this stack can write is not recorded — 3 members of 5 have no imported tool surface. Section 05 says what is known before you approve anything.
- 5 members are connected straight from their own package or address — nothing in them goes through mcprush.
What the whole stack can reach
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 |
|---|---|---|
| E2B (official) | imported | 1 |
| GitLab | not imported | not recorded |
| Sentry | not imported | not recorded |
| Shortcut (official) | 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.
Sensible swaps
A stack is a default, not a verdict. These are the substitutions the maintainer would make, and what each one costs or saves.
A team on Bitbucket gets the same shape — pull requests, branches, repositories — from a server that speaks its own host instead of GitLab's.
If the previews already build on Vercel, keep that one: the branch preview is the only thing this stack asks of either.
Where this stack stops
Written by the maintainer, kept on the page rather than in a support thread.
It cannot deploy to production. Netlify here builds the branch preview; the production deploy stays a human decision.
Nothing in it writes to your database. A migration inside the diff is read and reviewed, never run.
Every member is a record imported from a public registry, so the tool surface is not counted for this stack — each member's own page says what it declares.
Who keeps this current
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.
Stacks that share parts with this one
Release and infrastructure desk
Takes a green branch to a running deployment, and keeps the DNS, the cluster and the access list honest on the way.
Design-to-code desk
Reads the Figma file, builds the component, and ships the page without redrawing the design in CSS by eye.
Bug reproduction
Tools to investigate a bug report and work toward a reproducible test case.