Loading ToolBench
An MCP server for tracking and managing expense entries with database persistence
ExpenseTracker has acceptable naming and schemas but falls short on description quality and lacks sophisticated error handling. All three tools are explicitly registered with input schemas and docstrings, but descriptions are minimal (10-20 chars) and parameter annotations lack actionable context. The tool interface is reasonably clean but does not follow LLM-optimized description patterns. No output schemas are documented, parameter constraints lack detail, and error handling is generic. The server is functional but would not pass code review for production agent use.
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 (10 - 35 chars) and lack actionable context. 'Add a new expense entry to the database' does not tell the LLM when to call this vs. other tools, what it returns, or what prerequisites exist. Minimum viable description should be 50 - 100 chars explaining WHAT, WHEN, and WHAT IT RETURNS.
Parameter descriptions lack constraint details. 'date' and 'start_date'/'end_date' are string parameters with no format guidance (ISO 8601 expected?). 'category' and 'amount' lack enums or range constraints. LLMs will guess formats and pass invalid values.
No output schema documented. list_expenses and summarize return structured lists but there is no formal schema definition. LLMs cannot reliably parse or chain results without knowing expected fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Error handling is generic ('Database error: ...') with no recovery guidance. Pattern rule requires errors to tell the LLM what to do next: retryable? user-fixable? fatal? Current responses offer no such classification.
'category' parameter in summarize has a default of null (via JSON Schema but not explicit in function signature). This is inconsistent and may confuse LLMs about whether the field is optional. Default should be documented or removed.
No pagination support on list_expenses and summarize. If expense database grows large, returning all rows will blow context windows. No limit parameter, no offset/cursor, no total count in response.
Date parameters ('date', 'start_date', 'end_date') are simple strings with no format validation. No guidance on whether to use YYYY-MM-DD, MM/DD/YYYY, or Unix timestamps. LLMs will hallucinate formats.
No input validation before database operations. If an LLM passes an invalid date format or a negative amount, the tool silently fails or returns a database error. Should validate early and return actionable error messages.
add_expense modifies state (WRITE risk) but has no idempotency guarantee or confirmation step. If an LLM retries after an ambiguous failure, it will create duplicate expense entries. Should either be idempotent (e.g. via upsert by date+category) or support a dry-run.