Show records
well_show_recordsPut a table of records IN FRONT OF THE USER. Use it when the user asked to SEE rows — "show me my invoices", "list my companies", "which suppliers have no category" — and when the answer you owe them IS the table.
Without columns, the table is the root's display view in the Well web app's column order. With columns, the table shows those paths in that order, sideways-scrollable, with the root's identity column first.
⚠️ FOR A READ THAT IS YOURS RATHER THAN THEIRS, CALL well_query_records INSTEAD. Same arguments, same rows, no table. Every gate, count, freshness check and intermediate read belongs there — this tool renders on every call, so using it for an internal check drops a table into a conversation about something else.
⚠️ DO NOT NARRATE THE TABLE. The card already shows these rows; restating them as markdown gives the user the table and a duplicate list under it. Two things the table cannot say for itself belong in your text: totalCount when it exceeds what is displayed ("showing the 50 most recently updated of 214"), and the records_url link for everything the card truncates.
⚠️ ONE CARD PER TURN. A turn draws at most one table, and never a table beside a card that is waiting for a click.
ROOTS (read-only — all 73): companies, people, connectors, workspaces, workspace_connectors, invoices, documents, notes, transactions, accounts, memberships, payment_means, invoice_payment_means, cards, checks, chat_conversations, ledger_accounts, journals, journal_entries, tax_rates, exchange_rates, invoice_transactions, media, emails, phones, web_links, locations, categories, invoice_items, account_balances, tasks, workspace_connector_sync_logs, blueprint_runs, billing_events, payslips, messages, calendars, calendar_events, projects, shipments, activities, company_relations, connector_filters, employment_contracts, field_definitions, payslip_line_rubrics, subscriptions, supplier_payment_terms, workspace_category_overrides, workspace_groups, products, inventories, inventory_movements, daily_metrics, allocations, project_changes, shipment_events, statutory_values, adoption_scopes, browser_skills, canvas_views, connector_requests, document_layouts, expense_notes, field_rules, flow_runs, memory_units, share_links, skills, transaction_category_rules, workspace_posting_mappings, workspace_schedules, workspace_views (The accounting graph — ledger_accounts, journals, journal_entries — and balances/rates are read-only projections owned by the sync/posting pipelines; query them for financial context, you cannot create/update them here. Sub-resources like emails/phones/locations are usually richer when read via their parent company/person.) ("messages" holds the messages Well sent outbound on a member's behalf — emails and WhatsApp; notifications to the member are not stored. A message is visible to its sender only, so a read returns the caller's own messages. Filter by sender_membership, recipient_person or recipient_address, message_category, channel, status.)
CATEGORY CATALOGS: "categories" holds two independent taxonomies, separated by category_type. Always filter on it — an unfiltered read mixes them:
whereClause: { category_type: { _eq: "company" } }is the COMPANY-CATEGORY catalog: the industry labels a counterparty carries, and the idswell_update_company({ category_ids })accepts. There is no curated allowlist — the labels are minted during enrichment — so read them here rather than inventing a taxonomy.whereClause: { category_type: { _eq: "transaction" } }is the management/transaction taxonomy.
TRANSACTION FIELD NAMES (root "transactions"; a path opens with "transactions", e.g. ["transactions", "counterparty"]):
The name of the other side is counterparty: the company paid on an outflow, the one who paid on an inflow. When it is empty, provider_label holds the name the bank gives that side. Both are computed when the row is read: select them, but never filter, sort or total on them. To filter on a supplier, filter creditor_payment_means.company.name.
remittance.unstructured is the payment reference the bank carries: an invoice number, or a code of the bank such as fx_card. It is never the name of the other side: never give it as a name, and never quote a bank code to the user. When counterparty and provider_label are both empty, use it only to say in plain words what the movement is: fx_card on a Qonto account is a Qonto currency exchange fee ("frais de change Qonto").
The amount is instructed_amount.amount with instructed_amount.currency. Its sign gives the direction (negative for an outflow) only when amount_sign is "signed"; on any other row, give the amount as it is and never call it an outflow or an inflow. The date is executed_at. status says where the payment stands.
A list of transactions for the user reads executed_at, counterparty, provider_label, remittance.unstructured, instructed_amount.amount, instructed_amount.currency and status, newest first (orderBy executed_at, desc).
TRANSACTION CATEGORY FIELDS (root "transactions"): Well's category of a transaction is on the transaction row itself:
category_normalized: the category label. category_key: the stable key of that label.
category_status: the categorization state (values: "categorized", "uncategorized", "classifier_abstained", "classifier_failed", "pending", "legacy_unmapped"). "pending" means a categorization run is queued or in flight. Whether the transaction has a category is decided by category_normalized alone. When category_normalized is empty, tell the user the transaction is not categorized yet, in the language of your reply.
category_source: who wrote the category (values: "classifier", "user", "connector", "rule").
To find the transactions that have a category, read or filter these fields, for example whereClause { category_normalized: { _is_null: false } }. To find the transactions without one, use { category_normalized: { _is_null: true } }.
The transaction_categories relation holds only the labels that an accounting connector sent with the transaction. A bank-feed transaction usually has none, and Well never writes one. Never read or filter transaction_categories to say that a transaction has a category or has no category.
ACCOUNT FIELD NAMES (root "accounts"; a path opens with "accounts", e.g. ["accounts", "account_name"]):
The label of an account is account_name. The accounts root has no name column: never select or filter "name" on it. From the account_balances root, the label is account.account_name.
Never filter accounts on a bank name. bank_company stays empty until Well identifies the bank, and account_name is the label the provider sends (for example "Plaid Checking"), so such a filter returns no row for an account the workspace holds.
For the accounts or the balance at a named bank, call well_list_account_balances and keep the rows whose institution_name is that bank. Never say that the workspace has no account at a bank from a records read.
CONNECTED TOOLS: do NOT use this tool to show the user what they have connected — call well_list_connectors instead. It owns that job: connection status, and an install link for anything not connected yet. Query root "workspace_connectors" here only for genuine RECORD-level needs — reading sync timestamps, filtering connections, joining them with other roots. ("connectors" is the installable catalog; "workspace_connector_sync_logs" is per-sync history.)
Well already syncs the providers' data into the roots above — invoices, transactions, accounts, the accounting graph. ALWAYS read it from here. well_invoke_connector_tool and a provider's own tools are for an ACTION the user explicitly asked to take on that provider (e.g. "create this record in Attio"), never a way to fetch data Well already holds.
FILTERING (whereClause):
Uses Well's whereClause operators (underscore-prefixed, e.g. _eq, _ilike, _and) on field names.
Safe operators (work on ALL field types): _eq, _neq, _in, _nin, _is_null
Numeric/date only: _gt, _gte, _lt, _lte
Text only: _like, _ilike
When unsure of a field's type, prefer _eq or _in (they always work).
Combine with _and, _or, _not
For relationship fields, use nested syntax: { "issuer": { "company_id": { "_eq": "<company_id>" } } }
NEVER select the workspace's OWN records by matching a company name. One legal entity appears under several labels — a registered name, a trade name, a bank-issued label — so a name filter silently drops rows and the total reads as complete. On the invoices root, pass
partyScopeinstead: it resolves the workspace's own side on the server, so this query needs no id lookup and no extra call. Call well_get_own_company for the id only when a root has nopartyScopeand you must filter on the nested company_id yourself.Match a counterparty by id too whenever you have one. Reach for _ilike on a name only to DISCOVER candidates to show the user, never to compute a figure you will report. Examples: { "status": { "_eq": "unpaid" } } { "grand_total": { "_gt": 1000 } } { "local_currency": { "_eq": "EUR" } } { "_and": [{ "status": { "_eq": "unpaid" } }, { "grand_total": { "_gte": 500 } }] } { "issuer": { "company_id": { "_eq": "<company_id from well_get_own_company>" } } }
SORTING (orderBy):
Sort by any field: { field: "grand_total", direction: "desc" }
Default sort is newest first on
created_at; transactions sort onexecuted_at, companies and people by name.
⚠️ RULES:
Omit
fieldsandcolumnsto show the user the root's own display viewcolumns(at most 12 paths) is what the user SEES: the paths REPLACE the display view, and the root's identity column still leadsfieldsis ADDITIVE and for values YOU need to reason about: it widens the payload you read and never changes the columns the user seesField paths from schema: "invoices.issuer.name" → ["invoices", "issuer", "name"]
Default 50 records per request, max 500.
EXAMPLE - show the user their invoices (no fields, ever):
well_show_records({ root: "invoices", limit: 50 })
ONE CALL IS THE ANSWER — do not walk the root:
Every response carries totalCount (ALL matches, not just this page) and records_url (the full web-app table, with your filter and sort already applied). So a request to see a record type is ONE call: the user gets a table of the first page, the count tells them how many there are, and the link takes them to the rest. "Show me all my invoices" is answered by one call plus the link — NOT by fetching 483 rows into this conversation.
A non-null
nextCursoris NOT a to-do. It means more rows exist, whichtotalCountalready told you and the link already covers.Never compute a total from the rows. They are a page, so a figure added up from them changes with
limit,orderByandcursor, and the same question gets two answers. Passsumand quotetotals: it covers every match. A count istotalCount.Never paginate to "be thorough". Large roots will exhaust the output limit mid-walk, and the user ends up with nothing legible.
Paginate ONLY for per-row work over every match that no aggregate can express, and tell the user the cost before starting. Then: pass the returned
nextCursorascursor;nextCursor: nullis the last page.
Returns { rows, columns, totalCount, nextCursor, records_url, success }.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sum | No | Numeric fields to total over EVERY row the filter matches, not over this page. The result's `totals` gives one group per currency, each with its row `count` and one sum per field, so the figure is the same whatever `limit`, `orderBy` or `cursor` you pass. Quote these sums for any total you report; never add up the rows. Fields it takes, per root: `invoices`: `balance_due` (in `local_currency`), `grand_total` (in `local_currency`), `paid_amount` (in `local_currency`); any other field is refused. At most 3 fields. Example: ["balance_due"]. | |
| root | Yes | The entity type to query — any of the 73 read-only roots (companies, people, connectors, workspaces, workspace_connectors, invoices, documents, notes, transactions, accounts, memberships, payment_means, invoice_payment_means, cards, checks, chat_conversations, ledger_accounts, journals, journal_entries, tax_rates, exchange_rates, invoice_transactions, media, emails, phones, web_links, locations, categories, invoice_items, account_balances, tasks, workspace_connector_sync_logs, blueprint_runs, billing_events, payslips, messages, calendars, calendar_events, projects, shipments, activities, company_relations, connector_filters, employment_contracts, field_definitions, payslip_line_rubrics, subscriptions, supplier_payment_terms, workspace_category_overrides, workspace_groups, products, inventories, inventory_movements, daily_metrics, allocations, project_changes, shipment_events, statutory_values, adoption_scopes, browser_skills, canvas_views, connector_requests, document_layouts, expense_notes, field_rules, flow_runs, memory_units, share_links, skills, transaction_category_rules, workspace_posting_mappings, workspace_schedules, workspace_views). Call well_get_schema(root) first to discover fields. | |
| endBy | No | On a timeline, the date field each bar ends on; `groupBy` is the date field it starts on. Same path format as `groupBy`, for example ["invoices", "due_date"]. A path that is not a date of the root's own row is dropped, and each bar is then one day long. Omitted, a saved view keeps its own end date. Ignored on any other layout. It changes the link, never the rows. | |
| limit | No | Max records to return (default 50, max 500) | |
| cursor | No | Opaque cursor for the next page. Omit for the first page, then pass nextCursor from the previous response. | |
| fields | No | EXTRA field paths to add to the root's display view, for values you need to reason about. Each path is an array whose first segment is the root's table name — use the paths well_get_schema(root) returns verbatim, which is the root name for every root except people (whose table is peoples); a path opening with any other segment is dropped. Additive only: they widen the payload you receive, and the root's own display projection (the columns the Well web app shows, and the ones a table drawn from this query carries) stays what it is no matter what you pass here. A scalar a composite renders comes back AS that composite — asking for grand_total gets you composite_total_amount_currency, with grand_total inside it — so read `columns` for what was actually materialized. Omit unless you need a value the display view does not carry. | |
| layout | No | The layout `records_url` opens the table in: one of table, kanban, calendar, gallery, chart, list, graph, timeline. Any other value is ignored. Omitted, a saved view keeps its own layout. It changes the link, never the rows. | |
| viewId | No | A saved view of this workspace, by its id. The read applies the view's filters and sort (and, on well_show_records, its columns), and `records_url` opens the table on that view. `root` must be the view's root. `whereClause` narrows the view's rows further; `orderBy` and `columns` replace the view's own. | |
| columns | No | The columns the table shows, in this order. Same path format as `fields`: each path is an array opening with the root's table name, taken verbatim from well_get_schema(root); a path opening with any other segment is dropped. A scalar a composite renders comes back AS that composite, so `grand_total` shows as `composite_total_amount_currency`; read the result's `columns` for what was materialized. They REPLACE the display view; the root's identity column still leads. Omitted, the table shows the root's own display view. At most 12. | |
| groupBy | No | The field whose values make the columns of a kanban (or group a calendar, or start the bars of a timeline) when the table opens through `records_url`. One path in the `fields` format, opening with the root's table name, for example ["invoices", "status"]; a path that is not a field of the root's own row is dropped. Omitted, a saved view keeps its own grouping. It changes the link, never the rows. | |
| orderBy | No | Sort results by a field. Example: { field: "grand_total", direction: "desc" } | |
| listRows | No | false when your text already reports on the rows (a short report: the count, the totals, the highlights). A chat that lists the first rows under your text then sends only the link to the table. Omitted or true, it lists them. It changes no row and no table. | |
| allFields | No | If true, automatically fetches all scalar fields from schema. No need to specify fields. | |
| partyScope | No | Which side of an invoice the workspace itself occupies, resolved from its own company rather than a party name. `invoices` root only. "purchase" = the workspace owes it (payables); "sales" = the workspace is owed (receivables); "intra_self" = both parties are companies the workspace owns; "unattributed" = Well cannot place it on either side. The four partition every invoice, so report the "unattributed" count beside any payable total rather than dropping it — an unattributed invoice may still be owed. Prefer this over hand-writing an issuer/receiver filter. | |
| whereClause | No | Filter object in Well whereClause syntax. Operators: _eq, _neq, _gt, _gte, _lt, _lte, _like, _ilike, _in, _nin, _is_null. Example: { "status": { "_eq": "unpaid" } } | |
| workspace_id | No | Target workspace. Omit to query every authorized workspace at once; each row comes back tagged with the workspace it belongs to. | |
| conversation_id | No | 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. | |
| workspace_scope | No | Restrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | Query results | |
| error | No | ||
| end_by | No | The date field path a timeline ends its bars on: the asked one, else the saved view's. Null on any other layout. Each row carries its value. | |
| layout | No | The layout the records card draws and `records_url` opens: the asked one, else the saved view's. Null when neither names one. | |
| totals | No | Present when `sum` was passed and the total read succeeded: the sums over every matching row, one group per currency. `truncated: true` means the group list hit its cap and is incomplete. `completeness` (invoices root only) says how far the workspace's own-side resolution lets you trust the total: the self-party set's size and the counts of the rows it could not prove a side for. | |
| columns | No | The materialized columns in display order, with each composite substituted in place of the source fields it consumed. A row object's key order does not preserve this — the flattener appends reconstructed composites last — so a UI that wants the web app's column order must read it from here. | |
| success | Yes | ||
| group_by | No | The field path a kanban or a calendar groups the rows by, or a timeline starts its bars on: the asked one, else the saved view's. Each row carries its value. | |
| returned | Yes | Number of rows returned | |
| columnMeta | No | Per-column field meaning, keyed by the same column paths as the rows. `context` = what the field means; `enrichment` = how the value is sourced (e.g. Bank sync, AI extraction). Only documented columns appear. Read this to interpret the returned values. | |
| nextCursor | No | Cursor for the next page. null means last page. | |
| totalCount | Yes | Total matching records | |
| party_scope | No | Present only when `partyScope` was passed: what the scope resolved to on this read. `side_unknown: true` means the workspace resolved no own company, so NO side filter was applied (`applied: false`) and the rows and totals cover invoices on BOTH sides — say the side is unknown, never that the figure is the requested side's. | |
| records_url | No | Login-gated deep link to the FULL web-app records table for this root (real DataTable: composites, inline editing, resize/pin), carrying this call's `whereClause` and `orderBy` so it opens on the same rows. Hand it to the user for everything past this page — it is the answer to 'show me all of them', not pagination. Null when no workspace is in context or no web page serves the root. | |
| conversation_id | No | The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation. | |
| newly_connected | No | Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later. | |
| workspace_figures | No | Present when a read that names no workspace covered several and passed `sum` or `partyScope`: one entry per workspace it read, with that workspace's own count, totals and side. The top-level `totalCount` adds these counts, including any entry whose side is unknown, and no top-level `totals` exists: an amount belongs to one workspace. A workspace whose read failed has no entry and is named in `error`. | |
| totals_unavailable | No | Present instead of `totals` when `sum` was passed but no total could be measured (`timeout`, `error`, or `count_mismatch` when the total did not cover the same rows as `totalCount`). The rows are still a page: never add them up to stand in for the total. Say the total is unavailable. | |
| conversation_id_note | No | Present only when the server opened a fresh lane, stating that no choice recorded earlier was read. | |
| conversation_id_source | No | Where the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened. |