Get the workspace's current cash runway — cash on hand, trailing-3-month average burn, and months of cash left — the exact same computation and numbers the Well app's canvas KPI cards show. Use this instead of computing runway yourself from raw account/transaction reads.
Returns `cash` (amount + currency), `avg_burn` (amount + currency + trailing_months), `months`, and a `status` discriminator:
- "ok" — a finite months figure.
- "capped" — runway exceeds 36 months; report as ">36 months", not the raw number.
- "infinite" — cash is positive and the workspace isn't burning (net inflow); there is no meaningful "months" figure.
- "insufficient_data" — not enough connected cash/transaction data to compute; tell the user to connect a bank/accounting connector (well_list_connectors) instead of guessing.
`change` is a percentage against `baseline`. A baseline runway divides a month-end cash reading by a trailing burn window, so it takes two dates to describe: `baseline.period` is the cash month-end it was anchored at, and `baseline.burn_window` is the span of the burn it divided by, which normally ends an earlier month. Never present the baseline as the runway measured on one day. `trend` is whether the change is GOOD, not which way the number moved; `trend_polarity` is `higher_is_better` for runway, so `"up"` means the runway grew. Read the sign of `change` for direction.
`partial: true` means some accounts or transactions were excluded from the computation (e.g. missing FX rate) — mention the exclusion counts and any `hints` if present rather than presenting the number as unconditionally complete.
Pass `year` + `month` to read a past reporting period instead of the live figure. There is no burn-window option here on purpose: the runway figure composes the endpoint's own trailing burn, so a custom window would pair `months` from one window with `avg_burn` from another and the cash ÷ burn division could not reproduce the headline. Call `well_get_burn` for a different window.
For the month-by-month cash series, call `well_get_cash_forecast`. Its forward half is a WORST CASE: it assumes the trailing burn continues and no revenue arrives at all. Never describe it as expected, forecast or likely cash, and never quote a month from it as what the balance will be — say what it is, the floor if nothing changes. A month in the settled half is a measured balance and may be stated plainly.
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.