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

Annotations already declare read-only, idempotent, closed-world, non-destructive, so the safety profile is fully covered. The description adds genuinely new context beyond that: it is a delayed sample, restricted to games that started 3+ hours ago, and limited to the last 30 days — key expectations for the caller.

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 the core identity ('delayed free sample of Line Moves') and follows with the qualifying constraints and return fields. Compact and free of filler; only minor redundancy in spelling out both 'free sample' and 'Free tier'.

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 helpfully enumerates the returned fields (the call, line at call time, predicted closing line). Absent only a note on ordering or pagination, which is minor for a two-param sample endpoint.

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?

Both parameters (limit, sport) are fully documented in the schema at 100% coverage, including the default and enum values. The description adds no parameter-level detail such as how 'limit' interacts with the sample size or default ordering, so it hits the baseline.

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 resource (line-move calls) and scope precisely: delayed free sample covering games that started 3+ hours ago within the last 30 days, with named return fields (call, line at call time, predicted closing line). It implicitly distinguishes itself from the paid get_line_moves by 'free sample'/'delayed' but never names that sibling explicitly.

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 constraints ('free tier', 'delayed', 3+ hours ago, last 30 days) imply when this tool applies versus the full feed, but the description never says 'use get_line_moves for full/real-time data'. The agent must infer the routing from the sibling name alone.

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