Loading ToolBench
A Model Context Protocol server for managing personal finances including expenses, income, and budgets with SQLite storage.
The Expense Tracker MCP has well-structured tool names following verb_noun conventions (add_expense, list_income, summarize, financial_summary). All 8 tools are properly registered with input schemas and descriptions. However, several definition quality gaps prevent a higher score: (1) Parameter descriptions lack constraint details (e.g., date format, numeric ranges, category allowlist); (2) Output schemas are not formally documented, tool implementations return dicts but the schema structure is inferred from code rather than declared; (3) Error handling is minimal, no recovery guidance for invalid inputs like malformed dates or negative amounts; (4) The server lacks parameter validation warnings in descriptions (e.g., 'amount must be > 0', 'date must be valid YYYY-MM-DD'). Tool names are clear and verb-first (add_, list_, summarize, financial_summary), which is good. Descriptions are present and action-oriented (10 tools × 8 tools avg ~100-150 chars each), meeting the 10-1024 char baseline. However, descriptions do not explain WHEN to use each tool (e.g., when to call summarize vs financial_summary) or dependencies (e.g., 'Call list_expenses first to discover available dates before filtering'). Parameter descriptions are generic ('Amount spent', 'Date in YYYY-MM-DD format') without enforcement details.
Add a single expense entry to the database.
Add an income entry to track earnings.
Add multiple expense entries at once.
Add multiple income entries at once.
Get a comprehensive financial summary showing income, expenses, and balance.
List expense entries within an inclusive date range.
List income entries within an inclusive date range.
Output schemas not documented. Tool implementations return dicts (e.g., list_expenses returns [{id, date, amount, category, subcategory, note}]) but the schema is inferred from code, not formally declared in tool metadata. LLMs cannot reliably plan downstream operations or validate response structure.
Parameter descriptions lack constraint details. 'amount' accepts any float without bounds (negative, zero, or million-dollar values all pass silently). 'date' is described as 'YYYY-MM-DD' but no validation hint or example provided. 'category' is free-form string with no enum or allowlist.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Summarize expenses by category within an inclusive date range.
No error recovery guidance. When add_expense fails (e.g., invalid date format, negative amount, or duplicate entry), there is no error message or actionable recovery hint. The server returns {'status': 'success', 'id': ...} on success but offers no explicit failure path or validation hints.
Ambiguous tool distinction. 'add_expense' vs 'add_multiple_expenses' and 'add_income' vs 'add_multiple_income' suggest the LLM must decide between single and batch variants. Batch tools should be the primary interface; single-item tools reduce duplication. The trade-off is not documented.
Missing distinguishing documentation for similar tools. 'summarize' and 'financial_summary' both aggregate financial data over a date range. The description does not explain when to use summarize (expenses by category) vs financial_summary (complete income/expense/balance view). An LLM may waste a call choosing the wrong one.
No pagination support. 'list_expenses' and 'list_income' accept only a date range; they will return ALL matching records. For users with years of history, a single call could return thousands of rows, exhausting context. Pagination (limit, offset, cursor) is not offered.
No idempotency semantics. 'add_expense' returns the inserted ID on success but offers no way to check if the exact same expense was already recorded (e.g., duplicate protection). Agents retrying on network failures risk creating duplicate entries.
No dry-run or confirmation for destructive operations. The codebase includes a 'budgets' table but no budget tools are exposed. More fundamentally, write tools like 'add_expense' do not offer a preview or confirmation step. An agent could mass-add incorrect expenses without warning.