What does the new analyze_stripe_churn MCP tool do?

It pulls canceled subscriptions directly from your Stripe account using a restricted (read-only) API key, enriches each cancellation with plan, MRR, sub age, and voluntary vs. involuntary context, and feeds them into Claude for churn pattern analysis. You ask Claude 'analyze my churn from Stripe for the last 60 days' and get back ranked insights with severity, confidence, and recommendations — all without leaving your editor or pasting any data manually.

How is this different from analyze_churn?

analyze_churn takes pasted feedback text (CSV, plain text, forwarded emails). analyze_stripe_churn pulls directly from the Stripe API — zero copy-paste required. Both run locally on your machine via stdio MCP and return the same analysis output shape, so any tool that consumes one can consume the other.

Is my Stripe key safe?

Yes — and we recommend you use a restricted (read-only) Stripe key, not your live secret key. The MCP server runs locally on your machine over stdio. Your Stripe key never touches RetentionCheck's servers. We document the exact restricted-key permissions needed (Subscriptions Read, Customers Read, Prices Read) on the integrations page.

What about Stripe Connect for one-click setup?

Stripe Connect OAuth is the next step on the public roadmap. The current env-var setup is intentionally simple to ship — and works for any founder with a Stripe account in under 3 minutes. Connect will reduce friction further but requires Stripe platform approval.

Does RetentionCheck store my cancellation data?

Not when using the MCP server. The tool is stateless: it fetches from Stripe, analyzes via Claude, returns results. Nothing is persisted on RetentionCheck's side except anonymous usage telemetry (counts only, never feedback text or financial data). The full web app at retentioncheck.com does store analyses for trend tracking — that's a separate, opt-in flow.

npm install @retentioncheck/mcp-server, then add it to your Claude Desktop / Cursor / Zed MCP config with two env vars: ANTHROPIC_API_KEY and STRIPE_SECRET_KEY (use a restricted read-only key). Restart your MCP client, then ask Claude 'analyze my churn from Stripe.' Full instructions at retentioncheck.com/integrations.

I Shipped a Stripe MCP Tool Because of One Tweet

Two days ago I tweeted about RetentionCheck's MCP server. A founder named Kay replied with a simple question: "retention analysis as an mcp tool is a genuinely useful idea. what data source does it pull from? curious if it works against postgres directly or needs a middleware layer"

I drafted a reply, then stopped. The honest answer was — it doesn't pull from anywhere. It takes pasted feedback text. That was the entire integration story. And Kay's question made me realize that's the exact friction point keeping every busy founder from actually using it.

