Skip to main content
Glama

Synci

List accounts

list_accounts
Read-onlyIdempotent

List the user's connected financial accounts (bank, investment, crypto). Each is a lean summary: name, institution, category, currency, a balance block, account health, and earliest_available_date. IMPORTANT: balances can lag transactions: check balance.as_of (the last time balances synced) and caveat stale figures. IMPORTANT: earliest_available_date is the start of the account's synced history: a query for a period before it returns nothing because the data was never synced, NOT because there was no activity, so never report a total for a window that starts before it without caveating the coverage. While older history is still being fetched it is the oldest date fetched so far, and it moves back as the history arrives. It is absent only when nothing has been synced for the account yet, so the account has no history to report. health is INACTIVE for an account that is switched off or on a switched-off connection (live is false): its data is frozen at the last sync. Investment/crypto accounts have an empty balance block: read total_balance for the broker-reported portfolio value and cash_balance for uninvested cash, and call list_holdings for the positions behind them. verbose:true returns the full record. Sensitive identifiers are omitted.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_accounts"
  }
}

Input Schema

NameRequiredDescriptionDefault
verboseNoWhen true, return the full account record instead of the lean summary.
account_categoryNoOptional. Restrict results to a single account category.

Output Schema

NameRequiredDescriptionDefault
accountsYesLean account summaries; with verbose:true each item is the full account record instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / accounts / items / properties / category / description
      Previous value: -"One of BANK, INVESTMENT, DEPOSIT, LOC, LOAN. LOAN is a manual loan the user keeps by hand: its balance is negative (money owed) and derived from its terms and matched payments. A BANK account whose institution is \"Manual accounts\" is filled from statement files the user imports; its balance is the last one verified plus the rows since."New value: +"One of BANK, INVESTMENT, DEPOSIT, LOC, LOAN. LOAN is a manual loan the user keeps by hand: its balance is negative (money owed) and derived from its terms and matched payments. A BANK account whose institution is \"Manual accounts\" is filled from statement files the user imports; its balance is the last one verified plus the rows since. An INVESTMENT account with that institution holds positions the user entered, valued daily from end-of-day prices."
  2. Changed1 schema field changed
    • changedOutput schema / properties / accounts / items / properties / category / description
      Previous value: -"One of BANK, INVESTMENT, DEPOSIT, LOC, LOAN. LOAN is a manual loan the user keeps by hand: its balance is negative (money owed) and derived from its terms and matched payments."New value: +"One of BANK, INVESTMENT, DEPOSIT, LOC, LOAN. LOAN is a manual loan the user keeps by hand: its balance is negative (money owed) and derived from its terms and matched payments. A BANK account whose institution is \"Manual accounts\" is filled from statement files the user imports; its balance is the last one verified plus the rows since."
  3. Changed1 schema field changed
    • changedOutput schema / properties / accounts / items / properties / loan / properties / paying_financial_account_id / description
      Previous value: -"The bank account whose payments drive the loan; absent in schedule mode."New value: +"The bank account whose payments drive the loan; absent in schedule mode and when that account is not shared with this app."
  4. Changed3 schema fields changed
    • changedInput schema / properties / account_category / enum
      Previous value: -[
      -  "BANK",
      -  "INVESTMENT",
      -  "DEPOSIT",
      -  "LOC"
      -]New value: +[
      +  "BANK",
      +  "INVESTMENT",
      +  "DEPOSIT",
      +  "LOC",
      +  "LOAN"
      +]
    • changedOutput schema / properties / accounts / items / properties / category / description
      Previous value: -"One of BANK, INVESTMENT, DEPOSIT, LOC."New value: +"One of BANK, INVESTMENT, DEPOSIT, LOC, LOAN. LOAN is a manual loan the user keeps by hand: its balance is negative (money owed) and derived from its terms and matched payments."
    • addedOutput schema / properties / accounts / items / properties / loan
      Added value: +{
      +  "description": "Manual loan accounts only (category LOAN).",
      +  "properties": {
      +    "balance_verified_at": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "current_rate": {
      +      "description": "Annual interest rate in percent.",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "expected_payment_day": {
      +      "type": [
      +        "integer",
      +        "null"
      +      ]
      +    },
      +    "fee_per_payment": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "kind": {
      +      "description": "MORTGAGE, STUDENT, AUTO, PERSONAL or OTHER.",
      +      "type": "string"
      +    },
      +    "last_regular_payment_amount": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "months_remaining_estimate": {
      +      "description": "Rough months until paid off; null when unknown.",
      +      "type": [
      +        "integer",
      +        "null"
      +      ]
      +    },
      +    "paying_financial_account_id": {
      +      "description": "The bank account whose payments drive the loan; absent in schedule mode.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "payment_change": {
      +      "description": "A payment whose amount changed on cycle, awaiting the user to confirm whether the rate changed.",
      +      "type": [
      +        "object",
      +        "null"
      +      ]
      +    },
      +    "schedule": {
      +      "properties": {
      +        "amount": {
      +          "type": "number"
      +        },
      +        "day_of_month": {
      +          "type": "integer"
      +        }
      +      },
      +      "type": [
      +        "object",
      +        "null"
      +      ]
      +    }
      +  },
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  5. Changed3 schema fields changed
    • changedOutput schema / properties / accounts / items / properties / earliest_available_date / description
      Previous value: -"Start of the synced history (YYYY-MM-DD); windows before it were never synced."New value: +"Start of the synced history (YYYY-MM-DD); windows before it were never synced. Absent only when nothing has been synced for the account yet."
    • changedOutput schema / properties / accounts / items / properties / health / description
      Previous value: -"HEALTHY, FAILING or DEAD in the lean shape; the full health record in verbose records."New value: +"HEALTHY, FAILING or DEAD in the lean shape, or INACTIVE when the account is not live (switched off, or on a switched-off connection); the full health record in verbose records."
    • addedOutput schema / properties / accounts / items / properties / live
      Added value: +{
      +  "description": "False when the account or its connection is switched off; its data is then frozen at the last sync.",
      +  "type": "boolean"
      +}
  6. Changed1 schema field changed
    • addedOutput schema / properties / accounts / items / properties / balance / properties / currency
      Added value: +{
      +  "description": "Currency of these figures. A multi-currency account (currency XXX) holds one balance per currency; this is the one reported.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  7. Changed1 schema field changed
    • addedOutput schema / properties / accounts / items / properties / total_balance
      Added value: +{
      +  "description": "Broker-reported total account value (positions + cash); investment accounts only.",
      +  "properties": {
      +    "amount": {
      +      "type": [
      +        "string",
      +        "number"
      +      ]
      +    },
      +    "currency": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  8. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavioral context well beyond them: balance lag versus transactions with a balance.as_of timestamp, the meaning of earliest_available_date as synced-history start that shifts backward as backfill arrives and is absent when nothing is synced, INACTIVE health semantics for switched-off accounts, and the fact that sensitive identifiers are omitted.

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

Conciseness4/5

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

The purpose is front-loaded and the warnings are grouped behind explicit IMPORTANT markers, so an agent can scan for the critical constraints. It is still long, with the earliest_available_date explanation spread over three sentences and some re-statement of fields the output schema already defines, so it is not maximally tight.

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?

For a two-parameter read tool with an output schema, this covers everything an agent needs to interpret results responsibly: staleness caveats, coverage-window traps when reporting totals, frozen accounts, and the empty-balance quirk for investment/crypto accounts with the pointer to total_balance, cash_balance and list_holdings. No material gap remains.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already documented in structured form; the description only restates that verbose:true returns the full record and never mentions account_category at all. Baseline 3 applies since the schema, not the description, carries parameter meaning.

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 first sentence states a specific verb and resource ('List the user's connected financial accounts') and immediately enumerates the categories covered (bank, investment, crypto). It also implicitly separates itself from siblings by directing position-level data to list_holdings rather than folding it into this tool.

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

Usage Guidelines4/5

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

It gives clear routing guidance in-context: use list_holdings for positions behind investment/crypto accounts, and use verbose:true when the full record is needed instead of the lean summary. It does not explicitly contrast with get_account_balance or list_connections, so the when-not guidance against those siblings is left to inference.

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