well_render_burn

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

Put a burn figure YOU computed onto the burn 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 burn yourself and can state every field below from your own work — never to "get" a burn. The server derives no burn 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 to you 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 outflow per month, as a POSITIVE magnitude in `currency` - `window` — the months the average divides by, not the months that carried spend - `convention` — "signed", and the counts you elected it from - `months_in_window` and `months_with_data` — 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 an outflow, and that the average still divides by the whole window - `excluded` — what fell out, in named groups - `transaction_count` and `unplaceable_count` — how much of the window could be placed inside or outside the transfer rule at all REFUSED rather than rendered: - a negative `amount` — a burn is a magnitude; a negative one means a signed subtotal was used without taking its magnitude - `convention: "magnitude"` — that feed keeps direction in a field no grouping here reaches, so no outflow was measured - `months_with_data` above `months_in_window`, or `unplaceable_count` above `transaction_count` - a `months_in_window` that disagrees with the months `window` spans — the two state one fact, and a reader cannot tell which is the lie - `signed` elected from ZERO negative rows: whatever the convention was called, that window measured no outflow - `convention_counts` summing past `transaction_count`, or `months_with_data` disagreeing with the months `per_month` shows carrying an outflow — your own prose states both, so a contradiction between them is a sentence that refutes itself - a `window` whose bounds are not each the first of a month, or that fits inside one month: a month average divides by whole months - a `per_month` series that is not the window's own months, in order, averaging to `amount` — a dark month belongs in it as a zero, and a series that disagrees with the figure is not the working behind it - a `currency` outside ISO-4217 — the code is checked against the catalog, not its shape OPTIONAL, and only as a pair: - `baseline` and `change` — the earlier window you compared against, its own average, and the signed percentage between them. Send both or neither: a percentage whose baseline the reader cannot name is exactly the unchecked number this tool refuses everywhere else. The card draws the CHIP alone and never the baseline, so sending the pair obliges you to NAME that comparison in prose: the baseline window and its own average. Compute the baseline the same way you computed the figure, over a window of the same length; the two may overlap, and when they do say so too. `change` is checked against `amount` and `baseline.value` and refused when it does not follow from them, so send the percentage you actually divided. Do not send a direction: down is GOOD for a burn, and the card's green is decided server-side from `change` rather than read off its sign. 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.