well_list_account_balances

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

List every account on the workspace with its stored balance. Rows only — this tool holds no definition of cash, and returns no figure the app renders. Use it when you are computing a cash figure whose RULES you are stating yourself: which accounts belong to the business, which account types count as cash, which stored field is "the balance", what each currency converts at. The server derives no cash position of its own from this call, so a cash figure starts here: state the rules, keep exactly the rows they admit, then put the result on a card with `well_render_cash_position`. **It applies no scope.** Every active account comes back, including ones you will almost certainly exclude. `ownership` is `workspace`, `counterparty` or `unknown`, and it decides membership together with `company_id`: - `workspace` — the business's own, EXCEPT when `own_company_id` is set AND the row names a different company. A row with no `company_id` is trusted, because a connector tags a row before any holder is known; so is a row naming a company while `own_company_id` is still `null`, because nothing has disproved the pairing yet. Only a tag contradicting a resolved anchor is stale, and counting that one widens the owned scope and overstates the figure. - `counterparty` — not the business's, unconditionally. - `unknown` — unsettled, and settled ONLY by the anchor: own when `company_id` equals `own_company_id`, a counterparty's when it names a different one. `own_company_id` is `null` when the workspace has not set one. Nothing is settled against it then — no `unknown` row, and no `workspace` row's company pairing either — so say so rather than counting or dropping on a guess. This is the same three-way rule the app's own canvas account scope applies, and a figure that departs from it disagrees with the number the product shows. **It applies no type filter.** `account_type` is one of deposit, credit, loan, investment, payroll, other. A credit or loan account is a liability, so its balance normally nets out of cash rather than adding to it — but that is your decision to state, not a fact about the row, and the sign stored is the sign the provider sent. **It chooses no amount.** `closing_booked` is SETTLED cash; `closing_value` includes pending and uncleared movements. The two differ by every initiated-but-unsettled payment, so which one you total is the single most consequential choice a cash figure makes: state it. `opening_booked` is the fallback for a freshly-opened balance with no settled activity yet. Any of them is `null` when the stored value was absent or not a finite number, which is not a zero balance. **It converts nothing.** Each reading carries its own `currency`, which can differ from the account's own `account_currency`. Convert per row at a rate you can state, then total — a sum across currencies is denominated in nothing and no field here would say it happened. `balance` is `null` when no row was selected for that account. Two different situations produce it and they must not be reported the same way: `verification_rejected: true` means the newest balance failed verification and the bounded walk back found no verified one, so the data is repudiated; `false` means the account simply has no history yet. `months_back` adds `month_ends` to every row: one reading per closed month end, oldest first, keyed `YYYY-MM`, ending on the last COMPLETE month. A `null` reading is a month no stored row covered — not a zero balance, so never plot it as one and never interpolate between two real points. Omit `months_back` for the current reading alone; the series is a second query and is not free. `partial: true` means the read was cut short BEFORE RETURNING ANYTHING, so it always arrives with an empty `rows` — it is a fact about the call, never a coverage figure over rows you received. Nothing is known about what is there, so derive no figure from it: say the read was cut short and offer to try again. `unreadable_rows` is the separate case and the only one that continues: the read finished, and that many rows carried a stored balance that could not be parsed. They hold a `null` balance, sit in no figure, and make any total a floor by exactly their count. 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.