Loading ToolBench
A local MCP server suite for crypto trading, portfolio tracking, and LLM reasoning with multiple specialized microservices (CCXT, CoinGecko, Freqtrade, TA, Portfolio, LLM integration, etc.)
The Crypto MCP Server exhibits pervasive quality issues across the 24 tools. Most tools have basic descriptions (50-150 chars), but many lack depth in parameter documentation. Input schemas are partially visible but inconsistent. Three tool names are duplicated ('ping' appears 3 times across ccxt_mcp, coingecko_mcp, freqtrade_mcp), violating naming uniqueness. Schemas show type declarations for most parameters, but validation constraints (enums, min/max) are largely absent. Error handling descriptions are missing entirely. The server groups 24 tools across three internal MCP sub-servers (ccxt, coingecko, freqtrade) but lacks clear composition documentation. High-risk tools (create_order, execute_approved_order) have descriptions but lack explicit dry-run guidance and idempotency declarations. Output schemas are not documented anywhere in the visible code.
Cancel an existing order
Fetch detailed information about a coin
Creates an order. IMPORTANT: This does NOT execute immediately. It sends a pending request to the dashboard for human approval.
Internal tool called by the backend to actually execute the order after human approval.
Fetch account balance from an exchange
Fetch OHLCV candlestick data for a given symbol and timeframe
Duplicate tool names: 'ping' appears 3 times across different sub-servers (ccxt_mcp, coingecko_mcp, freqtrade_mcp). LLMs cannot disambiguate which ping to call. Violates naming uniqueness requirement.
No output schemas documented. The evaluation cannot verify what fields tools return, making it impossible for LLMs to plan downstream calls or extract the right data. Critical for chainability.
High-risk tools (create_order, execute_approved_order) lack explicit error handling guidance and recovery instructions. Descriptions do not clarify what happens if approval times out or fails, or what fields the approval_token response contains.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Fetch list of open orders from an exchange
Fetch the order book (L2) for a given symbol.
Fetch the list of recent trades for a given symbol.
Fetch the list of coin markets sorted by market cap.
Fetch ticker data for a given symbol from an exchange
List available strategies in Freqtrade
Logs the AI's reasoning for a specific pending trade or general market observation. Must be called BEFORE executing a trade or immediately after a dry_run.
Fetch market chart data for a coin
ccxt_mcp alive — Crypto MCP Server (Corax CoLAB - The Future of Edge AI & Blockchain)
coingecko_mcp alive — Crypto MCP Server (Corax CoLAB - The Future of Edge AI & Blockchain)
freqtrade_mcp alive (rest={FREQTRADE_REST_URL}) — Crypto MCP Server (Corax CoLAB - The Future of Edge AI & Blockchain)
Fetch price data for a coin
Reload the Freqtrade configuration
Start the Freqtrade bot
Get the status of the Freqtrade bot
Stop the Freqtrade bot
Fetch list of trades from Freqtrade
Fetch trending coins from CoinGecko
create_order and execute_approved_order descriptions do not declare the tools as IRREVERSIBLE or WRITE operations. LLMs cannot determine whether they are safe to retry without explicit risk annotation.
Parameter descriptions lack explicit constraints. For example, 'exchange' parameter does not list valid exchange names (binance, kraken, etc.). 'symbol' does not clarify format (e.g., 'BTC/USDT' vs 'BTCUSDT'). LLMs will hallucinate invalid values.
'price' and 'coin_info' parameters lack descriptions clarifying what constitutes a valid CoinGecko coin ID. The description says 'e.g., bitcoin' but does not state whether 'Bitcoin', 'BTC', or system IDs are accepted.
No pagination documentation for list-like tools (get_coins_markets, list_strategies, trades, fetch_trades). No mention of limit/offset, max results, or whether results are capped. Large result sets risk blowing the context window.
No idempotency declaration on write operations (create_order, execute_approved_order, start_bot, stop_bot, reload_config). Agents retrying on network failure may duplicate orders or restart the bot twice.
Tool 'log_reasoning' requires a 'trade_id' but no tool visible returns a trade_id. No documented way to obtain one. LLMs cannot call this tool without extra discovery.
Descriptions for 'optional' parameters (symbol in cancel_order, price in create_order) do not clarify consequences of omission. What happens if symbol is omitted in cancel_order? Does the tool fail or cancel all orders?