What can you do with this server?

This MCP server provides AI assistants with read-only access to Stripe business metrics, enabling natural language queries about revenue, customers, subscriptions, refunds, and forecasts. Key capabilities include: * Revenue Summary: MRR, ARR, total revenue, growth rate, and average transaction value for configurable periods (7d, 30d, 90d, 1y). * Customer Metrics: Total customers, new customers, average lifetime value, and top spenders. * Product Performance: Revenue by product, units sold, average price, and revenue share to identify best and worst sellers. * Subscription Health: Active subscriptions, churn rate, MRR, ARPU, new vs. canceled subscriptions, and plan breakdowns. * Recent Transactions: Charges and payments with amount, status, customer email, description, and timestamp. * Refund Analysis: Refund counts, amounts, refund rate, and reasons. * Revenue Forecast: Projected MRR/ARR based on trends, with growth direction and confidence level.

Which integrations are available for this server?

Provides tools for querying Stripe business metrics such as MRR, ARR, revenue, customer metrics, product performance, subscription health, recent transactions, refund analysis, and revenue forecasts via natural language.

How do I use indie-metrics-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@indie-metrics-mcp What's my MRR for this month?" 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.

indie-metrics-mcp

by MARCCHERGGI

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

indie-metrics-mcp

MCP server that gives an AI assistant read-only access to Stripe business metrics. Ask an MCP-compatible client about revenue, customers, subscriptions, refunds, and forecasts in natural language.

What You Can Ask

"What's my MRR this month?"
"Show me my top customers by spend"
"Which product is selling best?"
"What's my churn rate?"
"Show recent transactions"
"How many refunds did I have this quarter?"
"Forecast my revenue for next month"

Related MCP server: Metabase MCP Plus

Tools

Tool	Description
`get_revenue_summary`	MRR, ARR, total revenue, growth rate, average transaction value
`get_customer_metrics`	Total customers, new customers, LTV, top spenders
`get_product_performance`	Revenue by product, units sold, revenue share
`get_subscription_health`	Active subscriptions, churn rate, MRR, ARPU, plan breakdown
`get_recent_transactions`	Latest charges with amount, status, customer, timestamp
`get_refund_analysis`	Refund count, rate, amounts, reasons
`get_revenue_forecast`	Projected revenue, trend direction, confidence level

Install From Source

The npm package is not claimed as published. Use the tagged source release until an npm package is independently confirmed.

git clone https://github.com/MARCCHERGGI/indie-metrics-mcp.git
cd indie-metrics-mcp
npm ci
npm run build

Configure Safely

Start with a Stripe test-mode restricted key. Grant only the read permissions required by the tools you plan to use. Never commit a key, paste it into an issue, or expose it to a hosted demo.

export STRIPE_API_KEY=sk_test_your_restricted_key_here

Add to an MCP-compatible desktop client

Point the client at the locally built executable:

{
  "mcpServers": {
    "indie-metrics": {
      "command": "node",
      "args": ["/absolute/path/to/indie-metrics-mcp/dist/index.js"],
      "env": {
        "STRIPE_API_KEY": "sk_test_your_restricted_key_here"
      }
    }
  }
}

Use your client's secure environment-variable or secret-management feature when available instead of storing credentials directly in a configuration file.

Supported Periods

All time-based tools accept a period parameter: 7d, 30d, 90d, or 1y.

Security Boundaries

The server is designed for local execution.
Tool operations are read-only with respect to Stripe.
Start in Stripe test mode and use a restricted key with least privilege.
Do not connect real customer data to public demonstrations.
Forecasts are estimates, not financial advice.
Review the source and permissions before using the server with production data.

Public Reproducibility Companion

FounderMetricBench is a separate public synthetic evaluation maintained by Marco Hergi. It contains 24 gold cases for routing, calculation, retrieval, and safety, plus stable evidence fixtures and a hosted synthetic MCP endpoint. It does not use this repository's users, credentials, or real Stripe data.

This repository and the companion site are independent projects. They are not produced, sponsored, certified, or endorsed by Stripe, Anthropic, OpenAI, Google, Microsoft, or Perplexity.

Release Verification

Before publishing a release, run:

npm ci
npm run build

A release should describe known limitations and link to the exact commit or tag it represents.

License and Attribution

MIT. See LICENSE. Existing copyright and authorship notices are preserved.

Available Tools

7 tools

get_customer_metricsCustomer MetricsA

