Skip to main content
Glama

Rico MCP

by io.github.mcp-dir

openfinance_get_account_balance

Read-onlyIdempotent

Returns the latest available balance per account id (GET /accounts/:id/balance). This is the freshest balance the provider can serve, but it is a SNAPSHOT anchored to the connection's last upstream sync: the updateDateTime/updatedAt in each row is that sync instant, NOT a to-the-second live read. If a movement that just happened is not reflected yet, or the balance disagrees with the sum of openfinance_list_transactions, run openfinance_force_sync to pull fresh data and then re-read. Pass account_ids as an array (1–50). CREDIT accounts may return Pluggy BALANCE_FETCH_ERROR (provider could not fetch it) or BALANCE_CONSENT_ERROR (the institution refused it because the consent lacks the balance permission — reconnecting the bank restores it) — those rows include a structured warning instead of throwing. When the financial institution is temporarily unavailable upstream (5xx) or the connector is not Open Finance, the row DEGRADES to the last-synced balance with realtime: false, updatedAt and a warning instead of an error. Response shape: { results: [...], errors: [{ id, status, message }] }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_idsYes

TDQS

A4.8/5.0
Behavior5/5

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

Although annotations already declare readOnlyHint, idempotentHint, and destructiveHint, the description adds valuable behavioral detail: balances are snapshots tied to upstream sync, not live reads; rows may degrade with realtime:false; credit accounts may return structured warnings rather than throwing. Nothing contradicts the annotations.

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 long but every sentence earns its place by covering snapshot semantics, sync guidance, error modes, degraded rows, and response shape. It is front-loaded with the core purpose and endpoint before adding edge-case detail.

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 there is no output schema, the description fully compensates by documenting the response shape, error rows, warning behavior, degraded response fields, and the relevant failure modes. An agent has enough information to call this tool correctly and interpret common outcomes.

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 coverage is 0%, so the description must compensate, and it does by specifying that account_ids is an array of 1–50 items. It does not detail the exact string format of each account ID, but the sibling tool context and the endpoint path make the semantics clear enough.

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 begins with a specific verb and resource: 'Returns the latest available balance per account id' and even cites the endpoint. It clearly differentiates this from siblings like openfinance_list_accounts and openfinance_get_accounts_detail by focusing on balance freshness and snapshot semantics.

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?

It explicitly tells the agent when to use this tool and when to switch to openfinance_force_sync, e.g., when a movement is missing or the balance disagrees with the sum of transactions. It also covers error-driven fallback behavior, leaving no ambiguity about when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Rico MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, especially the openfinance_* family, but there is some overlap: openfinance_list_transactions and openfinance_list_transactions_by_item both cover transaction listing (though the latter is aggregated by connection), and openfinance_get_account_balance vs openfinance_list_accounts both return balance info. Descriptions are detailed enough to guide selection, so ambiguity is limited but present.

Naming Consistency4/5

The 19 openfinance_* tools follow a consistent verb_noun pattern (list_accounts, get_balance, force_sync). The remaining generic tools (connect, authenticate, marketplace, report_bug, etc.) don't share the prefix but use clear verb-style names. Two conventions exist, but within each group naming is predictable and readable.

Tool Count3/5

25 tools is at the high end but supports the dual scope: platform management (connect, auth, marketplace) and comprehensive Open Finance data access (19 tools). The count feels slightly heavy, especially with the massive marketplace tool that bundles many actions into one, but it's justified by the breadth of the financial domain.

Completeness4/5

The Open Finance surface is quite complete: accounts, balances, transactions, bills, loans, investments, categories, connections, sync, and provider status are all covered. Missing minor operations like updating categories is present, but there is no obvious gap like missing update/delete for transactions (not applicable). The platform side is minimal but sufficient for auth and info.

Resources