Skip to main content
Glama

Bank balances

get_bank_balances
Read-only

Returns the organisation's bank holdings, ONE line per connected bank (Mercury, Revolut (legacy), Meow, Wise, and one line PER Open Banking connection — an org may hold several banks, each named, with connection_id, per-connection fetched_at staleness and a shared_accounts count for an account two connections serve, rendered once; plus, when a bank needs reconnecting or was removed but still has booked cash, a residual Open Banking line with connection_id null whose name says "(reconnect required)" or "(no live connection)" — that line is NOT a connected bank), as a LIVE-VALUE view: each bank's booked cash balance — summed from its per-currency cash sub-accounts (e.g. Revolut GBP/EUR/USD collapse into a single Revolut total) — converted to the org home currency at TODAY's FX rate. This is the same number the human dashboard's "Bank balances" card shows. It is deliberately DISTINCT from the balance sheet's booked value (each transaction stamped at its own transaction-date rate); the difference is accumulated unrealized FX. The balance source is the booked general ledger (not a live provider API), so it is reproducible from the ledger. Every connected bank is listed including newly-connected zero-balance ones (book_cents 0). A bank whose currency has no available FX rate shows book_cents null (rate unavailable) rather than a misleading zero. Stripe is a payment processor, not a bank — its money is under get_account_balance / clearing, not here. For live provider API balances or Stripe/cash, use get_account_balance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
org_idNoOptional. Defaults to the organisation the authenticated API key is bound to, so you normally omit it and never need to ask the user for their organisation UUID. If provided, it must match the key’s org or the request is rejected.0e91146d-511c-469f-bdee-5c867b26ae0d

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
banksYes
rate_dateYes
home_currencyYes
openbanking_fetched_atYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Even though readOnlyHint=true already signals safety, the description adds substantial behavioral detail: per-currency sub-accounts collapse into one total, conversion uses today's FX rate, zero-balance banks are included, missing FX rates yield null rather than zero, and residual lines with connection_id null are explicitly not connected banks. This goes far beyond the annotation.

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 content is dense and valuable, but the structure is one long run-on paragraph with deeply nested parentheticals, making it harder to parse than it should be. It is appropriately sized for the tool's complexity but would benefit from segmentation into purpose, behavior, and exclusions.

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?

The description covers what the tool returns, how values are computed, how it differs from related reports, edge cases like zero balances and missing FX rates, and explicit routing to the correct sibling. With an output schema present, no return-value detail is missing.

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 the single org_id parameter is already fully documented with its default and rejection behavior. The description does not add parameter-specific semantics, but the schema alone carries the full meaning, so the baseline of 3 applies.

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 opens with a precise verb and resource: 'Returns the organisation's bank holdings, ONE line per connected bank,' and immediately differentiates itself from the balance-sheet view and from get_account_balance by excluding Stripe and live provider APIs. The naming of Mercury, Revolut, Meow, and Wise, plus the residual Open Banking line, leaves no ambiguity about what the tool returns.

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 states when NOT to use this tool: 'For live provider API balances or Stripe/cash, use get_account_balance.' It also contrasts this tool's ledger-based, today-FX value with the balance sheet's transaction-date value, giving an agent clear routing criteria among siblings.

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