Loading ToolBench
Currency conversion and personal expense auditing MCP server that reads transaction data from local files and provides real-time exchange rates
The server defines 2 tools with reasonable naming and basic descriptions, but falls short on several critical quality dimensions. Tool names (read_spending_data, get_exchange_rate) start with action verbs and are reasonably clear. However, parameter descriptions lack format constraints (e.g., month format is mentioned as 'YYYY-MM' in agent instructions but not in the parameter schema), error handling is minimal, and output schemas are not formally documented. The read_spending_data tool accepts optional filters but lacks guidance on what happens when both filters are provided. The get_exchange_rate tool calls an external API but provides no timeout documentation, rate-limit guidance, or pagination info. Both tools return bare error objects without recovery guidance. Parameter types are present (string, with defaults), which is better than many community servers, but descriptions are quite thin (e.g., 'The currency to convert from (e.g., "USD").' lacks constraint on valid ISO 4217 codes).
Use this to get current exchange rate.
Reads transaction data from the local monthly_spending.json file.
Parameter descriptions lack format constraints and validation rules. 'month' is documented as 'Optional filter by month (e.g., '2026-01' or '2026-02')' but the schema description does not formally specify the YYYY-MM format requirement or reject invalid dates. 'currency_from' and 'currency_to' lack any mention of ISO 4217 code requirements.
Output schemas are not documented in tool definitions. The code returns structured responses (e.g., {'count': ..., 'transactions': ..., 'currency': ...} for read_spending_data and {rates, date, ...} for get_exchange_rate), but the tool descriptions do not explicitly state what fields the response contains, their types, or whether additional fields may appear. LLMs cannot reliably extract and chain these responses without documented schemas.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 8 | - | v1 |
Error handling lacks recovery guidance. Both tools return bare error objects (e.g., {'error': 'Spending file not found on local server.'} or {'error': 'API request failed: ...'}) without actionable next steps. Per pattern:recovery-guide, errors must guide the LLM: 'File not found, ensure monthly_spending.json exists in the server directory, or call setup_spending_file() to initialize it.'
No pagination or result limits documented. read_spending_data can return unbounded transaction lists, if a user has years of data, the response could exhaust context. The tool description should cap results (e.g., 'Returns up to 100 most recent transactions; use month/category filters to narrow results') and guide pagination.
No timeout or rate-limit documentation for external API call. get_exchange_rate calls https://api.frankfurter.app with no explicit timeout, retry logic, or rate-limit headers. If the API hangs, the agent blocks. No documentation states whether the tool respects backoff-retry or has built-in jitter.
Parameter relationships undocumented. read_spending_data accepts both category and month filters. The description does not state whether they are combined (AND) or alternatives (OR), or what happens if neither is provided (return all transactions?). Per pattern:tool-description, undocumented parameter relationships cause silent misuse.
Tool descriptions are below baseline length and lack context for selection. 'Reads transaction data from the local monthly_spending.json file.' (59 chars) and 'Use this to get current exchange rate.' (37 chars) are too brief. Baselines show average tool descriptions are 194 chars. LLMs need WHEN to use the tool (e.g., 'Call this to retrieve a user's spending for a specific month to analyze budget trends or compare across periods') and any prerequisites.