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. 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.

Input Schema

TableJSON 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

TableJSON 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
    • 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"
      +  ]
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: balances can lag transactions and should be caveated, earliest_available_date defines synced history coverage, investment/crypto accounts have empty balance blocks requiring different field interpretation, and sensitive identifiers are omitted. This is rich, non-obvious behavior that an agent needs to know.

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 description is dense but well-organized: it front-loads the core purpose, then provides structured caveats with clear markers (IMPORTANT). Every sentence adds information, though the length is substantial. The structure is logical: purpose, output shape, caveats, special-case behavior, parameter note, and security note.

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 tool's complexity (special balance semantics, date coverage caveats, category-specific behavior) and the presence of an output schema, the description is remarkably complete. It covers return value interpretation, edge cases (investment/crypto empty balance blocks), data freshness caveats, and routing to sibling tools. An agent has everything needed to call this correctly and interpret results.

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 schema already documents both parameters (verbose and account_category). The description adds value by explaining the default lean summary and the verbose:true behavior ('returns the full record'), which clarifies the parameter's effect beyond the schema's phrasing. It doesn't add detail on account_category beyond the schema's enum, but the schema already covers that.

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 description states a specific verb ('List') and resource ('the user's connected financial accounts'), enumerates the account types (bank, investment, crypto), and distinguishes the output as a lean summary. It clearly differentiates from siblings like list_holdings and get_account_balance by describing the account-level summary scope.

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?

The description explicitly tells the agent when to use this tool (to list connected accounts and get lean summaries) and when to use alternatives: 'call list_holdings for the positions behind them' for investment/crypto accounts. It also provides critical usage caveats about balance lag and earliest_available_date, which guide correct interpretation of results.

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