Loading ToolBench
MCP server for SharpAPI: live sports betting odds, +EV, arbitrage and middles as Model Context Protocol tools
Strong foundation with 9 well-named tools following verb_noun convention (list_*, get_*). All tools have descriptions (avg 180 chars, within 10-1024 baseline). Input schemas use Zod with type definitions and descriptions for most parameters. Key gaps: output schemas are not documented (LLMs cannot predict response structure), some parameter descriptions lack format/constraint details, and error handling is generic ('SharpAPI request failed: {msg}') without recovery guidance. No tool annotations (readOnlyHint, destructiveHint). Pagination support present (cursor, limit) but not fully documented in all tools.
Find cross-book arbitrage opportunities: sets of prices whose combined implied probability is under 100%, so backing every outcome locks a margin. Requires a Hobby plan or above.
Get the best available price per selection across all covered books. This is the line shopping view: one row per selection rather than one per book.
Find positive expected value (+EV) bets: prices that beat the fair probability implied by the wider market. Each opportunity carries a fairProbability field, which is the de-vigged number. Requires a Pro plan or above.
Get all odds for a specific event across every covered sportsbook. Returns the complete set of rows for that event in one call — no pagination. Use list_events to find event ids. To narrow by book, pass sportsbook.
Find middle opportunities: two prices on opposite sides with a gap where both bets can win. Sorted by quality unless told otherwise.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination format). Rubric requires 'Document the output schema' for all tools.
Error handling is generic ('SharpAPI request failed: {msg}'). Does not categorize errors as retryable/user-fixable/fatal or provide recovery guidance. Rubric requires 'Error responses must tell the LLM what to do next.'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only but this is not declared in the schema. Rubric rewards tool annotations as current pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 75 | 2026-07-28+ | v2 |
Get normalized odds across sportsbooks. Returns American and decimal prices plus implied probability, one row per book/market/selection, so prices are directly comparable between books. Results are paginated at 100 rows by default; pass the cursor from pagination.next_cursor to fetch the next page when pagination.has_more is true.
List events (games) with ids, start times and teams. Use this to find an event id before fetching odds for it.
List the sports SharpAPI covers, with live and upcoming event counts for each. Call this first to discover valid sport ids for the other tools.
List the sportsbooks SharpAPI normalizes, with their ids. Use the returned ids for the `sportsbook` argument elsewhere. Which books a key can actually read depends on its plan: the free tier serves DraftKings and FanDuel only.
Parameter descriptions lack format/constraint details. E.g., 'date' accepts 'ISO date' but no validation pattern shown; 'limit' max=500 is in schema but not in description text. Rubric: 'When a parameter has a regex pattern, length limit, or character restriction, state it in the description.'
Pagination cursor behavior not fully documented in all tools. 'get_odds' documents cursor well, but 'get_best_odds', 'get_arbitrage', 'get_ev', 'get_middles' do not mention pagination or cursor support despite accepting 'limit'. Rubric: 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.'