Loading ToolBench
MCP server for accessing Polymarket APIs (Gamma, Data, and CLOB) to retrieve market data, user positions, trades, orderbook information, and manage orders.
The MewCP Polymarket server presents a coherent, well-organized set of 7 read-only tools with consistent naming and reasonable descriptions. All tools follow the verb_noun pattern (polymarket_get_*), have non-empty descriptions (averaging ~110 chars), and include input schemas with types and descriptions. Pagination parameters are present on multi-result tools. However, the server exhibits several significant quality gaps: (1) Output schemas are NOT documented in the tool definitions, only inferred from the code implementation. LLMs cannot reason about return types without explicit documentation. (2) All tools return JSON strings rather than structured objects, forcing LLMs to parse and manually extract fields. (3) Error handling is minimal, generic exceptions logged but not returned with actionable recovery guidance. (4) No tool annotations (readOnlyHint, etc.) despite all being read-only operations. (5) Parameter descriptions lack validation details (e.g., 'Ethereum wallet address' gives no format guidance for input validation). (6) No rate limiting, timeout, or resilience documentation. The tools are functional and well-named, but fall short of production-grade quality due to missing output schemas and limited error guidance.
Get list of events from Polymarket. Events contain groups of related markets. No authentication required.
Get detailed information about a specific market by ID. No authentication required.
Get list of markets from Polymarket. Returns market data including question, end date, and token information. No authentication required.
Get midpoint price for a specific market. The midpoint is the average of best bid and ask. No authentication required.
Get orderbook for a specific market. Shows bids and asks with prices and sizes. No authentication required.
Get user positions by wallet address. Returns all positions held by the user. No authentication required.
Output schemas are not documented in tool definitions. LLMs cannot reason about what fields to expect in responses. Only inferred from code implementation (e.g., get_markets returns {success, count, markets[{id, question, active, closed, end_date}]}, but this is not declared to the LLM).
All tool responses return JSON strings (str type) rather than structured Pydantic models or typed dictionaries. LLMs must parse JSON text, increasing error likelihood and wasting tokens. Should return structured objects with declared fields.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
Get user trade history by wallet address. Returns all trades executed by the user. No authentication required.
Error handling returns generic exception messages without recovery guidance. E.g., 'Failed to get markets: {exception}' tells the LLM nothing about cause, retryability, or next steps. Should categorize errors (retryable vs user-fixable vs fatal) and provide actionable recovery hints.
No tool annotations despite all tools being read-only operations. MCP supports readOnlyHint in tool metadata, should be applied to signal safe operations to LLMs and inform agent planning.
Parameter description for 'user_address' lacks format specification. Ethereum addresses are 42 characters (0x + 40 hex), but description says only 'Ethereum wallet address to query'. Should include expected format to guide LLM input validation.
No documentation of result limits or pagination behavior. Tools with limit/offset should state max results returned even when limit=1000, and whether all results fit in one response or if pagination is required.
'active' parameter in polymarket_get_markets has type bool but default=None, creating type confusion. Should be Optional[bool] with explicit three-state documentation (true=active only, false=inactive only, null=both).