Loading ToolBench
Professional trading assistant providing real-time market data, technical analysis, and trading recommendations for multiple asset classes. Supports Forex (22+ pairs), Stocks (US equities), and Crypto (BTC, ETH, etc). Includes advanced tools: Volume Profile, Market Profile, VWAP, Fibonacci, Bollinger Bands, MACD, Moving Averages, ATR, Support/Resistance, Pivot Points, Stochastic, ADX, Ichimoku Cloud, and Pine Script v6 development tools.
The server has 6 tools with basic structure, but critical gaps severely limit production readiness. All tools have descriptions (positive), but most descriptions are vague and miss WHEN/WHY guidance. Input schemas exist but lack rigor: no enums for constrained values (e.g., timeframe accepts arbitrary strings, not validated against '5m'|'15m'|'1h'|'4h'|'1d'), no min/max constraints on arrays, no output schemas documented. Parameter descriptions are minimal, 'Symbol (e.g., "EURUSD", "AAPL", "BTC")' tells the LLM what field names exist but not what formats are truly accepted or rejected. The health_check and list tools are well-named and appropriate for discovery. However, get_price and get_multiple_prices are adjacent tools with no clear distinction guidance to the LLM, when should it call one vs. the other? analyze_pair accepts an undocumented default 'timeframe' parameter with no validation. Error handling is absent from visible tool definitions, no recovery guidance, no actionable error messages, no handling of invalid symbols or API failures. The server logs are present but tool output schemas are not documented in the descriptions, forcing LLMs to infer what they'll receive.
Comprehensive technical analysis for any symbol.
Get current prices for multiple symbols at once.
Get current price for any asset (Forex, Stock, or Crypto).
Check server health and API connectivity status.
List all available forex pairs organized by category.
List all supported assets by category.
No output schemas documented. LLMs cannot infer what fields health_check, get_price, get_multiple_prices, analyze_pair return. This forces agents to guess at response structure and risks misuse of returned data.
Timeframe parameter in analyze_pair has no validation. Description says '5m', '15m', '1h', '4h', '1d' but are these the ONLY valid values? Should be declared as enum. Currently LLMs could pass 'invalid', '2h', etc. without knowing if they'll fail.
get_price and get_multiple_prices are adjacent tools with overlapping intent. No guidance in descriptions about when to call one vs. the other. LLM will waste reasoning cycles or make suboptimal choices. Consider consolidating into get_prices with a single_or_multiple strategy, or clarify in descriptions when each applies.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Symbol parameter descriptions include example values ('e.g., "EURUSD", "AAPL", "BTC"'). Per the rubric, LLMs latch onto example values and may treat them as the only valid options or pass them literally in unrelated contexts. Replace with format/enum constraints.
No error handling guidance. Tools do not document what happens when a symbol is invalid, API is down, or rate limits are exceeded. Error responses in the code show format_error_response() is available, but tool descriptions offer no recovery hints to LLMs (e.g., 'If symbol not found, try list_supported_assets() first').
get_multiple_prices array parameter has no min/max bounds. LLMs could pass 1000+ symbols, potentially overwhelming the API or the context window with responses. Should enforce limit and document it (e.g., 'max 50 symbols per call').
Descriptions are too terse (under 100 chars for most tools). 'Get current price for any asset' doesn't explain when to call this instead of list_supported_assets or analyze_pair.