Loading ToolBench
An MCP server for managing and tracking expenses with SQLite database backend
The server has 3 tools with reasonable naming conventions and functional schemas, but descriptions are sparse and lack LLM optimization. Tool names follow verb_noun pattern (add_expense, list_expenses, summarize) which is good. However, descriptions are terse (13-26 chars for tool level, not reaching 50-200 char LLM-optimized range). Parameter descriptions are minimal, amount and category lack detail on format/constraints. No output schema documentation, no error handling guidance, no pagination support despite list_expenses returning potentially large result sets. Security considerations for data persistence are present but undocumented.
Add a new expense entry to the database. If date is not provided, it defaults to current IST date.
List all expenses between start_date and end_date.
Summarize all expenses by category within an inclusive date range. If category is not provided, summarize all categories.
Tool descriptions are too short and lack LLM-optimization context. 'Add a new expense entry to the database. If date is not provided, it defaults to current IST date.' (84 chars) should explain WHEN to use it, WHAT it modifies (state mutation), and prerequisites. Descriptions should be 50-200 chars with actionable detail.
add_expense parameter descriptions lack constraint details. 'The expense amount' does not specify: numeric range, precision (cents?), currency, minimum/maximum allowed. 'The expense category' lacks enum of valid categories or reference to the categories resource. This forces LLMs to guess valid inputs.
No output schema documentation. add_expense returns {status, id} but this is inferred from code, not documented for the LLM. list_expenses and summarize return list/dict structures with no documented field definitions, field types, or nested object descriptions. LLMs cannot plan downstream calls without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
list_expenses lacks pagination support. Querying all expenses between two dates could return hundreds or thousands of records, exhausting context window. No limit parameter, no offset/cursor, no total count returned. Pattern requires pagination for list tools.
No error handling or recovery guidance. Tool code has no input validation; invalid dates, negative amounts, or missing required fields could cause silent failures or 500 errors. No mechanism to tell LLM what went wrong or how to retry. Pattern requires categorized errors with actionable recovery steps.
Date parameter format is undocumented. add_expense accepts 'date: str | None' with default to 'DD-MM-YYYY' format, but no description specifies this format. list_expenses and summarize accept start_date and end_date with no format guidance. LLMs will guess and pass wrong formats (ISO 8601, Unix timestamp, etc.), causing silent failures.
No distinction between required and optional parameters in descriptions. add_expense and summarize have optional parameters (subcategory, note, category) with defaults, but descriptions do not explain the implications of omission. LLMs cannot infer when to pass them.
add_expense performs a state mutation (INSERT) but no description warns the LLM that this is irreversible or idempotent behavior. No dry-run or confirmation step. If an LLM accidentally calls this twice, duplicate expenses are created silently.
Response fields from list_expenses and summarize are not guaranteed to match input parameter names. If future tools expect 'category_name' but list_expenses returns 'category', LLM chains break. No documented chaining IDs or related fields returned.