well_list_accounts_needing_company

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

List the workspace's accounts that cannot yet be placed on either side of a transfer, so a figure that depends on account ownership can say exactly what is missing before it is computed. Two states, ONE worklist, because they answer one question — whose account is this: - No company attached. Nothing can place the account on either side of a transfer. - `ownership: "unknown"`. The account has a company, and whether the workspace owns it is unanswered. The second is not the lesser case. An account left `unknown` sits outside the internal-transfer rule exactly as an unattached one does. **This is a gate on a FIGURE, not a tidiness list.** `well_sum_transactions` with `exclude_internal_transfers` keeps the rows with exactly one leg on an account the workspace OWNS, and drops the two-leg ones. So an account's ownership decides whether its movements count as money leaving the business. An account wrongly marked as the workspace's own removes real spend from the figure, quietly, with no error anywhere. **Do not propose an owner of your own.** You cannot read one off an account's name, its bank, or the company that appears most often beside it — a name-shaped match proposes the company minted FROM that name, and the bank that issues an account is not its owner. Where the system HAS a grounded proposal it rides on the row as `company_suggestion`, and the card is where a reader accepts it. `unknown` is a truthful state and a wrong classification is not. Each row carries `account_id` (pass it to `well_assign_account`), `account_name`, `iban`, `currency`, the `company_id` and `company_name` already attached when the gap is the ownership rather than the link, and `ownership`. `own_company_id` names the company that IS the workspace. It is what settles ownership without guessing: an account attached to that company is the business's own, and one attached to any other company belongs to a counterparty. When it is null the workspace has set no anchor, so nothing here settles ownership and the account stays `unknown` until a reader says otherwise. The companies a reader can pick ride alongside the rows, capped. When the workspace holds more than the cap, narrow them with `company_search` rather than assuming the card carries every company. A row whose ownership is already `workspace` carries `company_suggestion`: the company that IS the workspace, which is what such an account belongs to by definition. The field is ABSENT on a `counterparty` or still-`unknown` row, and on a workspace with no anchor set — absent means nothing grounded a guess, never that the row was checked and has no owner. It is a proposal for a reader to accept, not a decision: ownership decides whether an account sits in the workspace's own set at all, so never write it without the reader choosing it. `truncated: true` means the page filled and more accounts exist, so report the count as a floor rather than as the total. **`success: false` means the worklist is UNKNOWN, not empty.** The read failed, so no count exists. An empty `records` on a failed read is not "every account is settled" — treating it that way lets a figure be computed on evidence it never obtained. 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.