Loading ToolBench
MCP server for live market data. Gives AI agents real-time crypto and stock prices, OHLCV candles, order books, and market analysis. Zero API keys needed.
mcp-market-data defines 8 tools with consistent naming (verb_noun), present descriptions, and visible JSON Schema inputs. However, descriptions are generic and lack LLM-specific guidance (e.g., 'when to use', 'prerequisites', examples of output structure). Parameter descriptions are minimal, most are 1-2 sentences without format constraints, ranges, or dependency hints. No output schemas documented. Error handling is present in the code but not surfaced in tool definitions. The tools are READ_ONLY and well-scoped, avoiding multi-action problems, but lack the precision needed for confident LLM selection and chaining. Average tool score is 52; the server lands in the 'Fair/C' band with noticeable gaps in parameter documentation and output schema clarity.
Technical analysis: RSI, SMA, volatility, z-score, trend detection. Requires at least 14 candles.
Get OHLCV candlestick data for any crypto. Returns open, high, low, close for each period.
Compare multiple crypto assets side by side. Shows prices, changes, market caps.
Crypto Fear & Greed Index — 7 days of fear/greed sentiment data.
Get top cryptocurrencies ranked by market cap with prices, volumes, and 24h changes.
Get live order book — top 20 bids and asks with spread. Shows market depth and liquidity.
Get current price, 24h change, volume, market cap for any cryptocurrency. Examples: BTC, ETH, SOL, DOGE.
Output schemas are not documented. LLMs cannot infer return types, forcing manual discovery or trial-and-error. For example, 'price' returns fields like price, change_24h, market_cap, but these are not declared in the tool definition.
Parameter constraints (enum values, ranges, format patterns) are missing from schemas. For example, 'candles' accepts days ∈ {1,7,14,30,90,180,365} but schema declares days as bare 'number' with no constraints. This invites invalid LLM input and requires server-side validation.
Descriptions lack LLM-specific guidance (when to use, prerequisites, decision criteria). For example, 'order_book' doesn't explain when it's preferable to 'price' (e.g., for slippage/liquidity analysis), and 'analyze' lists indicators without explaining their interpretation thresholds.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Get trending cryptocurrencies right now with market cap rank and price in BTC.
Some tool names do not follow verb_noun pattern. 'trending', 'feargreed', 'market_cap' are nouns; clearer names would be 'list_trending', 'get_fear_greed_index', 'list_top_by_market_cap'. This reduces clarity for LLM intent inference.
Error handling is not surfaced in tool definitions. Code includes fallback for missing order_book (Binance API down) and missing Fear & Greed API, but LLMs cannot see these recovery paths. Tool descriptions do not mention what errors might occur or how to recover.
Parameter descriptions are minimal (1-2 sentences). For example, 'symbol' in 'price' is described as 'Crypto symbol (BTC, ETH, SOL, DOGE, etc.)', this is a format hint, not a description of what the parameter controls or its constraints. LLMs need fuller context.