Get customer analytics including total customers, new customers in period, average lifetime value (LTV), and top customers by spend.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Time period for new customer analysis	30d
`limit`	No	Number of top customers to return

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must convey behavioral traits. It indicates a read-only operation with no side effects, which is appropriate for a GET style tool. However, it could add detail about potential staleness of data or that results are aggregates, but overall it is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence clearly enumerates the output metrics and purpose with zero redundancy. Every part contributes to understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the key returned data points and the two parameters adequately. While an output schema is absent, the listed metrics provide sufficient context for a simple analytics tool. Minor omission: no mention of data aggregation level or temporal scope beyond the period parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, baseline is 3. The description adds value by explicitly linking 'period' to 'new customer analysis' and 'limit' to 'top customers', confirming their roles beyond the schema's minimal descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns customer analytics including specific metrics like total customers, new customers, LTV, and top spenders, which distinctly separates it from sibling tools focusing on transactions, refunds, revenue, or subscriptions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for customer metric queries but provides no explicit guidance on when to use this tool versus alternatives like get_revenue_summary or get_subscription_health, nor does it mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_product_performanceProduct PerformanceB

Analyze revenue by product — shows each product's revenue, units sold, average price, and share of total revenue. Identifies your best and worst sellers.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Time period to analyze	30d

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should explicitly state behavioral traits like safety (read-only), data freshness, or aggregation scope. It only describes output but not side effects, permissions, or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the core function and list specific outputs. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with minimal parameters and no output schema, the description covers the return values adequately. However, it lacks completeness on data scope (e.g., all products? historical comparison?) which would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'period' is fully described in the schema (enum, default, description). The tool description adds no additional meaning beyond the schema, so baseline score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool uses 'Analyze revenue by product' and specifies the metrics (revenue, units sold, average price, share) and outputs (best/worst sellers). It is distinct from siblings which focus on customers, transactions, refunds, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus siblings like get_revenue_summary or get_recent_transactions. The context is implied but not directed; a user must infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_recent_transactionsRecent TransactionsA

List recent charges and payments with amount, status, customer email, description, and timestamp. Great for checking latest sales activity.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of transactions to return

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral disclosure burden. It implies a read-only operation by using 'list' but does not explicitly state no side effects, authentication needs, or time range limits (e.g., how far back 'recent' goes). This leaves some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long with no redundancy. The first sentence states the core functionality, and the second adds usage context. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one optional parameter and no output schema, the description adequately covers the tool's purpose and output fields. It lacks explicit ordering or time range details, but these are implied by 'recent'. Slight gap in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description adds no extra meaning to the single 'limit' parameter beyond what the schema already provides. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the exact verb ('list') and resource ('recent charges and payments') and enumerates the fields returned. It clearly distinguishes from sibling tools that focus on metrics, summaries, or specific analyses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a usage hint ('Great for checking latest sales activity'), providing context for when to use. However, it does not explicitly state when not to use or compare with alternatives, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_refund_analysisRefund AnalysisA

Analyze refunds: total count, amount, refund rate vs successful charges, and details of recent refunds including reasons. Helps identify product issues.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Time period to analyze	30d

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It states the tool returns aggregated metrics and recent refund details, implying read-only analysis. However, it does not explicitly confirm read-only nature or discuss response structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. Front-loaded with the verb 'Analyze' and key outputs. Every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description adequately covers purpose and expected results. Minor gap: no mention that output is a summary (no pagination).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with an enum parameter (period). The description adds no extra meaning beyond what the schema provides, thus scoring baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes refunds, listing specific metrics (count, amount, rate) and implicit goal (identify product issues). It distinguishes from sibling tools like get_customer_metrics or get_product_performance by focusing solely on refunds.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for product issue identification but fails to mention when not to use it or suggest sibling tools for other contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_revenue_forecastRevenue ForecastA

Predict future revenue based on recent trends. Shows current MRR, projected monthly and annual revenue, growth trend direction, and confidence level. Uses 3-month rolling analysis.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses key outputs but omits limitations like data freshness, assumptions, or that it's a statistical model, leaving some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, front-loading the purpose and efficiently covering key details without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return values well but could be more specific about format (e.g., numeric vs. string for trend direction).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. The description adds value by detailing what the tool returns (MRR, projections, trend, confidence), which compensates for the lack of output schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool predicts future revenue based on trends, listing specific outputs like MRR, projected revenue, growth direction, and confidence. It distinguishes itself from siblings that summarize current revenue or other metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for recent trend analysis via '3-month rolling analysis' but lacks explicit guidance on when not to use it or alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_revenue_summaryRevenue SummaryB

