Rootline

**USE THIS for any 'summarize / how much / top methods / activity' question over a time window** — it walks and aggregates internally. Single tool call, no manual loop. For individual rows or a specific payment, use `list_payments` instead. Resolve the `acc_…` via `find_accounts` first — never guess an id or ask the operator for one. **The window is when the PAYMENTS happened**, not when settlement ran. It walks the account's settlement reports, keeps the released payments (journal == 'funds_released') whose `payment_created_at` falls inside [since, until), aggregates, and returns one structured payload. So "how did account X do on 18-19 June" means exactly that, even though the report carrying those payments was generated days later — settlement lag is handled internally and is not something to compensate for in the arguments. `since`/`until` accept an ISO date (YYYY-MM-DD, whole day) or an ISO datetime (YYYY-MM-DDTHH:MM:SS, UTC if no offset) for sub-day windows — same syntax as `list_payments`. A plain end *date* is inclusive through the end of that day; a datetime upper bound is exclusive. As with `list_payments`, these bounds are **UTC** while displayed times are local wall-clock — don't reuse a displayed time as a bound. A window whose settlement hasn't run yet returns zero with an explicit caveat saying so, rather than an unqualified "no activity". FEES, and which side of a platform you are on. `total_fees` breaks the window's fees down by kind (platform_fees, interchange_fees, scheme_fees, markup, commission, processing_fees, other_fees), keyed by currency, and lists only the kinds that carry money. Every figure is signed from THIS account's point of view — negative is money leaving it — so gross + fees = net. On a marketplace SELLER's account `platform_fees` is what the platform charged it, and `total_platform_revenue` is zero; on the PLATFORM's own account `total_platform_revenue` is what it earned across all its sellers. So "what did this seller cost / earn us" is answered by running this on the SELLER's account and reading `platform_fees` — the platform's own account only ever gives the blended figure across every seller. Returns a dict with: account_id, account_name, window server_time_utc: the server clock when this ran — check a relative window ("today", "this week") against it before trusting a zero settled_through: the latest date settlement has actually covered for this account, or null when no report matched; a window running past it is partial and says so in follow_ups summary: total_count, total_gross / total_net / total_platform_revenue / total_fees (each keyed by currency code) by_method: list of {method, count, gross} sorted by count desc — use this to answer 'top payment methods' or 'method mix' payments: per-payment detail (payment_id, method, amounts, fees, timestamps) — use to surface notable individual payments reports_consulted: list of report IDs included Prefer this tool over `list_reports` + repeated `download_report` when the question is window-based. It's ~N× faster (parallel fetch) and one Claude turn instead of many.

get_account_activity

