Loading ToolBench
An MCP server for managing and tracking expenses with a SQLite database backend
The server provides 3 well-structured tools with complete input schemas and reasonable descriptions. All tools have verb-noun naming (add_expense, list_expenses, summarize) which is correct. Schemas are properly typed with JSON Schema format. However, descriptions are brief (34-66 characters), falling short of the 50-200 character production baseline. Parameter descriptions are minimal but present. Output schema is not explicitly documented. Error handling is absent, no guidance on what to do when operations fail. No parameter validation hints (date formats, amount ranges). No security measures documented despite write operations (add_expense).
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.
Descriptions are below production baseline (34-66 chars vs 50-200 target). add_expense description 'Add a new expense entry to the database.' lacks context on when to use it, what fields are required, and side effects of the write operation.
Output schemas are not documented. LLMs cannot plan downstream tool calls or know what fields to expect. For example, add_expense returns {status, id}, but list_expenses and summarize responses are inferred from code, not explicitly specified.
No error handling or recovery guidance. If add_expense fails (invalid date format, negative amount), there is no message telling the LLM what to do. No input validation hints (e.g., date format 'YYYY-MM-DD', amount > 0).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Date parameters lack format specification. Descriptions say 'The date of the expense' and 'The start date for the range' but do not specify expected format (ISO 8601? Unix timestamp? Natural language?). LLMs will guess and pass malformed values.
No parameter validation constraints. amount parameter accepts any number, no minimum (must be > 0?), no maximum. LLMs could pass negative amounts or absurdly large values.
category parameter in add_expense and summarize has no enum constraint. No guidance on what values are valid. subcategory is optional with default '', but no explanation of valid values or relationship to category.
No idempotency guidance. add_expense writes to database on every call, if an LLM retries after a transient error, a duplicate expense is inserted. No confirmation step or dry-run capability for destructive writes.
summarize tool has 'category' parameter marked as optional with default=null, but description says 'Optional category filter'. The JSON Schema shows default: null but does not use 'required' field to clarify optionality. Ambiguous to LLM.