Get a complete revenue overview including MRR, ARR, total revenue, transaction count, average transaction value, and period-over-period growth rate. Supports periods: 7d, 30d, 90d, 1y.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Time period to analyze	30d

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It lists output metrics but does not disclose whether the tool is read-only, any side effects, data freshness, or pagination. It is decent but incomplete for behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, efficient and no redundancy. Front-loads the core purpose and lists supported periods clearly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple schema (one optional enum parameter) and no output schema, the description covers what the tool returns. It could mention scope (e.g., entire account) or if it includes historical data, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (single enum parameter). The description restates the period options but adds no new meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves a revenue overview including specific metrics (MRR, ARR, etc.) and the period parameter. However, it does not differentiate from sibling tools like get_revenue_forecast, which could overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., get_revenue_forecast or get_customer_metrics). An agent would need to infer usage from the sibling names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_subscription_healthSubscription HealthA

Full subscription analytics: active subscriptions, churn rate, MRR, ARPU, new vs canceled subscriptions, and breakdown by plan. Essential for SaaS metrics.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description lists output metrics but does not disclose behavioral traits like read-only nature, authentication requirements, or side effects. Burden falls on description, which is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with key action and content. Every sentence adds value; no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no parameters, description adequately explains what the tool returns. Missing details like time period or snapshot type, but reasonably complete for a simple analytics tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, so baseline 4 applies. Description adds value by explaining what the output contains, compensating for the lack of parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it provides 'full subscription analytics' with a specific list of metrics (active subscriptions, churn rate, MRR, etc.), distinguishing it from sibling tools like get_customer_metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage for SaaS metrics but does not explicitly state when to use this tool versus alternatives or provide exclusions. Context from sibling names helps but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.0.0May 30, 2026
- First observedget_customer_metrics
- First observedget_product_performance
- First observedget_recent_transactions
- First observedget_refund_analysis
- First observedget_revenue_forecast
- First observedget_revenue_summary
- First observedget_subscription_health

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-05-30 14:25 across 7 tools

Disambiguation5/5

Each tool targets a distinct aspect of business metrics: customers, products, transactions, refunds, revenue forecast, revenue summary, and subscriptions. There is minimal overlap, and descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent 'get_' prefix followed by a descriptive noun phrase (e.g., get_customer_metrics, get_revenue_summary), making them predictable and easy to understand.

Tool Count5/5

With 7 tools, the server covers key analytical areas without being overwhelming. The count is appropriate for a focused metrics server, each tool earning its place.

Completeness4/5

The tool set covers core SaaS metrics like revenue, customers, products, transactions, refunds, and subscriptions. Missing advanced features like cohort analysis or funnel metrics, but the surface is largely complete for typical use.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

RampOAuth
com.ramp.ramp-mcp-remote
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
Finance Databases Search
2
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111

Related MCP Servers

saas-brain-mcp
Finance Databases Monitoring
Mohd16kaif
F
license
Not graded
quality
D
maintenance
Open-source MCP server for Claude AI that connects Stripe and Supabase to enable natural language SaaS analytics, including churn analysis, subscription tracking, and revenue insights.
Updated 5 months ago (2026-04-13 06:11 UTC)
-
Metabase MCP Plus
Databases Data Visualization Search
schachan
A
license
A
quality
C
maintenance
An MCP server that enables AI assistants to query databases, execute SQL, and manage Metabase resources like dashboards, cards, and collections through natural language.
Updated 6 months ago (2026-03-20 01:45 UTC)
22
MIT
revenuecat-charts-mcp
Finance Monitoring
stackcurious
A
license
A
quality
D
maintenance
An MCP server that gives AI agents access to RevenueCat's Charts & Metrics API. Query MRR, churn, trial conversion, revenue, and 17 more subscription metrics directly from Claude, Cursor, or any MCP client.
Updated 5 months ago (2026-04-03 16:05 UTC)
5
8 npm
MIT
revenuecat-charts-mcp
Finance Research & Data
joeyaflores
A
license
A
quality
D
maintenance
An MCP server that enables AI agents to query RevenueCat's subscription analytics API using natural language, retrieving metrics like MRR, churn, and revenue.
Updated 6 months ago (2026-03-13 15:12 UTC)
3
5 npm
MIT