Loading ToolBench
MCP server for Polymarket prediction markets integration with Claude Desktop
This server demonstrates solid foundational quality with well-structured tool definitions, clear naming conventions, and comprehensive parameter schemas. All 8 tools follow the verb_noun pattern (get_*) consistently. Descriptions are present and contextual (ranging 100-180 chars, within the 10-1024 baseline). Parameter schemas are fully typed with JSON Schema constraints including enums, defaults, and descriptions. However, output schemas are not documented, LLMs cannot see what fields will be returned, forcing them to reason blind about downstream chaining. Error handling is implicit in the API layer but not surfaced to the protocol. Tool composition is excellent with minimal overlap, and pagination is properly implemented across all list-returning tools.
Retrieve Polymarket events which contain multiple related markets. Events group markets around a common theme or topic.
Retrieve holders and their positions for a specific market. Shows who owns shares and their holding amounts.
Get current market prices and trading data for specific markets or tokens. Shows bid/ask spreads, last traded prices, and market depth.
Retrieve Polymarket prediction markets with filtering and pagination options. Get market data including prices, volume, liquidity, and metadata.
Retrieve current order book data showing bids and asks for a specific market or token. Shows market depth and liquidity.
Retrieve recent trades and transaction data from Polymarket markets. Shows who traded what at what prices.
Output schemas are not documented. LLMs cannot predict what fields will be returned (e.g., does get_markets return market_id, market_name, last_price, volume, liquidity, etc.?). This forces blind reasoning and prevents tool chaining, the agent doesn't know if the response includes the market_id needed for get_market_prices.
No error handling guidance. The CallToolRequestSchema handler throws 'Unknown tool' for invalid names, but client-facing errors (API failures, rate limits, not-found scenarios) are not documented. LLMs cannot distinguish retryable failures from user errors without explicit error categorization.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | 0.6.0+ | v1 |
Retrieve user activity and transaction history on Polymarket. Shows trades, deposits, withdrawals, and other account activities.
Retrieve a user's current positions in Polymarket markets. Shows what shares they hold and their value.
Parameter validation rules not explicit in descriptions. For example, 'limit' accepts 1-100 but description only states 'default: 20, max: 100', minimum is not stated. 'offset' has no range guidance. 'liquidity_min' and 'volume_min' are numeric but lack units clarity (USDC is mentioned but not enforced). Parameter descriptions should state: 'Minimum liquidity threshold in USDC (0-1000000)'.
Tool composition risk: Tools like get_market_prices and get_order_book both operate on markets but require different parameter combinations (market_id vs token_id vs both). The distinction between a 'market' and a 'token' outcome is not explained. An agent may call the wrong tool or pass the wrong identifier type without clear guidance on when to use each.
Parameter naming inconsistency in sorting. Tools use 'order' for sort field and 'ascending' for direction (get_markets, get_events), but others use 'order_by' and 'order_direction' (get_trades, get_user_activity). This forces LLMs to memorize different APIs for similar operations. Standardize to a single convention across all tools.