Loading ToolBench
MCP server for managing expense tracking with database operations
ExpenseTracker has 3 tools with adequate naming and schemas, but descriptions are minimal and lack LLM-optimized guidance. All tools have input schemas with types and descriptions, which is a strength. However, parameter descriptions are generic (e.g., 'Date of the expense' without format specification), and tool descriptions lack context about when to use them vs. alternatives. Error handling exists but returns generic messages that don't guide recovery. No output schema documentation. The naming follows verb_noun pattern (add_, list_, summarize) which is correct. Parameter names are clear but lack detail about expected formats (dates should specify ISO 8601). Overall, this is a functional but C-grade implementation that could reach B with better description depth and output documentation.
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 lack LLM-optimized context. Descriptions are 15-33 chars, well below the 50-200 char baseline. 'Add a new expense entry to the database' tells WHAT but not WHEN to use it or what it returns. Missing dependency hints (e.g., 'Returns the expense ID needed for list_expenses').
Date parameters lack format specification. Descriptions say 'Date of the expense' but don't specify ISO 8601 (YYYY-MM-DD) or other format. LLMs frequently generate invalid date strings without explicit format constraints in descriptions.
Output schemas are not documented. Tools return structured responses (dict with 'status', 'id', 'message' for add_expense; list of dicts for list_expenses/summarize), but the MCP schema does not declare these return types. LLMs cannot plan downstream calls without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Error handling is generic and non-actionable. Errors return 'Database error: {str(e)}' without guiding the LLM to recovery steps. No categorization of errors as retryable, user-fixable, or fatal.
No pagination support on list_expenses. The tool accepts any date range and returns all matching expenses without limit. A wide date range could return 10,000+ records, exhausting context windows. Should include limit and offset/cursor parameters with reasonable defaults (e.g., limit=50).
subcategory and note parameters have vague descriptions. 'Subcategory of the expense (optional)' doesn't explain what values are allowed or when to use it. 'Note about the expense (optional)' is generic. These lack the detail required for LLM parameter selection.
summarize's category parameter default is null but description says 'Optional category filter' without clarifying that null/omission returns all categories. Behavior on null is ambiguous.