Loading ToolBench
MCP server for personal finance data access with OAuth-protected tools for spending analysis, budgeting, transaction search, and financial reporting
Server defines 13 financial analytics tools with consistent parameter schemas and descriptions. All tools are READ_ONLY with proper annotations. However, descriptions are terse (avg ~80 chars, below 194-char baseline), lack WHEN-to-use guidance, and parameter descriptions are minimal. Output schemas are not documented in the source. Tools share identical parameter sets (start_date, end_date, currency, query, category_id, account_id, pending, limit, cursor, previous_start_date, previous_end_date, report_type), suggesting potential over-parameterization and unclear differentiation. Error handling is present but generic ('FORBIDDEN' check). No evidence of recovery guidance or actionable error messages.
Compare deterministic financial metrics for two same-currency periods.
Bounded transaction review signals. These do not establish fraud.
Monthly category limits, usage and pace for the month containing end_date.
Qualified income minus consumption spending. Not a bank-balance reconciliation.
Net settled spending grouped by category for a bounded period.
Institution sync freshness, history coverage and reconciliation status.
Structured financial report including balances, merchant summaries, anomaly details and coverage.
All 13 tools share identical parameter schemas (start_date, end_date, currency, query, category_id, account_id, pending, limit, cursor, previous_start_date, previous_end_date, report_type). This over-parameterization obscures tool differentiation and forces LLMs to reason about which optional filters apply to each tool. Most tools likely need only start_date, end_date, and currency.
Tool descriptions are terse (avg ~80 chars vs 194-char baseline) and lack WHEN-to-use guidance. E.g., 'High-level income, spending, budgets and recurring costs' does not explain when to call get_financial_snapshot vs get_spending_summary vs get_financial_report. LLMs cannot disambiguate.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
High-level income, spending, budgets and recurring costs. No transaction detail or account balances.
Net settled spending grouped by merchant for a bounded period.
Known asset and liability balances with observation timestamps. No FX conversion.
Detected recurring bills with observed prices and estimated monthly equivalents.
Settled consumption spending with refunds netted. Transfers excluded; pending reported separately.
Search a maximum of 100 transactions. Use only when transaction-level detail is needed.
Output schemas are not documented in the source code. The switch statement in server.ts shows data assembly (e.g., metrics.spending, metrics.budget, metrics.recurring) but no explicit schema definitions or return type documentation. LLMs cannot plan downstream tool calls or extract fields reliably.
Error handling is minimal. Only a generic 'FORBIDDEN' check for auth; no guidance on retryability, user-fixable errors, or recovery steps. Errors like invalid date ranges or currency mismatches are not documented.
Parameter descriptions are minimal or absent. E.g., 'query' is described as 'Optional search query, max 100 characters' but does not explain what fields it searches (merchant name? category? description?). 'report_type' enum has no description of weekly vs monthly semantics.