USE THIS for a compound 'overview / status / how is X doing / summary / overview of the <name> accounts' ask about ONE account — it answers in a single call what would otherwise take find_accounts + get_account + get_account_balance + list_payments. This is the ACCOUNT (money-holding) overview — balance + activity + terminals; it is NOT the company / onboarding lookup (that's find_companies / get_company). `account` accepts whatever the operator has: a display name, a namespace ("rootline.cafe"), or an `acc_…` id — it resolves the name the same way find_accounts does. Exactly one match → the overview. Several matches → a short list and nothing else, so you can ask the operator which one (never guess). No match → a clean not-found line. Returns one composite covering the account's identity (name, namespace, linked company), live available/pending balance per currency, the last 14 days of payments (count, succeeded/failed/abandoned, succeeded gross per currency, and the latest five), and the terminals assigned to it. Each section loads independently: if one is momentarily unavailable the overview still returns with the rest, noting the gap. DO NOT use this for a single narrow fact — a balance alone → get_account_balance; one payment → get_payment; a windowed aggregation with method mix → get_account_activity. This is the broad first look, not a replacement for the focused tools.

get_account_overview

Fetch real-time balance summaries for an account. Call after `find_accounts` returns an `acc_…` id — never guess an id or ask the operator for one. Returns current available + pending balances per currency. **Real-time, unlike settlement reports.** Settlement is delayed (cadence varies by account — some weekly, some daily), so a fresh capture won't appear in `get_account_activity` until the next settlement run — but it WILL be visible in `pending` here within seconds. Use this for 'how much is in account X right now?'.

get_account_balance

Download and parse a single Rootline financial report CSV. Use an id from `list_reports`, and only when the merchant asks about ONE specific report by ID. For summaries over a time window, use `get_account_activity` — it fetches and aggregates in a single tool call. Returns the report's full column set and a page of rows. Every column is in the structured output (the interactive card lets the operator toggle which columns show); use `offset` to walk further. Settlement_report columns include: `account_id`, `account_name`, `payment_id`, `payment_method`, `journal`, `gross_amount`, `gross_currency`, `net_amount`, `net_currency`, `platform_fees`, `interchange_fees`, `scheme_fees`, `processing_fees`, `journal_event_time`, `payment_created_at`. The `journal` column's value set varies by report; the values present are listed in the response. Large reports: the parsed rows come back page by page (walk with `offset`), and every response carries the report's `dashboard_url`. If a report is too large to return the whole file inline, the reply says so and hands back that dashboard link with a one-line instruction to open it and download the full file — the answer never dead-ends without a path to the data. A host that can save files (e.g. Claude Code) can write a returned small report to disk on request.

download_report

Resolve which account(s) the operator means, scoped to this login. Accounts are the money-holding layer — the `acc_…` objects that carry balances, payment activity/volume, and assigned terminals. This is the resolver for ANY "account(s)" ask ("the accounts for rootline.cafe", "my accounts", "find Acme's account"). It is NOT the legal-entity / onboarding resolver: a "which merchant / is X verified / onboarding status" ask goes to `find_companies` instead, never here. Pass `name` with whatever the operator called the account ("Rabobank test", "Acme Bakery") to get the best server-side matches. This is the fast path and the only one that scales: it runs ONE ranked search and the API caps it at 10 results (no pagination), so a login with hundreds of accounts still resolves a name in a single request — never a full walk. A namespace-shaped term (e.g. "rootline.cafe") also resolves: if the ranked search finds nothing, it retries as an exact namespace lookup, so operators can identify an account by namespace as well as by name. Leave `name` unset only to answer "what can I see" — that returns the in-scope account total plus a first page, not the entire list. When `truncated` is true, more accounts matched than were returned: ask the operator to be more specific rather than guessing from a partial list. The accounts returned are exactly those this login is permitted to see — nothing more. Identity is taken from the operator's sign-in. Returns the matched `account_name` + `acc_…` id for YOU to act on: chain them straight into the next lookup (balance, activity, company, devices). Never ask the operator to supply, paste, confirm, or look up an `acc_…` — resolving names to ids is this tool's whole job, and sending them to the dashboard for an id defeats the point of the connector. Lead the operator with the account NAME, not the raw id string, but you always hold the id to chain with. operator: {username, name, email} — context only, don't recite it account_count: accounts matching `name` (or total in scope when unset) accounts: [{account_id, account_name}] — the matches to choose from truncated: true when more matched than were returned (ask to narrow)

find_accounts

Find companies (legal entities / merchants) and their onboarding status, scoped to this login. Companies are the legal-entity layer — the `co_…` objects that carry verification/onboarding status, KYC next-action, and registered country + address. They do NOT carry balances or payment activity. This is the tool for "what's the onboarding status of <merchant>?" and "which of my merchants are suspended / need action?". It is NOT the resolver for an "account(s)" ask. Anything about balances, payment activity/volume, terminals, or "the accounts for <name>" goes to `find_accounts` (or `get_account_overview`), never here — even when the operator names a brand or namespace that also happens to be a merchant. Pass `name` with whatever the operator called the merchant to match by name. Pass `verification_status` — one of `created`, `open`, `verified`, `not_accepted`, `suspended` — to list merchants in that onboarding state. Combine both to check one merchant's state. Leave both unset to answer "what companies can I see" — the in-scope total plus a first page. Each match carries the company NAME, its `co_…` id, the onboarding `verification_status`, and the pending `next_action` when there is one — so the status question is answered in-line, and you can chain the `co_…` into `get_company` for full detail. Never ask the operator to supply a `co_…`; resolving names to ids is this tool's job. Lead with the company NAME. Status here is fresh within seconds. For the authoritative real-time status of ONE company, chain its `co_…` into `get_company`. When `truncated` is true, more companies matched than were returned: ask the operator to narrow rather than guessing from a partial list. total_count: companies matching the query (or total in scope when unset) rows: [{company_name, id_raw (co_…), status, next_action}] operator: {username, name, email} — context only, don't recite it truncated: true when more matched than were returned (ask to narrow)

find_companies

Fetch metadata for a single Rootline report by its `report_…` ID — use an id from `list_reports`. Returns the row dict (see `list_reports` for columns). An id that matches no report is an error, the same as an unknown `pmt_…` on `get_payment` — never a silently empty result that could be read as "a report with no data".

get_report

List the accounts a payment device is *eligible* to be assigned to (not yet assigned). Use this to discover valid `account_id` values before calling `manage_payment_device(action="assign", …)` — it will reject an account that isn't on this list. Different from `get_payment_device(...).assignments`, which is the *current* assignment set. Returns `accounts`, a list where each entry has `id` and `name`.

list_eligible_accounts

List payment devices (terminals), cursor-paginated. Optionally filter by `account_id` to scope to devices assigned to one account. `page_size` is 1-100 (values above 100 are rejected). Returns `{rows: [...], next_cursor, has_next, total_in_scope}` — same shape as `list_reports`. To walk further pages, pass the returned `next_cursor` back exactly as returned as `after` — never construct, modify, or reuse a cursor across different filters. There is no connectivity/last-seen field on a terminal — its `status` is ASSIGNMENT status (assigned to an account vs unassigned), not online/ offline. To gauge whether a terminal is transacting, look at recent payments via `list_payments(payment_device_id=…)`. Use to answer 'what terminals does account X have?' or to find a device whose `device_…` ID isn't already known.

list_payment_devices

List individual payments, newest first, with server-side filters. SPLIT PAYMENTS: upstream, every split is its own payment, so a split checkout produces a root row PLUS one row per split — same amount, same timestamp, ids differing only near the end. By default those split sub-payment rows are hidden (one row per customer transaction) and the result says how many were hidden. Pass `include_splits=True` for the full ledger; split rows are then marked and excluded from the summed total. Counts and sums over the default view are per customer transaction — never double-counted. SPLIT DESTINATIONS: scope `account_ids` to an account that only RECEIVES splits — a marketplace seller, or a funds-holding entity such as a Dutch `stichting derdengelden` — and every row is a split whose root sits on the paying account, outside this scope. Those rows are kept and `split_destination_view` is true: they are that account's real receipts, so report them as money routed IN from checkouts taken elsewhere, not as checkouts this account took. The paying account is not on the rows. Pagination is **page-based, not cursor-based** (unlike `list_reports`): pass `page=0` for the first page, `page=1` for the second, etc. Page size is fixed at 50 rows. All filters are AND-combined. List filters (account_ids, checkout_statuses, payment_methods) are OR within themselves. Enum filter values are CASE-SENSITIVE and lowercase, and they differ from the display forms shown in results: - `checkout_statuses`: use the lowercase status as returned in `checkout_status` — e.g. "succeeded", "failed", "open". Uppercase ("SUCCESS") is rejected. - `payment_methods`: use the lowercase method code — e.g. "ideal", "visa", "mastercard". The display-case the rows show ("Ideal") is NOT a valid filter value — it silently matches zero rows. There is no currency filter (the upstream filter is broken today) — narrow by date/status/method and read the currency off the rows. `start_date`/`end_date` accept an ISO date (`YYYY-MM-DD`, whole day) or an ISO datetime (`YYYY-MM-DDTHH:MM:SS`, UTC if no offset) for sub-day windows such as the last hour. CLOCK TRAP: these bounds are **UTC**, but every time this server *displays* is local wall-clock in the deployment's display zone (CET/CEST by default) — two hours apart from UTC in summer. Reusing a displayed time as a bound returns an empty window with no error to notice. Build sub-day filters from a row's `created_at_utc`, or convert explicitly and say you did. `min_amount`/`max_amount` are in WHOLE currency units (euros), NOT minor units/cents: min_amount=100 filters to payments ≥ €100. Passing eurocents here would over-filter by 100×. `query` is a free-text search across reference + customer fields. Use this for individual rows or a specific payment — 'show me payments for account X last week', 'top recent payments', 'declined payments for method Y', or 'payments in the last hour' (pass start/end one hour apart). For a single known `pmt_…` ID, use `get_payment` instead — it returns the full detail tree (authorizations, captures, refunds, …). For a how-much / summary total over a window, use `get_account_activity`, which walks and aggregates internally. "Biggest / largest payment": there is NO server-side sort by amount. To find it, ratchet `min_amount` upward (e.g. try 1000, then 5000, …) until only a handful of rows come back, or pull a window and compare the amounts in the returned rows — do not claim a maximum you didn't actually see. ACCURACY TRAP: filtering `checkout_statuses=["succeeded"]` excludes failed and abandoned attempts, and the largest attempt is often a decline — so a "biggest payment" answer scoped to succeeded can silently miss it. Leave the status filter off (or say you scoped to succeeded) when the question is about the largest attempt, not the largest *successful* payment. Returns: - `payment_summaries[]` — each row has `payment_id`, `created_at` (the upstream value, whose shape isn't guaranteed), `created_at_utc` (the same moment as an unambiguous ISO-8601 UTC instant — **this is the one to build a filter from**), `created_at_display` (local wall-clock with its zone label, for reading aloud — never for filtering), `account_id`, `amount` (with currency + value), `payment_method`, `checkout_status`, `reference`, `is_split_root`. On a platform the account is the platform's on every row, so `reference` (the merchant's own order id) is the only per-row clue to which seller or venue a payment belongs to. - `hidden_split_count` — split sub-payment rows hidden from this page (0 when `include_splits=True`, and 0 on a split-destination view). - `split_destination_view` — true when every row is an incoming split (see SPLIT DESTINATIONS above). - `total_payments` / `total_payments_in_scope` — root rows on THIS page (default), or rows seen through this page when `include_splits=True`; either way `has_next` (not these counts) says whether more pages exist — pass page+1 to fetch them.

list_payments