Loading ToolBench
MCP server providing currency exchange rate lookup and historical rate details
This is a mediocre server with significant definition quality gaps. All three tools have schemas with proper JSON structure and explicit registration, but descriptions lack critical guidance for LLM selection and parameter usage is minimal. Tool names follow verb_noun convention but descriptions are too generic and fail to explain WHEN to use each tool or dependencies between them. No parameter descriptions exist for the 'symbol' and 'date' fields beyond type names. Output schemas are undocumented, the LLM cannot predict what fields will be returned, breaking tool chaining. Error handling is present but provides no recovery guidance. The server reads only from public APIs with no side effects, but lacks the structure and clarity production tools require.
Returns the current currency exchange rate details of a currency. This tool should be used after using the list_all_currencies tool.
Returns the current currency exchange rate details of a currency on a particular date. This tool should be used after using the list_all_currencies tool to retrieve rate for a particular date.
Lists currencies of all countries and currency codes This tool should be used first to actual currency code before calling get_currency_rate_details tool.
All tools lack output schema documentation. LLM cannot predict return structure (field names, types, nested objects). Breaks downstream tool chaining and forces the LLM to probe responses empirically.
Parameter descriptions are missing or trivial. 'symbol' is described as 'The symbol of the currency to get the exchange rate for' but lacks format guidance (uppercase? lowercase?), enumeration of valid symbols, or reference to list_all_currencies. 'date' parameter has no validation note (YYYY-MM-DD required) in the description itself, only in instruction text that LLMs often ignore.
Tool descriptions contain dependency hints as prose ('This tool should be used first', 'This tool should be used after') rather than in structured form. LLMs interpret these as suggestions, not hard requirements, leading to out-of-order calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
'list_all_currencies' description contains a typo ('to actual currency code before calling') and does not explicitly state its purpose is discovery/enumeration. Description is 125 chars and misses critical patterns: it doesn't explain WHEN to call it (before any rate query), WHAT it returns (structure of the result), or HOW to use the output.
'get_currency_rate_details_for_date' uses 'details_for_date' naming which is ambiguous, it does not clearly distinguish it from 'get_currency_rate_details'. A clearer name would be 'get_currency_rate_by_date' or 'get_historical_exchange_rate'. LLM may conflate the two.
No enum or pattern constraint on 'symbol' parameter. The tool accepts any string; the API silently returns errors for invalid symbols. LLM should be guided to call list_all_currencies first, but this is not enforced or validated in the tool itself.