Emails, domains and templates through the Resend API: every API grows a transactional mail obligation by the second week.
API delivery desk
Designs the endpoint, wires the auth and the payment, and reviews the shape before it is public and permanent.
Built for: The team shipping the first version of an API that other people will build against — and cannot quietly rename next month.
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.
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
Review a REST design against security, resilience and operational rules while it is still a document.
- 02
Read the schema behind the endpoint on a read-only Postgres connection and keep the response honest about it.
- 03
Wire OAuth 2.1 with PKCE and refresh, and a Stripe checkout, from the same desk that wrote the route.
- 04
Deploy the service to Railway and read back what the platform says about it.
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.
Read-only access to the data the endpoint returns, with row caps and statement timeouts, so design questions get real answers.
The route, the spec and the review live in the same repository; this is the desk's way in and out of it.
The OpenAI API as a plain dependency, for the endpoints that call a model and now need their own timeouts and costs.
Manages the Railway infrastructure the service runs on, so deploying is part of the same session rather than a different tool.
Reviews the design while it is still cheap to change: security, resilience, pagination, errors, versioning — the list a public API is judged on later.
Implements the authorisation-code-with-PKCE, client-credentials and refresh flows properly, which is where hand-written auth usually goes wrong.
The integration side of payments — payments, subscriptions, invoices and customers — kept to Stripe's own current patterns.
A worked checkout contract over REST, with idempotency and status transitions, for teams building the commerce half of the API.
For the endpoint that has to remember a user between calls: a memory layer added deliberately, rather than a growing prompt.
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 |
|---|---|---|
| Resend | Free | — |
| Database Postgres | Free | — |
| GitLab | Free | — |
| Openai | Free | — |
| Railway | Free | — |
| Skills | ||
| Review API Design | Free · context cost only | — |
| OAuth | Free · context cost only | — |
| Stripe | Free · context cost only | — |
| UCP Checkout REST | Free · context cost only | — |
| Mem0 | 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 1 tool.
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 api-delivery 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.
- Database Postgres
POSTGRES_HOST— Database hostPOSTGRES_USER— Database user (a read-only user is recommended)POSTGRES_PASSWORD— Database password (or use POSTGRES_PASSWORD_FILE)POSTGRES_DATABASE— Database name- GitLab
GITLAB_PERSONAL_ACCESS_TOKEN— GitLab personal access token for local stdio use- Openai
OPENAI_API_KEY— Your OpenAI API key- Railway
RAILWAY_API_TOKEN— Your Railway API token (railway.app/account/tokens)
Set them where you start Claude Code — export POSTGRES_HOST=… in your shell profile on macOS and Linux, setx POSTGRES_HOST "…" on Windows, then open a new terminal. Claude Code reads them at start; the config keeps only the names.
# 01 · Resend
claude mcp add --scope user resend-mcp '--' npx -y mcp-resend
# 02 · 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
# 03 · 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
# 04 · Openai
claude mcp add --scope user --env 'OPENAI_API_KEY=${OPENAI_API_KEY}' --transport stdio openai-mcp '--' npx -y @mzxrai/mcp-openai
# 05 · Railway
claude mcp add --scope user --env 'RAILWAY_API_TOKEN=${RAILWAY_API_TOKEN}' --transport stdio railway-mcp '--' npx -y @jasontanswe/railway-mcp
# 06 · Review API Design
npx mcprush@latest skill add psenger/review-api-design
# 07 · OAuth
npx mcprush@latest skill add mcollina/oauth
# 08 · Stripe
npx mcprush@latest skill add sundial-org/stripe
# 09 · UCP Checkout REST
npx mcprush@latest skill add orcaqubits/ucp-checkout-rest
# 10 · Mem0
npx mcprush@latest skill add mem0ai/mem0Requirements 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 — 4 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 |
|---|---|---|
| Database Postgres | not imported | not recorded |
| GitLab | not imported | not recorded |
| Railway | not imported | not recorded |
| Resend | 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 4 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 — UCP Checkout REST. 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.
For an API that ships as functions rather than as a service, the Vercel server manages the same deploy from the same desk.
Transactional mail is one interchangeable dependency; take whichever account you already have domains verified on, and the API code changes in one place.
Where this stack stops
Written by the maintainer, kept on the page rather than in a support thread.
It cannot approve its own design. The review skill produces findings; whether the API ships with them open is a person's call.
It cannot move money. The Stripe skill writes the checkout into your code; nothing in this stack reads or changes a live Stripe account.
It does not write your client SDKs. Generating and publishing packages is outside this stack.
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
Database changes
Tools to prepare database changes and review their effects before rollout.
Security and access review desk
Reviews the code, the identities and the exposure of one service, and writes down what it found rather than a score.
Data and ML desk
Gets the data out, trains or fine-tunes the model, and evaluates it before anybody calls it an improvement.