Loading ToolBench
MCP server for Polymarket trading integration providing market discovery, analysis, and trading tools
Scoring was not performed
Descriptions are consistently below production baseline (10-40 chars vs 50-200 char target). Examples: 'Get spread for a token' (24 chars), 'Get liquidity information' (26 chars). LLMs cannot reliably distinguish between similar tools with such minimal context.
Input schemas shown in the data are incomplete. Parameters like 'filters' in search_markets are described as 'object' with no sub-field definitions. Parameters lack minLength/maxLength, minValue/maxValue, enum constraints, or pattern definitions that would guide LLM input generation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 26 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
No output schemas are documented anywhere in the source. Tools like get_market_details, get_orderbook, and get_portfolio_value provide no specification of what fields will be returned, forcing LLMs to guess at response structure. This violates the requirement that tools return structured objects with typed fields.
Tools with empty or trivial schemas: get_all_positions, get_portfolio_value, get_portfolio_risk, get_open_orders, cancel_all_orders all have {} input schemas. While acceptable for no-parameter tools, LLMs benefit from explicit documentation that these take no input.
No error handling guidance visible. Tools like cancel_order, create_limit_order, execute_smart_trade (all destructive/write operations) lack descriptions of what can fail and how to recover. LLMs receive no indication whether errors are retryable, require user intervention, or are fatal.
Destructive operations (cancel_order, cancel_market_orders, cancel_all_orders, create_limit_order, execute_smart_trade) have NO confirmation or dry-run capability documented. Agents operating on real trading accounts could execute irreversible trades without a safeguard.
Parameter names are sometimes ambiguous: 'side' appears in get_current_price (BUY, SELL, or BOTH), create_limit_order, create_market_order. The description 'Side (BUY or SELL)' for create_limit_order conflicts with get_current_price's 'Side (BUY, SELL, or BOTH)'. LLMs will struggle to distinguish valid values across tools.
Tools return arrays (e.g., get_trending_markets, filter_markets_by_category, get_order_history) but no pagination or result-limiting guidance is visible in schemas. The 'limit' parameter exists but max value is undocumented. No mention of total_count, next_cursor, or how to handle large result sets.