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 7 servers and 5 skills are listed one by one with what each does to the bill — free, already yours, monthly or a one-off licence. Nothing is charged until you confirm it there, in Stripe’s own card frame on that page rather than a redirect, and each paid member keeps its own budget cap.
The reason to buy a stack rather than five listings: each line below needs more than one member connected at the same time.
Review a REST design against security, resilience and operational rules while it is still a document.
Read the schema behind the endpoint on a read-only Postgres connection and keep the response honest about it.
Wire OAuth 2.1 with PKCE and refresh, and a Stripe checkout, from the same desk that wrote the route.
Deploy the service to Railway and read back what the platform says about it.
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.
Utilities against the Supabase project behind the API — the fastest way to check what the platform is doing before blaming your own route.
Emails, domains and templates through the Resend API: every API grows a transactional mail obligation by the second week.
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.
Read-only access to Stripe data via an API key — enough to answer what a customer is on, without the ability to charge them.
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.
Every member is a subscription or a licence bought once, so the monthly figure is a price rather than an estimate: what moves it is adding or dropping a member, not how hard the stack is worked. The one assumption is that a one-off licence is spread over a year so it can sit in the same column as a subscription.
| Part | What you are paying for | Monthly, as quoted |
|---|---|---|
| Supabase Utils | Free | — |
| Resend | Free | — |
| Postgres | Free | — |
| Gitlab | Free | — |
| Openai | Free | — |
| Railway | Free | — |
| Stripe Connect | Free | — |
| Skills | ||
| Review API Design | Free · context cost only | — |
| OAuth | $99 · $8.25/mo over 12 months | $8.25/mo |
| Stripe | Free · context cost only | — |
| UCP Checkout REST | $59 · $4.92/mo over 12 months | $4.92/mo |
| Mem0 | $24 · $2.00/mo over 12 months | $2.00/mo |
| Everything above | $0 of servers plus $15 of skills, the same in a quiet month and a busy one | $15/mo |
Subscriptions at their monthly plan price; one-off licences spread over 12 months. One-off purchases in this stack total $182 — OAuth $99, UCP Checkout REST $59, Mem0 $24 — paid once and spread here so they sit in the same column as a subscription. Everything arrives on one mcprush invoice, taken by Stripe from the card on your account, not one per publisher — mcprush.com is the merchant of record and each publisher is paid out of it.
Install only these and the bill is nothing: 7 servers and 2 skills, 28 of the 28 tools.
Left out, and what goes with it:
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.
Budget caps are set per install and enforced at the gateway, so a retry loop is refused at the cap rather than left to run through an allowance overnight.
One step per part, in the order they are useful: connect what the work reads before what it writes, and install the skills that decide how the work is done last. Each step is a command you can read before you run it.
npx mcprush@latest stack add api-deliveryNothing in this stack installs from one command today: 12 members are either paid, run from its own source, or a skill with its own command — the steps above name each one. Nothing is connected until you approve it.
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 |
|---|---|---|
| Supabase Utils | imported | 4 |
| Gitlab | not imported | not recorded |
| Openai | not imported | not recorded |
| Postgres | not imported | not recorded |
| Railway | not imported | not recorded |
| Resend | not imported | not recorded |
| Stripe Connect | 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 6 members of 7 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.
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.
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.
The Stripe member here is read-only access to Stripe data — the desk can read customers and charges, and cannot move money.
It does not write your client SDKs. The glossary keeps the terminology consistent; generating and publishing packages is outside this stack.
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.
Writes the migration, proves it on a branch, and says what it will do to the table before it touches the real one.
Reviews the code, the identities and the exposure of one service, and writes down what it found rather than a score.
Gets the data out, trains or fine-tunes the model, and evaluates it before anybody calls it an improvement.