SportIQ

cricket_find_value_bets

Read-onlyIdempotent

Screens IPL odds events and compares model probabilities with de-vigged market prices to identify value bets; returns screened event counts with no bets until a calibrated cricket model is available.

Instructions

Compare model probabilities against market-implied IPL odds. Requires THEODDS_KEY.

NOTE: cricket has no calibrated team-strength model wired yet (unlike the football Elo/Poisson path), so this tool currently returns an EMPTY value_bets list — scoring an edge against a neutral 50/50 prior would flag every market underdog, which would be misleading. It still reports how many events were screened so callers know odds were available. For raw de-vigged prices use cricket_get_live_odds. Real edge detection lands when a cricket win model is wired (see cricket_head_to_head); it will flag outcomes where the model beats the de-vigged market by min_edge and the offered price has positive expected value.

Args: team: Optional team name to filter events (case-insensitive substring). Omit to scan every IPL odds event. min_edge: Minimum edge (model_prob - devigged_market_prob), 0..1. Default 0.05. Currently informational only (no bets emitted).

Returns: data.value_bets: always [] until a cricket model is wired. data.events_analysed: count of not-yet-started events screened (both teams present). data.model: "neutral_baseline". data.note: why no bets are emitted. meta.estimated: true.

Input Schema

Name	Required	Description	Default
`team`	No	Optional team name to filter events (case-insensitive substring). Omit to scan every IPL odds event.
`min_edge`	No	Minimum edge (model_prob - devigged_market_prob), 0..1. Default 0.05. Currently informational only (no bets emitted).

Output Schema

Name	Required	Description	Default
`data`	No
`meta`	No
`error`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Jul 10, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the read-only annotations by disclosing the THEODDS_KEY requirement, the current empty value_bets behavior, the neutral_baseline model, and the estimated flag. This prevents an agent from misinterpreting an empty result as a bug or as evidence of no value bets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but mostly justified because the empty-result caveat is essential. The Returns section overlaps with the output schema and could be tighter, but the front-loaded purpose and limitation make the overall structure effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's unusual current behavior, the description provides the missing context an agent needs: why results are empty, what is still returned, and when real edge detection will be available. Together with the existing output schema, nothing important is omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents team and min_edge thoroughly. The description adds useful context that min_edge is currently informational only and that omitting team scans every IPL odds event, which is slightly beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: comparing model probabilities against market-implied IPL odds. It clearly distinguishes itself from cricket_get_live_odds by noting that raw de-vigged prices belong to that sibling, and it explicitly explains the current neutral-baseline limitation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It tells the caller exactly when to use the alternative: use cricket_get_live_odds for raw de-vigged prices. It also explains the current limitation of this tool and what it still returns, so an agent can decide whether to call it at all rather than inferring from a misleading name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server