Loading ToolBench
MCP server for monitoring and managing a Polymarket copy trading bot with real-time trade tracking, position management, and configuration control
PolyCopy has 4 tools with basic verb-noun naming (get_*), but critical gaps undermine quality. All tools lack parameter descriptions, the rubric requires every parameter to have a description explaining what it controls. Tool descriptions are present but minimal (10-40 chars), below the 50-200 char baseline for LLM-optimized descriptions. Input schemas use Zod but lack inline descriptions for parameters. No output schema documentation. No error handling guidance. No tool annotations (readOnlyHint, etc.). The server reads from local JSON files without validation or pagination, risking context window exhaustion on large datasets.
Get current bot status and uptime
Get current bot configuration
Get current tracked positions
Get recent copy trades
All parameter descriptions missing. The 'limit' parameter in get_recent_trades has no description in the tool definition, only in the Zod schema. LLMs cannot read Zod; they need descriptions in the tool metadata.
Tool descriptions are too short (10-40 chars). Baseline is 50-200 chars. 'Get current bot status and uptime' (32 chars) lacks context on when to call this vs other tools, what fields are returned, and whether it reflects real-time state.
No output schema documentation. Tools return JSON text blobs without declaring field names, types, or structure. LLMs cannot plan downstream calls or extract data reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
No pagination or result limits enforced. get_recent_trades defaults to 20 but has no documented max. get_positions returns all positions without limit, risking context window exhaustion on large datasets.
No error handling guidance. If a data file is corrupted or missing, readDbFile silently returns an empty array. No error message tells the LLM what went wrong or how to recover.