Loading ToolBench
MCP server for expense tracking with calculator and search capabilities
Mixed quality implementation. Tools have clear verb-based naming and functional input schemas, but descriptions lack depth and fail to follow LLM-optimized patterns. All 5 tools have registered schemas with type information, but parameter descriptions are generic and do not explain WHEN to use tools, prerequisite knowledge, or expected outcomes. Output schemas are undocumented, LLMs cannot plan downstream calls. Error handling is minimal (only division-by-zero checked). The calculator and search tools are utility functions with good separation of concerns, but the expense tracker cluster (add_expense, list_expenses, summarize) lacks guidance on date format expectations, pagination strategies, and result limits. Database operations use async safely but provide no constraints or validation feedback to guide LLM input.
Adds a new expense record to the database
Performs basic arithmetic operations (add, subtract, multiply, divide) on two numbers
Searches the web using DuckDuckGo search engine
Lists all expenses within a date range
Summarizes total expenses by category within a date range
Output schemas are not documented. LLM cannot determine what fields to expect from any tool response, blocking downstream chain calls and forcing exploratory calls.
Parameter 'operation' in calculator accepts free-form string; should be enum-constrained to ['add', 'subtract', 'multiply', 'divide'] to prevent LLM hallucination.
Date format expectations undocumented for add_expense, list_expenses, summarize. LLMs will guess between ISO 8601, MM/DD/YYYY, and other formats, causing validation failures.
list_expenses and summarize lack pagination parameters (limit, offset) and result capping. If 500+ expenses exist, response will exhaust context window.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error recovery guidance. Division-by-zero in calculator returns 'Division by zero' (good), but invalid operations return generic 'Invalid operation'. LLM cannot self-correct without seeing enum options.
duckduckgo_search description is 60 characters; baseline is 194 chars. LLM lacks context to determine when to use this vs another search method or how to interpret results.
add_expense is a destructive write operation but has no dry-run, confirmation, or idempotency guidance. Agents may create duplicate expenses on retry.
list_expenses returns array with id, date, amount, category fields, but no guidance on field naming consistency. If downstream tools expect 'expense_id', mismatch breaks chains.