Loading ToolBench
Remote MCP servers with expense tracking and calculator functionality
This server contains 5 tools across two separate FastMCP apps (main.py and main1.py). While basic input schemas are present, the definitions suffer from multiple critical gaps: incomplete parameter descriptions, poor naming conventions, missing output schema documentation, and minimal error handling. Tool descriptions are present but lack LLM-optimization guidance. The server mixes two unrelated domains (expense tracking and math utilities) without a clear narrative. Of the 5 tools, the expense tools (add_expense, list_expenses, summarize) have reasonable names and structure, but the math tools (add, random_number) have generic names. Parameter descriptions are inconsistent in quality, and no tool includes documented return schemas. No tool provides recovery guidance in error cases. Per-tool scores range from 35 - 55, averaging 42.
Add two numbers together Args: a: First number b: Second number Returns: The sum of a and b
Add a new expense entry to the database.
List expense entries within an inclusive date range.
Generate a random number between a range Args: min_value: Minimum value (default:1) max_value: Maximum value (default:100) Returns: A random integer between min_value and max_value
Summarize expenses by category within an inclusive date range.
Generic tool names 'add' and 'random_number' lack verb-object structure and clarity. 'add' does not convey domain (math operation vs. database insert). LLM cannot distinguish between add_expense and add without explicit descriptions. Recommendation: rename to 'add_numbers' or 'calculate_sum' and 'generate_random_integer'.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract fields reliably. add_expense returns {status, id, message} but this is not declared in the tool definition. list_expenses returns an array of objects with fields [id, date, amount, category, subcategory, note], undocumented, forcing the LLM to infer structure. summarize returns [category, total_amount, count], also undocumented. add and random_number return bare integers with no explanation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Parameter descriptions are minimal or inconsistent. 'date' in add_expense lacks format guidance (ISO 8601? YYYY-MM-DD?). 'category' in summarize has description 'Optional category filter' but the parameter is not marked optional in the schema (default: null is present, but unclear if null means omitted or the string 'null'). 'min_val' and 'max_val' in random_number have generic descriptions with no range bounds documented.
Error responses are generic and non-actionable. add_expense returns {status: 'error', message: 'Database error: ...'} with raw exception text. No guidance for the LLM on whether to retry, ask the user, or abort. list_expenses and summarize return the same non-actionable error. No recovery hints provided.
No pagination or result limits on list_expenses or summarize. list_expenses returns all matching records without limit. If the database contains 10,000 expense records matching the date range, the response will be enormous, wasting tokens and degrading LLM reasoning. Recommendation: add 'limit' and 'offset' parameters, document a 50-item default cap in the description, and return a total_count or next_cursor for pagination.
Resource endpoints (expense:///categories, info://server) lack mime_type declarations in main1.py. Categories resource in main.py correctly declares mime_type='application/json', but server_info resource in main1.py does not. Inconsistent practice.
Two separate FastMCP apps (main.py and main1.py) are defined but only one can run on port 8000 at a time. The 'if __name__ == "__main__"' block in main1.py would conflict with main.py. This is an architecture issue, should consolidate into a single server or use a dispatcher. Unclear which app is actually deployed.