So I shipped what he was asking about. Today, four hours after that tweet, @retentioncheck/mcp-server@0.3.0 is live on npm with a new tool: analyze_stripe_churn. Pull canceled subscriptions directly from Stripe inside Claude. Zero middleware, zero backend, zero copy-paste. This post is the build-in-public story. (For the week's other launches — Churn Health Score, public roadmap, lifetime deal — see What We Shipped This Week.)

What the new tool actually does

You add a restricted Stripe key to your MCP config (read-only access to Subscriptions, Customers, and Prices), restart Claude Desktop, and then this works:

You: “Analyze my churn from Stripe for the last 60 days, focused on pricing.”
Claude: <invokes analyze_stripe_churn> → pulls canceled subs → enriches each one with plan, MRR, sub age, voluntary vs. involuntary → feeds them through Claude → returns ranked insights.

What you get back: a ranked list of churn drivers with severity (critical / high / medium / low), confidence scores, the actual cancellation reasons backing each insight, dollar impact in MRR, and a priority action. Plus a stripeContext block with the raw counts: how many cancels, how many active subs, voluntary vs. involuntary split, total MRR lost, and flags for low-sample / truncation / missing-feedback warnings.

Three things I refused to compromise on

1. Zero middleware. Period.

The MCP server is a local Node process running on your laptop over stdio. It connects directly to Stripe's API using your restricted key. Your data never touches our servers, our database, or our analytics. We collect anonymous telemetry — tool name, success/failure, item count, mode (live or test), nothing else — and you can opt out with a single env var.

This wasn't just a privacy decision. It was an architectural decision driven by Pieter Levels' philosophy: the simpler the deployment, the less can break. No backend means no auth flow to debug, no rate limits to manage, no DB schema to migrate, no Connect OAuth platform approval to wait on. The whole tool is one TypeScript file plus two pure helpers. It just works.

2. Honest empty states. No fake scores.

The most tempting thing to do when you have zero cancellations in the lookback window is return a perfect Churn Health Score of 100, grade A. After all, zero cancels = perfect retention, right? Wrong. Zero cancels in a 90-day window for an account with 4 active subs is not proof of healthy retention — it's not enough data to compute one. So the tool returns null for both score and grade in that case, with a summary that explicitly says "not enough data."

This matters because the tool's output is going to be screenshotted and shared. If it lies even once, the credibility is gone. We also low-sample-flag any analysis with fewer than 5 cancellations in the window, and prepend a tip when more than 70% of canceled subs have no cancellation reason recorded (suggesting the user enable cancellation reasons in their Stripe Billing Portal).

3. The README has to be three steps.

If a founder can't install the tool in under 3 minutes, they'll close the tab and go back to their CS dashboard. The setup is exactly: (1) generate a restricted Stripe key, (2) paste it into your MCP config alongside your existing Anthropic key, (3) restart your client. That's it. No webhook setup, no OAuth dance, no "contact us for enterprise pricing." Marc Lou rule: shipped > perfect.

The build-in-public timeline

2:00 PM — Tweet from Kay arrives. I draft a reply but realize the honest answer is too thin.
2:15 PM — Open a new conversation with Claude Code. Brainstorm the design via the superpowers brainstorming skill: data scope (we picked enriched cancellation_details with plan/MRR/age, deferring failed-invoice analysis to v2), auth model (env var, never tool argument — financial credentials should never enter LLM context), time window (90 days default, 7-365 range).
2:45 PM — Spec written and committed. 9 implementation tasks identified.
3:30 PM — Three new files written: stripe-feedback-formatter.ts (pure transformer: Stripe sub → feedback line with bracketed context), stripe-churn-fetcher.ts (paginates canceled subs, filters by canceled_at, caps at 500), analyze-stripe-churn.ts (the MCP handler with all the empty-state and error logic).
4:00 PM — 17 unit tests written, all passing. Full test suite: 119 passing, no regressions.
4:30 PM — Hit a dumb npm publish failure: 404 on PUT. Spent 15 minutes realizing it was actually an expired NPM_TOKEN, not a missing package (npm's error message is misleading — saved as a Claude Code skill so I never lose that hour again).
5:00 PM — @retentioncheck/mcp-server@0.3.0 live on npm. CI workflow updated with a date-based expiry check so the next NPM_TOKEN rotation doesn't silently break auto-publish.
5:30 PM — Reply to Kay: "Update — shipped."

What's next

The tool is intentionally scoped tight for v1. Three things on the roadmap, all already in the design spec:

Stripe Connect OAuth. Replace the env-var key with a one-click "Connect Stripe" button on retentioncheck.com. The MCP tool becomes a thin client that calls our backend with a RetentionCheck-issued API key. Removes the restricted-key setup entirely. Requires Stripe platform approval (~1 week).
Postgres adapter. Same pattern as the Stripe tool, but reads from a user-supplied connection string and SQL query. For self-hosted SaaS founders (and to answer the second half of Kay's original question).
Trend memory. Right now every MCP call is stateless. Optional opt-in to persist results server-side keyed by install ID, so the next analysis can say "this is your second analysis — here's what changed." The single most-likely-to-convert Pro upgrade hook.

Try it

Install instructions and the full restricted-key permission list are on the integrations page. The whole package is open source on GitHub. The MCP Registry listing is live so any compatible agent can discover it.

If you ship something built on top of this, or hit a bug, or want a feature — reply to me on Twitter. That's literally how this tool got built. The next one might be yours.