A player's recent games

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

Annotations already establish read-only, idempotent, non-destructive behaviour, so the description only needs to add context. It does: games are 'finished' (not in-progress), capped at 20, and accuracy is present only 'when Lichess has analysed the game' — a genuinely useful conditional that no annotation conveys.

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?

Two sentences, front-loaded with purpose then the chaining hint, with no filler. The enumerated return-field list is somewhat long, but it supports the purpose statement rather than padding it.

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 an output schema present, the return shape needn't be re-explained, and safety is covered by annotations; the description still supplies the 20-game cap, the 'finished' qualifier, the accuracy condition and the find_mistakes handoff. Only the relationship to get_game for single-game detail is left implicit.

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 max, rated, perf_type and username are already fully documented with defaults, ranges and enums; the description's 'up to 20' merely restates the schema maximum. Baseline 3 applies since the description adds no syntax or semantics 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?

States a specific verb and resource ('List a Lichess player's most recent finished games') plus the scope cap and the exact fields returned, which cleanly separates it from get_game (single game) and get_player (profile). An agent can pick it over siblings on name alone.

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?

Explicitly routes the agent forward: 'Use has_analysis to pick games that find_mistakes can review,' naming the downstream sibling and the condition that selects it. However it gives no contrast against get_game, get_player or opening_stats, and 'has_analysis' is an output field rather than an input, which could momentarily confuse an agent scanning parameters.

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