Loading ToolBench
Read the record behind a Polymarket resolution: how many dispute rounds, who was wiped out, and who bought the side that won.
Recuse has 29 tools with consistent naming (verb_noun pattern: assess_*, fetch_*, read_*, write_*, etc.) and descriptions present for all. However, critical gaps undermine quality: input schemas are largely absent or minimal. Most tools show object-type parameters with generic descriptions ('Market object', 'Assessment options') but lack detailed field-level schemas, type constraints, and parameter validation rules. Descriptions average ~80 chars but lack LLM-optimized guidance on WHEN to use each tool vs. similar ones. No output schemas documented. Error handling is implicit, not explicit. The tool set is well-composed (single responsibility, good naming), but schema and parameter documentation fall well short of production baseline (94% of A+ tools have full param descriptions; this server ~30%).
Add a market to the watchlist for monitoring.
Assess multiple markets in batch. Reads contested markets and returns assessments for all.
Read one market: what happened to its resolution, and who held it. Never throws for a missing source. A market with unreachable holders still returns an assessment, with the gap recorded as a caveat.
Assess one wallet's settlement positions across disputed markets.
Check whether a newer version of recuse was published.
Validate a webhook URL for event notifications.
Calculate how much of one side sits with its largest holders.
Fetch both YES and NO side states for a market.
Input schemas lack field-level detail. Most parameters are typed as 'object' with generic descriptions ('Market object', 'Assessment options') but do not specify required fields, nested types, or constraints. LLMs cannot validate inputs or understand what fields to construct.
No output schemas documented. Tools return data structures (assessments, tallies, concentrations) but the response format is not specified. LLMs cannot plan downstream tool calls or extract required fields without guessing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
Fetch contested markets from Polymarket. Returns markets that have been disputed.
Fetch a single market by ID or slug from Polymarket.
Fetch multiple markets from Polymarket.
Parse a market's resolution lifecycle into dispute state with round count and phase.
Get markets whose resolution has not finished.
Read the event log of market movements.
Read the cached radar state of contested markets.
Read the current watchlist of markets being monitored.
Recall what changed since the last run by comparing current and previous states.
Remove a market from the watchlist.
Tally addresses across contested markets to find repeat losers.
Tally addresses across the winning sides of contested markets.
Run the watcher in a continuous loop, checking for market movements at intervals.
Run one pass of the watcher to check for market movements.
Take a snapshot of current market state for watching.
Summarise the event log as a whole, showing event counts, markets, and activity.
Tally addresses on the winning side repeatedly across contested markets.
Tally addresses left holding losing sides repeatedly across contested markets.
Calculate concentration over the winning side, rebuilt from what people bought.
Calculate what the winning side put in and took out.
Write the radar state to cache.
Parameter descriptions lack actionable constraints. Numeric parameters (limit, topN, holderLimit, minAppearances) have no min/max bounds. Enum parameters (side, meaning) are documented but lack guidance on when to use each value. LLMs cannot self-correct invalid inputs.
No error handling guidance. Tools do not document failure modes, recovery steps, or what to do if a market is not found, a wallet is unreachable, or a webhook validation fails. Agents have no path forward on errors.
Tool composition lacks chaining hints. Tools like assess_market and fetch_market exist, but descriptions do not explain when to call fetch_market first vs. passing a market object directly. Multi-step workflows are not documented.