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

Annotations only cover read-only safety, and the description adds substantial behavior beyond that: exact credit pricing (10 per game, capped at 100), the closing-vs-opening capture semantics, the fact that outside football opening and closing are usually identical, the meaning of minutes_before_scheduled_start and when rows are retained, and a hard policy on not computing stakes or recommending bets. It also warns that estimate_only avoids charges.

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?

Front-loads purpose, then usage branching, then capture/backtest caveats, then policy, and nearly every sentence carries information. It is a dense single block with minor redundancy (credit cost restated) and could be broken into clearer segments, but no sentence is pure filler.

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?

With 8 optional parameters, an output schema, and non-obvious time-capture semantics, the description supplies everything an agent needs: which parameter combination to use, what it costs, how to filter for a clean backtest, and what the returned rows contain. Nothing material is missing for correct invocation.

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 100%, so the baseline is 3, but the description adds real semantics on top: the game_id vs player_id+from_date branching, snapshot_type defaults and why opening often equals closing, and the cost implications of each path. It leaves bookmaker keys and market enum details to the schema, which is acceptable given full coverage.

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?

States a specific verb+resource with scope: player prop lines by sportsbook, and enumerates the markets (points, goals, assists, shots on goal, blocked shots, saves, anytime scorer) plus coverage start date and book list. This clearly distinguishes it from siblings like get_odds, get_prop_history and get_prop_projections.

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?

Gives explicit call patterns: game_id for a whole game's props, or player_id + from_date (+ to_date) for one player across games, and names estimate_only as the free dry run. It does not explicitly route the agent away from sibling tools such as get_prop_history or get_prop_projections, so it stops short of full when/when-not guidance.

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