Skip to main content
Glama

List accounts needing a company

well_list_accounts_needing_company
Read-only

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 user asks to see, list or fix these rows, call this tool directly: its card is the answer. ⚠️ This tool draws its card on EVERY call, the empty one included. So when nobody asked for the list and you only need to CHECK whether anything is left (the first pass of a gate, or a re-check after a repair), call well_get_worklist_status({ worklist: "accounts_needing_company" }) first. It draws nothing. Call this tool after it only when it answers open: true.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax accounts to return (default 200).
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
company_searchNoNarrows the companies offered on the card by name, server-side. Use it when the workspace holds more companies than one page and the one the user means is not on it.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
recordsYes
successYes
returnedNo
truncatedNo
own_company_idNoThe company that IS the workspace; null when no anchor is set.
company_catalogNoHow many companies the card was given against how many the workspace holds. `truncated: true` means the one the user means may not be on the card — narrow with `company_search`.
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / conversation_id
      Added value: +{
      +  "description": "The conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id
      Added value: +{
      +  "description": "The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id_note
      Added value: +{
      +  "description": "Present only when the server opened a fresh lane, stating that no choice recorded earlier was read.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id_source
      Added value: +{
      +  "description": "Where the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.",
      +  "enum": [
      +    "host_meta",
      +    "argument",
      +    "minted"
      +  ],
      +  "type": "string"
      +}
  2. Added

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Well beyond the annotations (readOnlyHint=true), the description discloses that the tool draws its card on EVERY call including the empty one, that success:false means the worklist state is UNKNOWN rather than empty, and that truncated:true makes a count a floor rather than a total. It also documents field semantics such as company_suggestion being ABSENT meaning no grounded guess existed — not that the row was checked and found ownerless — which prevents serious misuse.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with bold-led paragraphs and a strong front-loaded purpose, and nearly every paragraph carries a distinct operational rule. However, it runs to roughly 600 words for a read-only list tool with four documented parameters; sections like 'The second is not the lesser case' and repeated warnings against guessing an owner could be tightened without losing substance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the domain's subtlety — ownership semantics, the unknown-vs-empty trap, and the relationship to well_sum_transactions — the description covers everything needed: the two states, own_company_id's anchoring role, company_suggestion presence/absence rules, success/truncated meanings, the lighter-weight sibling, and workspace disambiguation. The output schema and full parameter coverage handle returns and syntax, leaving no operational gap for an agent to guess about.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description adds operational context beyond the schema: companies offered alongside rows are capped and company_search exists to narrow them rather than assuming the card carries every company. workspace_id is also motivated as an answer to 'this read will not guess which one you mean,' which gives meaning beyond the schema's literal text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource — 'List the workspace's accounts that cannot yet be placed on either side of a transfer' — and explicitly defines the two qualifying states (no company attached; ownership unknown). Frames the result as a gate on a FIGURE rather than a tidiness list, which differentiates it from the many list siblings and clarifies what the list is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes between this tool and well_get_worklist_status: call this directly when the user asks to see/list/fix these rows, but call the status tool first when the agent only needs to check whether work remains, and call this only after status answers open: true. Also gives conditional workspace guidance — call directly with a single-workspace token, pass workspace_id when the token authorizes several.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources