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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: identical lines only are combined, one-sided markets yield no fair probability, prices are latest pre-game, and the call costs 10 credits. It also states a hard usage constraint (never compute stakes/payouts, recommend bets, or refer to a sportsbook), which is behavioral guidance unavailable in structured fields.

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-loaded with purpose and the sibling distinction, then caveats and cost, then the policy constraint. Dense but readable; the pricing/credit and responsible-use sentences are slightly detachable from the core explanation but still earn their place for an agent operating this tool.

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?

An output schema exists, so return values need not be enumerated, yet the description still summarizes what each row contains (average implied probability, fair probability, book count). For a read-only aggregation tool with fully documented parameters, nothing an agent needs to call it correctly is missing.

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 all three parameters are already documented and the baseline would be 3. The description adds interpretation that affects parameter choice, notably that only identical lines are combined and that one-sided markets such as player_anytime_td lack a fair probability, which helps the agent anticipate results for particular market enum values.

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 and resource: aggregated average implied probability (margin in) and fair probability (margin out) per player per line in one game, plus the number of contributing books. It explicitly contrasts itself with per-book pricing, so an agent can distinguish it from get_player_props and get_alt_player_props without opening schemas.

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?

Opens with the selection condition ('what the market thinks of the player props in one game, not any one book's price') and names the alternative for the other case ('For each book's prices use get_player_props'). It also flags the one-sided-market caveat (anytime touchdown has no fair probability) that tells the agent when the fair value will be absent.

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