well_render_mrr

io.github.WellApp-ai/well-mcp · Verify this server

Put an MRR figure YOU computed onto the MRR card. **This tool measures nothing.** It takes the figure and its method as input and returns them for rendering. Call it only after you have computed the recurring revenue yourself and can state every field below from your own work — never to "get" an MRR. The server derives no MRR of its own. The figure on the card is the one you state here, which is why every field below is required: the policy behind a number is the only thing that makes it checkable. **Under the number the card draws nothing.** It carries the figure, the window it averages and the trend chip; everything else you state below is REQUIRED and reaches no pixel. All of it comes back in this tool's text result, which is what you write the prose from. The card is the measure; the explanation is yours. REQUIRED, because a figure whose method is not stated cannot be checked: - `amount` — the recurring revenue per month in `currency`, net of tax and of credit notes, as the sum returned it - `window` — the months the average divides by, not the months that carried revenue - `months_in_window` and `months_with_revenue` — a window with dark months reports LOWER than its typical month. When the two differ you MUST say so in prose: how many months recorded recurring revenue, and that the average still divides by the whole window - `recurring_contexts` — the billing contexts the reader confirmed as recurring, as the keys the card recorded. `"unclassified"` among them means the reader counted the invoices with no billing context (the sum rows whose `billing_context` is `null`) as recurring. This is the reader's half of the policy and the card cannot show it, so an answer that does not name them leaves the figure unchecked - `invoice_count`, `unattributed_count` and `unclassified_count` — how much of the window the figure could reach at all. `invoice_count` is the issued invoices; `unattributed_count` is the SEPARATE set Well could place on neither side, reported beside it rather than inside it, and it may be larger. An unattributed invoice may still be recurring revenue. An unclassified one carries no billing context: it is in the figure only when `recurring_contexts` holds `"unclassified"`, and when it is, say in prose that the reader chose to count it. Send `null` for a count the sum returned as `null`: it is unmeasured, not zero - `excluded` — what fell out, as three invoice COUNTS kept apart: `one_off` (issued invoices under a context the reader did not count), `credit_notes` (the `credit_note_count` netted into the figure) and `unreadable_rows` (the sum's `excluded_malformed`, `null` when unmeasured) REFUSED rather than rendered, each because your own figures disagree with each other: - a negative `amount` — the credit notes outweighed the recurring invoices, so net recurring revenue fell below zero. That is a finding to report in prose, not a figure to put on a card, and never one to flip to its magnitude - an empty `recurring_contexts` — an MRR with nothing counted as recurring is not an MRR of zero, it is a policy nobody stated. Say the figure has nothing to measure instead - `months_with_revenue` above `months_in_window`, or `unclassified_count` above `invoice_count` - a `months_in_window` that disagrees with the months `window` spans — the two state one fact - a window whose bounds are not month starts — a month-average divides by whole months - `change` with no `baseline`, a `baseline.value` of zero, a baseline that does not start before the window or spans a different number of months, or a `change` whose magnitude or sign its own two figures contradict - a `per_month` series that does not name each month of the window once in order, does not average to `amount`, or disagrees with `months_with_revenue` **Send `baseline` and `change` as a pair or send neither.** Do not send a direction: the card's colour is decided server-side from the figures. Revenue is higher-is-better, which is the opposite of the burn card and exactly why a caller does not get to state it. When the token authorizes one workspace, call this directly — no other tool call is needed first. When it authorizes several, this read will not guess which one you mean: pass `workspace_id` on the call.