Skip to main content
Glama
clamp-sh

Clamp Analytics MCP Server

Official

revenue.retention

Read-only

Measures cohort revenue retention by anchoring customers at their first subscription event and reporting user retention plus net dollar retention at 7, 30, 60, and 90-day windows.

Instructions

Cohort revenue retention. Anchors each customer at their first cohort event (default: $subscription_started), then reports user retention + dollar retention at each anniversary window (default: 7d, 30d, 60d, 90d). Use this to answer "are customers sticking around?" and "is revenue churning, flat, or expanding?" in one round-trip.

Math is MRR-on-MRR: for each member, mrr_at_d is the cumulative sum of mrr_delta from anchor through anchor + d (the member's current MRR balance at that point). Retained members are mature members with mrr_at_d > 0. NRR = sum(mrr_at_d) / sum(baseline_mrr) across the same mature cohort — above 1.0 means net expansion (upgrades > churn), below 1.0 means contraction.

mature_size < size for windows the cohort isn't old enough to reach yet (e.g. a 90d window for a 30d-old cohort). Use mature_size to dim early windows or label them "cohort not yet mature".

Examples:

  • "what's our 30d retention" → read retention[].window=="30d".retention_rate (null when no mature members)

  • "are we expanding or contracting" → compare nrr across windows

  • "how many of last quarter's signups are still paying" → cohort_period="90d", read retention[].window=="90d"

Limitations: anchor is the user's FIRST cohort event in the period — re-subscribers after a cancel won't get a new anchor. The math assumes mrr_delta is set on $subscription_started / $subscription_canceled / plan-change events; events without mrr_delta don't affect the running balance. Canonical billing events are $-prefixed on the wire — pass cohort_event="$subscription_started" (not bare subscription_started) to anchor on them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idNoTarget project ID (e.g. "proj_abc123"). Required when the credential has access to multiple projects. If omitted and only one project is accessible, that project is used automatically. Call `projects.list` to discover available project IDs.
cohort_eventNo
cohort_periodNo
cohort_filter_propertyNo
cohort_filter_valueNo
windowsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cohortYes
sizeYes
baseline_mrrYes
currencyYes
retentionYes
Behavior5/5

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

Beyond the readOnlyHint annotation, the description details the MRR-on-MRR math, how mature_size works, and event requirements (e.g., $ prefix). No contradictions.

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?

Well-structured: purpose first, then math, then examples, then limitations. Every sentence adds value, and the description is front-loaded.

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

Completeness5/5

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

For a complex tool without an output schema provided, the description fully explains output concepts (retention_rate, mature_size, NRR) and how to interpret results. Covers limitations and edge cases.

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?

Defaults for cohort_event and windows are explained, and the $ prefix for events is highlighted. However, cohort_filter_property and cohort_filter_value are not described; schema coverage is only 17%.

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 computes cohort revenue retention, anchoring at first cohort event and reporting user and dollar retention per window. It distinguishes itself from sibling 'cohorts.retention' by focusing on revenue metrics.

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?

Provides concrete examples of queries and mentions limitations (e.g., re-subscribers). Lacks explicit comparison to sibling tools like 'revenue.sum' but gives good context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/clamp-sh/mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server