Loading ToolBench
The server implements three read-only tools for Polymarket data discovery with complete input schemas and descriptions. However, there are significant gaps in output schema documentation, parameter validation guidance, and error handling. Tool names follow verb_noun convention correctly (search_events, get_events, get_markets). Descriptions are present but lack depth regarding when to use each tool vs. alternatives, expected return structure, and error recovery paths. All parameters have type definitions and descriptions, but many lack constraints (enums, ranges). The output returns formatted strings rather than structured objects, which requires LLMs to parse unstructured text. No pagination metadata (total count, next_cursor) is documented despite the tools supporting pagination parameters.
Fetch a list of events from Polymarket. Args: limit: Number of events to return (default: 10) offset: Offset for pagination (default: 0) order: Comma-separated fields to order by ascending: Sort in ascending order (default: False) id: List of event IDs to filter slug: List of event slugs to filter tag_id: Tag ID to filter closed: Filter for closed events Returns: Formatted string with event details and markets table
Fetch a list of markets from Polymarket. Args: limit: Number of markets to return (default: 10) offset: Offset for pagination (default: 0) order: Comma-separated fields to order by ascending: Sort in ascending order (default: False) id: List of market IDs to filter slug: List of market slugs to filter condition_ids: List of condition IDs to filter closed: Filter for closed markets Returns: Table-formatted string of the markets list
Search for events on Polymarket using the public search endpoint. Args: q: Search query string (required) cache: Whether to use cached results events_status: Filter by event status limit_per_type: Number of results per type (default: 10) page: Page number for pagination events_tag: List of event tags to filter keep_closed_markets: Number of closed markets to include sort: Field to sort by ascending: Sort in ascending order search_tags: Include tags in search search_profiles: Include profiles in search recurrence: Filter by recurrence type exclude_tag_id: List of tag IDs to exclude optimized: Use optimized search Returns: Table-formatted string of search results
Output schema not documented: all three tools return 'str' (formatted table strings) with no documentation of structure, fields, or expected format. LLMs cannot plan downstream operations or extract structured data.
Parameters lack constraint documentation: 'sort' accepts free-form strings with no enum; 'events_status' has no documented valid values; numeric limits (limit, offset, page) have no min/max ranges stated in descriptions. Invites hallucinated invalid values from LLMs.
Tool descriptions lack context for selection: descriptions state WHAT each tool does but not WHEN to use it vs. alternatives. Does 'search_events' differ from 'get_events'? When should an LLM choose one over the other? No guidance provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
No error handling guidance: descriptions do not explain what errors can occur (e.g., API rate limits, invalid query, malformed parameters) or what the LLM should do if a call fails. No recovery paths documented.
Pagination metadata not documented: tools accept 'limit', 'offset', 'page' parameters and the code builds pagination params, but the output description never states whether full results are returned, how many items come back, or if there are more pages. LLMs cannot reliably iterate through large result sets.
Unstructured output requires LLM parsing: all tools return table-formatted strings via tabulate(). LLMs must parse markdown/grid tables to extract structured data (event IDs, market questions, volumes). Wastes tokens, increases hallucination risk, breaks downstream tool chaining.
Missing chaining IDs in output: search_events and get_events return event details with markets, but no evidence that event IDs or market IDs are included in output. If the next step is to call get_markets with an ID from a previous search, the formatted string output makes extraction ambiguous.