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

Annotations only declare readOnlyHint=true. The description adds valuable behavior: it is one cheap cached read, totals are market counts not rows in the tape window, unknown sport names return matched:false with available names rather than an error, and with sport given it reports that sport's counts. No contradiction with annotations.

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?

Dense but well-organized: core purpose first, then usage, then caveats and exclusions. Every sentence adds information needed for correct selection and interpretation; no 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 no output schema, the description explains what is returned: totals, per-sport breakdown, and optional sport-specific counts. It could have given a more explicit response shape, but it covers the key ambiguity risks such as counts vs rows and unknown sport handling.

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% and already documents that sport is optional, case-insensitive, and handles unknown names with matched:false. The description reinforces the purpose of the sport parameter but adds little beyond the schema.

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 states a specific resource and scope: live and prematch market totals plus per-sport breakdown using FanDuel sport names. It also disambiguates from siblings by explicitly saying it is not a schedule, uptime record, or upsell meter, and carries no prices.

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?

Explicit when-to-use guidance is given: before a board fetch to check if anything is live, to resolve a sport= filter to a name with markets, and to describe coverage accurately. When-not-to-use is also clear via exclusions like 'not a schedule', 'not an uptime record', and 'not what are the odds'.

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