Loading ToolBench
Servidor MCP de finanzas personales (solo lectura) sobre TrueLayer Data API / PSD2
Server has 9 tools with basic descriptions and some parameter schemas, but significant gaps prevent higher scores. All tools are READ_ONLY and well-intentioned, but descriptions are terse (avg ~50 chars, well below the 194-char baseline), parameter descriptions are minimal, and output schemas are not documented. No error handling guidance, no parameter validation rules, and no recovery hints. Tool naming is acceptable (verb_noun pattern) but lacks clarity on when to use similar tools (e.g., get_transactions vs search_transactions distinction is unclear). No tool annotations (readOnlyHint, etc.) despite all being read-only. This is typical of community servers, functional but not production-grade.
Saldo más reciente de cada cuenta.
Movimientos filtrados por cuenta, fechas (YYYY-MM-DD) y tipo (debit/credit).
Lista las cuentas bancarias sincronizadas.
Cargos recurrentes detectados (suscripciones / domiciliaciones).
Resumen mensual: ingresos, gastos, neto, top comercios y categorías.
Busca movimientos por texto en el comercio o el concepto.
Tool names lack clarity and consistency. 'spend_by_category_tool' and 'monthly_summary_tool' use '_tool' suffix (non-standard); 'unusual_charges' lacks verb prefix. Naming should follow verb_noun pattern consistently (e.g., 'get_spending_by_category', 'get_monthly_summary', 'detect_unusual_charges'). LLMs struggle to distinguish similar tools like get_transactions vs search_transactions without clearer names.
Descriptions are too terse (avg ~50 chars vs 194-char baseline). Examples: 'Lista las cuentas bancarias sincronizadas' (44 chars), 'Saldo más reciente de cada cuenta' (35 chars). Descriptions lack WHEN to use, WHAT it returns, and dependencies. LLMs cannot determine tool selection intent from such brief text. Expand to 100-200 chars explaining use case and output structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Gasto agregado por categoría en un periodo (fechas YYYY-MM-DD).
Estado de la última sincronización.
Cargos atípicos respecto al histórico de cada comercio.
Output schemas are not documented. Code shows tools return dicts (e.g., _tx_dict returns id, account_id, amount, currency, date, description, type, merchant, category), but no schema is visible in tool registration. LLMs cannot plan downstream calls or extract fields without knowing response structure. Document return types in tool definitions.
No error handling guidance. Tools lack descriptions of failure modes, recovery steps, or actionable error messages. E.g., if get_transactions fails due to invalid date format, what should the LLM do? No pattern:recovery-guide implemented. Add error classification (retryable, user-fixable, fatal) and recovery hints.
No tool annotations despite all tools being read-only. FastMCP supports readOnlyHint annotation, which should be applied to all 9 tools to signal safety to agents. This prevents unnecessary confirmation prompts and enables aggressive optimization.