get_balancesRetrieve current account balances, including cleared funds for net worth and available funds for spending decisions.
Current balances of one account. booked is the cleared balance (use this for net worth); available is what the bank says can be spent, which for credit and mortgage accounts includes the credit line.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | Account uid or label |
Changes observed during successful MCP inspections.
v0.1.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral transparency burden. It adds valuable context by defining booked versus available balances, but it does not disclose potential side effects (it is read-only by nature), authorization requirements, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences efficiently front-load the core purpose and then explain the critical distinction between booked and available balances. There is no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-documented parameter, and the description covers the key return semantics of balances, which is enough to make a correct call. However, without an output schema or annotation support, it could provide more detail on the response structure or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single `account` parameter as 'Account uid or label' (100% coverage). The description adds no new semantic detail about the parameter beyond repeating the 'one account' constraint, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Current balances of one account', which clearly identifies the tool's verb, resource, and scope. It implicitly distinguishes itself from siblings like list_accounts and get_transactions by focusing on balance data for a single account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful usage context, such as 'use this for net worth' for the booked balance and explains what available means for credit/mortgage accounts. However, it does not explicitly say when to prefer this tool over an alternative or mention any prerequisites like a valid consent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.