Provides read-only revenue analytics for a Stripe account, including current MRR/ARR by currency, subscription and customer churn, failed payment listings, and a combined revenue summary covering collected cash, failed payments, and churn.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-stripe-revenue-server show me my current MRR and ARR by currency"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server that answers revenue questions about a Stripe account: current MRR, churn, failed payments and a one-call summary. It is read-only, speaks MCP over stdio, and ships with a deterministic demo dataset so you can try every tool without a Stripe key.
Four tools: get_mrr, get_churn, list_failed_payments, revenue_summary.
Correct MRR: monthly, quarterly, yearly, weekly and daily prices are normalized; quantities and active percent_off / amount_off discounts are applied; canceled and incomplete subscriptions are ignored.
Never mixes currencies: every figure is grouped per currency.
Read-only by construction: the Stripe client is only ever used for list and retrieve calls.
Testable: all data access sits behind a RevenueSource interface; the calculations are pure functions.
Requires Node.js 20 or newer to run the server (engines in package.json). Running the tests and building from source needs Node.js 22.12 or newer, because the test runner does; it was developed and tested on Node 22.19.
git clone https://github.com/kienpt91/mcp-stripe-revenue-server.git
cd mcp-stripe-revenue-server
npm install
npm run build
node dist/cli.js --demo--demo serves built-in sample data with a fixed clock (2025-06-15 12:00 UTC), so the output below is identical on every run. The server waits for an MCP client on stdin/stdout; point a client at it as shown next.
Related MCP server: indie-metrics-mcp
Any MCP client that can launch a stdio server accepts a configuration of this shape. Use the absolute path to dist/cli.js:
{
"mcpServers": {
"stripe-revenue": {
"command": "node",
"args": ["/absolute/path/to/mcp-stripe-revenue-server/dist/cli.js"],
"env": {
"STRIPE_API_KEY": "rk_live_your_restricted_key"
}
}
}
}To try it with sample data instead, drop the env block and add the flag:
{
"mcpServers": {
"stripe-revenue-demo": {
"command": "node",
"args": ["/absolute/path/to/mcp-stripe-revenue-server/dist/cli.js", "--demo"]
}
}
}Without --demo the process exits with an error unless STRIPE_API_KEY is set. Diagnostics go to stderr; stdout is reserved for the protocol.
All tools are annotated readOnlyHint: true. Amounts are integers in the currency's minor unit (cents), each with a ...Formatted decimal string next to it. Currency codes are lowercase ISO 4217.
Tool | Arguments | Returns |
| none | MRR and ARR per currency, subscription and customer counts, and |
|
| Subscription churn, customer churn and churned MRR per currency over the window |
|
| Unpaid invoices that were attempted, newest first, with totals per currency |
|
| MRR, cash collected, failed payment totals and churn in one response |
The JSON below is the real output of node dist/cli.js --demo.
get_mrr{
"asOf": "2025-06-15T12:00:00.000Z",
"byCurrency": [
{
"currency": "eur",
"mrr": 7800,
"mrrFormatted": "78.00 EUR",
"arr": 93600,
"arrFormatted": "936.00 EUR",
"subscriptions": 2,
"customers": 2
},
{
"currency": "gbp",
"mrr": 5000,
"mrrFormatted": "50.00 GBP",
"arr": 60000,
"arrFormatted": "600.00 GBP",
"subscriptions": 1,
"customers": 1
},
{
"currency": "jpy",
"mrr": 30000,
"mrrFormatted": "30000 JPY",
"arr": 360000,
"arrFormatted": "360000 JPY",
"subscriptions": 1,
"customers": 1
},
{
"currency": "usd",
"mrr": 67133,
"mrrFormatted": "671.33 USD",
"arr": 805600,
"arrFormatted": "8056.00 USD",
"subscriptions": 11,
"customers": 10
}
],
"skippedItems": 1
}The usd figure is 11 subscriptions, including a yearly plan (1200.00/year counts as 100.00/month), a weekly plan, a 5-seat plan with 20% off until October, a plan with 10.00 off every invoice, one past-due subscription, and one subscription with a flat item plus a metered item (the metered item is counted in skippedItems).
get_churn{
"period": {
"from": "2025-05-16T12:00:00.000Z",
"to": "2025-06-15T12:00:00.000Z"
},
"subscriptions": {
"activeAtStart": 16,
"canceled": 3,
"churnRate": 0.1875,
"newInPeriod": 3
},
"customers": {
"activeAtStart": 15,
"churned": 2,
"churnRate": 0.1333
},
"revenueByCurrency": [
{
"currency": "eur",
"mrrAtStart": 11700,
"mrrAtStartFormatted": "117.00 EUR",
"mrrChurned": 3900,
"mrrChurnedFormatted": "39.00 EUR",
"churnRate": 0.3333
},
{
"currency": "gbp",
"mrrAtStart": 5000,
"mrrAtStartFormatted": "50.00 GBP",
"mrrChurned": 0,
"mrrChurnedFormatted": "0.00 GBP",
"churnRate": 0
},
{
"currency": "jpy",
"mrrAtStart": 30000,
"mrrAtStartFormatted": "30000 JPY",
"mrrChurned": 0,
"mrrChurnedFormatted": "0 JPY",
"churnRate": 0
},
{
"currency": "usd",
"mrrAtStart": 62133,
"mrrAtStartFormatted": "621.33 USD",
"mrrChurned": 6800,
"mrrChurnedFormatted": "68.00 USD",
"churnRate": 0.1094
}
]
}list_failed_paymentsCalled with { "limit": 2 }. totalCount and byCurrency cover every match; limit only truncates invoices.
{
"period": {
"from": "2025-05-16T12:00:00.000Z",
"to": "2025-06-15T12:00:00.000Z"
},
"totalCount": 4,
"customers": 4,
"byCurrency": [
{
"currency": "eur",
"count": 1,
"amountDue": 3900,
"amountDueFormatted": "39.00 EUR"
},
{
"currency": "usd",
"count": 3,
"amountDue": 10800,
"amountDueFormatted": "108.00 USD"
}
],
"invoices": [
{
"id": "in_demo_failed_2",
"customerId": "cus_demo_05",
"customerEmail": "ops@fabrikam.example",
"amountDue": 3900,
"amountDueFormatted": "39.00 EUR",
"currency": "eur",
"attemptCount": 1,
"status": "open",
"created": "2025-06-14T09:00:00.000Z",
"nextPaymentAttempt": "2025-06-16T09:00:00.000Z"
},
{
"id": "in_demo_failed_1",
"customerId": "cus_demo_10",
"customerEmail": "billing@northwind.example",
"amountDue": 4900,
"amountDueFormatted": "49.00 USD",
"currency": "usd",
"attemptCount": 2,
"status": "open",
"created": "2025-06-10T09:00:00.000Z",
"nextPaymentAttempt": "2025-06-17T09:00:00.000Z"
}
]
}revenue_summary{
"period": {
"from": "2025-05-16T12:00:00.000Z",
"to": "2025-06-15T12:00:00.000Z"
},
"mrr": {
"asOf": "2025-06-15T12:00:00.000Z",
"byCurrency": [
{
"currency": "eur",
"mrr": 7800,
"mrrFormatted": "78.00 EUR",
"arr": 93600,
"arrFormatted": "936.00 EUR",
"subscriptions": 2,
"customers": 2
},
{
"currency": "gbp",
"mrr": 5000,
"mrrFormatted": "50.00 GBP",
"arr": 60000,
"arrFormatted": "600.00 GBP",
"subscriptions": 1,
"customers": 1
},
{
"currency": "jpy",
"mrr": 30000,
"mrrFormatted": "30000 JPY",
"arr": 360000,
"arrFormatted": "360000 JPY",
"subscriptions": 1,
"customers": 1
},
{
"currency": "usd",
"mrr": 67133,
"mrrFormatted": "671.33 USD",
"arr": 805600,
"arrFormatted": "8056.00 USD",
"subscriptions": 11,
"customers": 10
}
],
"skippedItems": 1
},
"collected": [
{
"currency": "eur",
"collected": 3900,
"collectedFormatted": "39.00 EUR",
"invoices": 1,
"customers": 1
},
{
"currency": "gbp",
"collected": 15000,
"collectedFormatted": "150.00 GBP",
"invoices": 1,
"customers": 1
},
{
"currency": "jpy",
"collected": 30000,
"collectedFormatted": "30000 JPY",
"invoices": 1,
"customers": 1
},
{
"currency": "usd",
"collected": 45000,
"collectedFormatted": "450.00 USD",
"invoices": 9,
"customers": 8
}
],
"failedPayments": {
"totalCount": 4,
"customers": 4,
"byCurrency": [
{
"currency": "eur",
"count": 1,
"amountDue": 3900,
"amountDueFormatted": "39.00 EUR"
},
{
"currency": "usd",
"count": 3,
"amountDue": 10800,
"amountDueFormatted": "108.00 USD"
}
]
},
"churn": {
"subscriptions": {
"activeAtStart": 16,
"canceled": 3,
"churnRate": 0.1875,
"newInPeriod": 3
},
"customers": {
"activeAtStart": 15,
"churned": 2,
"churnRate": 0.1333
}
}
}MRR
Subscriptions in status active or past_due count. trialing, unpaid, paused, incomplete, incomplete_expired and canceled do not.
Each item contributes unit_amount x quantity, converted to a month: year / 12, week x 52/12, day x 365/12, and interval_count divides further (a quarterly price is month with interval_count 3).
Discounts attached to the subscription apply in order when active at the time of the call: percent_off scales the running total, amount_off is taken off each invoice and converted to a monthly amount using the billing interval. forever discounts always apply; repeating discounts apply between their start and end; once discounts never recur, so they are ignored. An amount_off in a different currency than the subscription is ignored. The result never goes below zero.
Totals are summed per currency and rounded once at the end. ARR is 12 x MRR.
Prices that have no fixed amount (tiered, volume-transformed or metered) cannot be turned into MRR; they are left out and counted in skippedItems.
Prices are taken as stored on the price object, so tax is not included. Item-level and customer-level discounts are not applied.
Churn over [now - days, now)
The cohort is every subscription that existed when the window began (never-started incomplete and incomplete_expired excluded). A cohort subscription is churned if it ended inside the window. churnRate is null when the cohort is empty instead of dividing by zero.
A customer churns only if they had a subscription at the start and have none at the end, so moving between plans is not churn.
mrrChurned values churned subscriptions at the start of the window, including discounts active then.
Failed payments: invoices in status open or uncollectible with at least one payment attempt, created inside the window. amountDue is the remaining balance.
Collected revenue (in revenue_summary): amount_paid of invoices paid inside the window. For Stripe data, invoices created up to 60 days before the window are considered so that late-paid invoices are not missed. Refunds are not subtracted.
In the Stripe Dashboard, create a restricted key with read-only access to Subscriptions, Invoices and Coupons. Nothing else is needed.
Put it in STRIPE_API_KEY in your MCP client configuration (see above), or export it and run node dist/cli.js.
Subscriptions and invoices are fetched with automatic pagination (100 per page). The server makes list and retrieve calls only. The Stripe-backed source is covered by tests against a fake client with the same list / retrieve surface; try it against a test-mode key first.
Settings, all optional environment variables:
Variable | Default | Effect |
|
| Stripe lists (subscriptions, failed and paid invoices) are cached in memory for this long, so a burst of tool calls costs one scan. Results can be that stale. |
|
| A single list read stops with a clear error once it has seen more than this many objects, instead of scanning an unbounded account. |
|
|
|
Use a restricted, read-only key (rk_...). The server never writes, but a full secret key (sk_...) would let anything with access to the process do far more; the server prints a warning to stderr when it is given one.
The key is read from the environment only. It is not logged, and anything that looks like a Stripe key is redacted from error messages returned to the client.
Tool results contain customer ids and billing emails. Set REDACT_EMAILS=true to mask the emails, and only connect clients you trust with the rest.
Dependencies are pinned to exact versions that were published at least 30 days before the pin date, and npm run check:deps-age verifies that for the whole lockfile. Advisories whose fixes are newer than that are tracked in SECURITY.md.
Path | Purpose |
| Pure calculations: interval normalization, discounts, MRR, churn, failed payments, summary |
| Domain model and the |
|
|
| In-memory source and the deterministic demo dataset |
| TTL cache decorator for any |
| MCP tool registration, JSON presentation, email masking and key redaction |
| Argument and environment handling, and the stdio entry point |
To plug in another data source, implement RevenueSource (three async methods) and pass it to createRevenueServer({ source }).
npm install
npm run typecheck
npm testThe tests need no network or API keys. They cover:
the calculations (interval normalization, discount windows and edge cases, per-currency grouping, zero-division in churn);
the Stripe mapping, using a fake client;
the MCP layer through the SDK client over a linked in-memory transport, and against a real --demo child process over stdio;
the cache (TTL expiry, shared in-flight requests, no cached failures) and the max-items guard;
this README: every JSON example above is compared with the live tool output.
npm run demo runs the CLI in demo mode straight from the TypeScript sources.
MIT
Churn over the last N days: subscriptions and customers that existed at the start of the window and had ended by its close, as a rate (null when nothing existed at the start), plus churned MRR per currency.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Length of the look-back window in days, ending now (1-365, default 30). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds genuinely useful behavioral detail (cohort definition, window boundary, null-rate case, currency segmentation), but omits the scale of the rate: e.g., whether it is a fraction or a percentage, which matters because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single, front-loaded sentence with no filler: the metric, the cohort, the window, the edge case, and the currency breakdown all earn their place. The dense parentheticals make it slightly harder to parse than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read tool with no output schema, and the description covers the cohort definition, the edge case, and the return segmentation. The only real gap is the rate's units/scale, which an agent would need in order to present the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the days parameter is fully documented (1-365, default 30). The description repeats 'last N days' and clarifies that the window ends at the close, which adds some cohort semantics but no new syntax or constraint information. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific metric (churn) computed over a defined cohort and window, plus what is returned: subscription and customer churn rates and churned MRR per currency. This is clearly distinct from the sibling tools get_mrr, revenue_summary, and list_failed_payments, which address different analytical questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the metric itself, but the description never says when to reach for this rather than get_mrr or revenue_summary, nor does it give any exclusions or prerequisites. The agent must infer the routing decision from the tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current MRR and ARR per currency. Counts active and past_due subscriptions, normalizes yearly/weekly/daily/multi-month prices and quantities to a monthly amount, and applies percent_off / amount_off discounts that are active right now. Amounts are in minor units (cents); currencies are never combined.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description's job is computational semantics — and it delivers: which subscription states count (active and past_due), how yearly/weekly/daily/multi-month prices and quantities are normalized, and that only currently-active discounts apply. This is meaningful disclosure beyond the safety profile, though edge cases like trials, paused, or canceled subscriptions go unmentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the return shape and followed by the calculation rules. Every clause carries information — normalization, discount eligibility, minor units, and the no-currency-combining constraint all matter to correct interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey the return shape, and it does: MRR and ARR broken out per currency, in minor units, never aggregated across currencies. It stops short of stating the container format (map keyed by currency, list of rows) or behavior on zero data, but the substantive semantics are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4. The description correctly signals the no-input nature by framing the result purely in terms of server-side computation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names the exact resource and scope: current MRR and ARR per currency. It is unambiguous what is being computed, but it never differentiates itself from the sibling revenue_summary, which an agent could plausibly pick for the same intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the word "Current," which suggests a point-in-time snapshot rather than a historical series. No alternative is named, and there is no explicit statement of when to prefer this over revenue_summary or get_churn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoices from the last N days that Stripe tried to collect at least once and that are still unpaid (open or uncollectible), newest first, with amount, customer and attempt count. Totals cover every match; limit only truncates the invoice list.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Length of the look-back window in days, ending now (1-365, default 30). | |
| limit | No | Maximum number of invoices to list (1-100, default 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and open-world access, so the description only needs to add operational detail — and it does: result ordering (newest first), what still counts as failed (open or uncollectible), and the important caveat that totals cover every match while `limit` only truncates the invoice list. It stops short of stating rate limits or what an empty result means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that front-loads the selection criteria and ordering, closes with the totals-vs-limit caveat, and contains no redundant restatement of the name or title. Every clause carries information an agent could act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description names the returned fields (amount, customer, attempt count) and explains the totals-versus-list relationship, which is adequate for a two-parameter read tool. Missing only minor items such as pagination behavior beyond `limit` and the shape of an empty result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with ranges and defaults already documented, so baseline would be 3. The description goes beyond that by explaining what `limit` actually truncates (only the invoice list, not the totals) and framing `days` as a look-back window ending now — semantics the schema text alone does not spell out.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (invoices that Stripe tried to collect and remain unpaid in the last N days) plus the selection criteria (open or uncollectible) and ordering (newest first). It is visibly distinct from aggregate siblings get_mrr, get_churn and revenue_summary, which return metrics rather than a list of invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope statement implicitly tells an agent this is the invoice-level detail tool rather than a revenue/churn aggregate, but there is no explicit 'use this when…' guidance or named alternative. Neither the description nor the siblings are cross-referenced, so routing relies on the agent inferring from the resource noun.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call overview for the last N days: current MRR, cash collected from paid invoices, failed payment totals and churn. Every money figure is grouped per currency.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Length of the look-back window in days, ending now (1-365, default 30). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile needs no restating. The description still adds real value beyond that: the window ends 'now', and every money figure is grouped per currency, which is an output-shaping trait no annotation or schema conveys. It stops short of mentioning data freshness lag, empty-window behavior, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The core payload is front-loaded and the currency-grouping caveat follows immediately where it is needed. Nothing repeats the title or the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns, and it does so by naming the four metric groups and the per-currency grouping. For a read-only aggregate with one optional parameter this is nearly sufficient; only edge cases (no invoices in window, zero-denominator churn) are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has 100% schema description coverage, including the 1-365 range, default of 30, and that the window ends now. The description's 'last N days' merely restates the schema rather than adding syntax or edge-case guidance, so the baseline 3 for a fully documented schema applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete deliverable (a single-call overview over the last N days) and enumerates exactly what it returns: current MRR, cash collected from paid invoices, failed payment totals and churn. The 'one-call overview' framing implicitly contrasts it with the per-metric siblings get_mrr, get_churn and list_failed_payments, but never names them, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the aggregate shortcut when several revenue metrics are needed at once. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. 'use get_mrr when you only need MRR'), and no note about cost or call-count tradeoffs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_churnget_mrrlist_failed_paymentsrevenue_summaryScored across 4 tools
Each tool has a distinct primary purpose: MRR, churn, failed payments, and an aggregate overview. The only overlap is that revenue_summary repeats metrics available from the individual tools, but its description clearly frames it as a one-call overview, making selection mostly clear.
Names are all snake_case and mostly follow a verb_noun pattern (get_mrr, get_churn, list_failed_payments). revenue_summary is a noun phrase rather than verb_noun, which is a minor deviation but still understandable and predictable.
Four tools is well-scoped for a focused Stripe revenue metrics server. Each tool covers a distinct metric area, and the aggregate summary tool adds convenience without overwhelming the surface.
The set covers core revenue analytics: MRR/ARR, churn, failed payments, and a summary with cash collected. Minor gaps exist around deeper drill-downs such as per-customer revenue or successful invoice listings, but the main metrics are fully represented.
Read-only revenue analytics from Stripe, Paddle, Polar, Lemon Squeezy, Creem and Freemius.
Read-only MCP over your own revenue and net margin across 14 billing rails
Read-only revenue, subscriptions, customers, and experiments tools for ZeroSettle accounts.
Stripe MCP Pack — read-only access to Stripe data via API key.
