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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: results arrive as cited rows told from the player's perspective, the record is pre-aggregated by season/team/stage, and the tool has a hard data boundary on injuries and availability.

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?

It is three sentences and front-loads the return shape before the triggering condition and the data-boundary warning. Some phrasing is ornate ('cited rows told from the player's side', 'the Desk'), which costs a little clarity but does not bury the actionable content.

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 five parameters, no output schema and rich annotations, the definition covers what is needed to choose the tool and set expectations for the response shape and the excluded data domain. A brief note on ordering or what restricts the returned rows would make it fully complete.

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 description coverage is 100%, so every parameter (asked, limit, player, season, includeAllSeasons) is already documented with defaults, maximums and constraints. The description only hints at the season/team/stage aggregation logic and does not add syntax or interpretation guidance beyond the schema, so the baseline 3 applies.

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 uses a specific verb and resource: it returns recorded lines a named player appeared in, as cited rows plus a record broken out by season, team and stage. That is clearly separable from sibling tools like query_match_log, query_player_rating and query_cohort_standing, which return different shapes.

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?

It gives an explicit trigger – 'when someone asks about a player's results, form or history' – and an explicit exclusion, warning that injury and availability are not held by the Desk. It stops short of naming a sibling tool (e.g., availability_loop) as the alternative for availability questions, so it lands at 4 rather than 5.

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