Loading ToolBench
An MCP server for tracking and managing expenses with database persistence, category management, and expense summarization.
Server has 3 tools with basic structure but significant quality gaps. Parameters have types but minimal descriptions. No output schemas documented. Error handling returns unstructured messages without recovery guidance. No tool annotations. Naming follows verb_noun convention (good), but parameter naming lacks consistency (start_date/end_date vs date). No pagination support despite list_expenses returning potentially unbounded results. Overall approach is functional but well below production quality.
Add a new expense entry to the database.
List expense entries within an inclusive date range.
Summarize expenses by category within an inclusive date range.
Tool descriptions are critically short (34-64 chars vs 194 char baseline). add_expense: 'Add a new expense entry to the database.' lacks context on required date format, amount constraints, category validation, or when to call this vs alternatives.
Parameter descriptions are minimal or missing. 'date' in add_expense has description 'Date of the expense' but does not specify required format (ISO 8601? MM/DD/YYYY?). 'amount' lacks constraints (min/max? decimal places?). 'category' lacks guidance on valid values or enum constraint.
No output schemas documented. list_expenses and summarize return structured objects (dicts with id/date/amount/category/... and category/total_amount/count), but these are not formally documented in tool descriptions or return type annotations. LLMs cannot plan downstream calls without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
No pagination support. list_expenses accepts start_date and end_date but provides no limit, offset, or page parameters. A user querying a full year of expenses could receive thousands of rows, bloating context window and degrading LLM reasoning.
Error handling does not guide recovery. Error messages like 'Database error: [exception string]' or 'Error listing expenses: [exception string]' are opaque to LLMs.
No input validation or constraint documentation. add_expense accepts amount as a number but does not validate it is positive. date is a string but no format constraint documented. category has no enum of valid options.
No tool annotations for destructiveness or idempotency. add_expense is a WRITE tool but lacks explicit destructiveHint annotation. summarize and list_expenses are READ_ONLY but lack readOnlyHint. Per 2026-07-28 spec, tool annotations enable agents to reason about safety and replay.
Inconsistent parameter naming across tools. add_expense uses 'date' (singular); list_expenses and summarize use 'start_date' and 'end_date' (qualified). This forces LLMs to reason about field mapping when chaining tools.