revenue_summaryGet a one-call overview of MRR, cash collected from paid invoices, failed payment totals, and churn for the last N days, grouped per currency.
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). |
Changes observed during successful MCP inspections.
v0.1.0Does 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.