Loading ToolBench
An MCP server for managing and tracking expenses with SQLite database backend. Supports adding, listing, editing, and deleting expense entries, as well as summarizing expenses by category.
The server provides 5 tools with basic but incomplete definitions. All tools have descriptions (10-70 chars), and most have input schemas, but there are significant gaps in parameter descriptions, output schemas, and error handling. Naming is verb-first (good), but parameter and output documentation is minimal. Error handling is present but not actionable, errors return generic messages without guidance on recovery or classification. No documentation of output structure means agents cannot reliably extract data for chaining. Tool composition is reasonable (5 separate concerns), but missing pagination, field limits, and per-request idempotence hints.
Add a new expense entry.
Delete an expense entry by its date (YYYY-MM-DD) and subcategory.
Edit an existing expense entry identified by date and subcategory. Only provide the fields that need updating.
List expense entries within an inclusive date range (YYYY-MM-DD).
Summarize expenses by category within a date range (YYYY-MM-DD).
Output schemas not documented. Tools return dicts or lists but the agent has no schema for what fields to expect. list_expenses returns expense records with id/date/amount/category/subcategory/note, but this structure is invisible to the LLM. Without documented output schemas, agents cannot plan downstream tool calls, extract required IDs, or validate responses.
Error responses are not actionable. All tools return {"status": "error", "message": str(e)} on exception. Generic messages like 'Error listing expenses: ...' do not tell the agent whether the error is retryable, user-fixable, or fatal. Missing date validation, no guidance on recovery. Agents cannot self-correct or escalate intelligently.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
list_expenses and summarize lack pagination/result limits. No limit param, no page/offset, no next_cursor. If a user has 10,000 expenses, list_expenses returns all of them, bloating context and wasting tokens. No documented result limits in descriptions.
Parameter descriptions are too generic. 'Date in YYYY-MM-DD format' is present but missing validation context: Are leap-day dates allowed? Future dates? The past 10 years only? 'amount' has no min/max bounds, can amounts be negative? Zero? Multimillion? This forces agents to guess or retry on validation failures.
delete_expense is destructive but has no confirmation step or dry-run. Agents can permanently erase data with no undo. No mention in description that this operation is irreversible. No error recovery guidance if the wrong date/subcategory combo matches unintended records.
edit_expense uses None defaults but accepts 'amount', 'category', 'note' as optional with default=null. Function signature shows Optional[float]=None but schema shows "default": null. Inconsistency in how optional fields are handled. Also, identifying an expense by (date, subcategory) tuple is fragile, if two expenses have the same subcategory on the same date, both will be updated.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). These hints let MCP clients show UI warnings or reject unsafe operations. add_expense, edit_expense, delete_expense are not marked as destructive/write-heavy. list_expenses and summarize are not marked as read-only. This is a small protocol-readiness gap but hampers client-side safety features.