get_value_bets

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It adds the refresh rate ('signals refresh about every 10 minutes') and the meaning of 'current' signals, which is useful. However, it does not explicitly state that this is a read-only operation, nor does it mention any rate limits or pagination behavior. The presence of an output schema reduces the need to describe return values, but more behavioral context (e.g., what happens if since is stale) would improve transparency.

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

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

The description is concise and front-loaded: the main purpose is stated in the opening clause, followed by optional filters and polling advice. All information is relevant and necessary, with no redundant phrases or filler. It fits in two sentences while covering all key aspects.

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

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

For a simple 2-parameter tool with an output schema, the description covers all essential context: what the tool returns (value-bet signals), how to filter (strategy), how to poll for new picks (since), and how often data updates (10 minutes). The output schema handles return structure, so the description does not need to repeat that. This is complete for the tool's complexity.

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

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

Schema coverage is 0%, so the description must compensate. It fully explains both parameters: strategy with specific accepted values ('hs2_v6' = High Volume, 'hs1_v6' = Sweet Spot) and since with its purpose for incremental polling. This adds significant meaning beyond the raw schema types (integer/string), making it clear how and why each parameter should be used.

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

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

The description clearly states the tool's function: 'Current value-bet signals — where PlayerElo's fair odds diverge from the market price.' It identifies the specific resource (value-bet signals) and the scope (current, based on odds divergence). This distinguishes it from sibling tools that focus on players, coaches, clubs, and leagues.

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

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

The description provides clear usage guidance for both optional parameters: strategy ('hs2_v6' and 'hs1_v6') and since ('pass since=<the largest id from your previous call>'). It also explains the refresh cadence ('about every 10 minutes'), which informs when to poll. However, it does not explicitly mention when not to use this tool or suggest alternatives, though the sibling set is clearly different.

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