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

Annotations already establish readOnly, idempotent and non-destructive behavior, but the description adds genuine context the annotations don't: results come from a cache and an uncached position yields available=false rather than a guessed evaluation. That fallback contract is exactly the kind of trait an agent needs before relying on the result.

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?

A single front-loaded sentence that delivers the verb, resource, source, output contents and the cache-miss behavior with zero filler. Nothing is padded or redundant.

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 values need not be spelled out, and annotations plus schema cover safety and parameters; the description closes the remaining gap by explaining the cache-miss case. It is only slightly short of complete because it omits any routing hint toward the tablebase sibling for endgame positions.

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% and the FEN and multi_pv parameters are both documented with formats and bounds in the schema. The description's 'up to 3 candidate moves' merely restates the multi_pv maximum, adding no syntax or semantic detail beyond the structured fields, 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?

States a specific verb and resource ('Get the engine evaluation of a chess position (FEN)') and scopes the source as 'Lichess's cloud cache', which meaningfully separates it from a local engine or the tablebase sibling. It does not name a sibling tool to contrast against, so it falls short of the top mark.

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 implies usage (feed it a FEN, get an eval) and notes the up-to-3 candidate-move capability, but gives no explicit when-to-use guidance or exclusions. Notably it never tells the agent to prefer the 'tablebase' sibling for endgame positions, which is the most likely selection ambiguity here.

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

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

Annotations cover the read-only/idempotent/safe profile, and the description adds genuinely new behaviour: results come from Lichess's server analysis rather than a locally computed evaluation, and an unanalysed game yields an explicit statement rather than guesses. Rate limits, auth, or pagination are not mentioned.

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, zero filler: the first front-loads what is returned and from where, the second covers the degraded case. Every clause earns its place.

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-value explanation is not required; the description nonetheless sketches the payload and the unanalysed-game case. With annotations covering safety and the schema covering all three parameters, nothing an agent needs to invoke this 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 description coverage is 100%, including the game_id format and the white/black-or-username option for for_player, so the schema carries the burden. The description lists the three severity labels, loosely mapping to min_severity's enum, but adds no format or edge-case detail 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 (list) and resource (one player's inaccuracies/mistakes/blunders in a Lichess game) and pins the source as Lichess server analysis, which cleanly separates it from siblings like evaluate_position or get_game.

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?

Implies the prerequisite context (a Lichess game that has been analysed, one player at a time) and the fallback when that precondition fails. It doesn't explicitly route the agent away from evaluate_position when the agent just wants a single-position judgement, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real behavioral context: evals and judgments are only present 'when Lichess has analysed the game', and the PGN is 'clean' (headers + moves, no comments). That conditional availability is exactly the kind of nuance annotations cannot express.

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, zero preamble, with the resource and payload front-loaded before the conditional eval caveat. The enumeration is long but each item is substantive rather than filler; slightly list-heavy for a description that could group related fields.

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 no further explanation, and the description nonetheless sketches the payload shape. Combined with full schema coverage and clear annotations, an agent has everything needed to invoke it; only the routing versus sibling list tools 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 both parameters (game_id format/URL, include_pgn default) are already fully documented in the schema. The description mentions 'Includes clean PGN' and 'every move in SAN', which aligns with but does not extend the schema semantics. 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?

States a specific verb ('Fetch') plus a precise resource ('one Lichess game') and enumerates the returned payload: players, ratings, result, opening, time control, SAN moves with clock times, engine evals/judgments, and PGN. The singular 'one game' clearly separates it from sibling recent_games (a list) and get_player (a player entity).

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?

Usage is implied by the payload description, and the clause 'when Lichess has analysed the game' signals a conditional expectation the caller should have. However, no sibling is named and no when-to-use/when-not guidance is given, so the agent must infer that recent_games is the path for discovery and this tool for a known game_id.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive, so the safety profile is fully covered by structured data. The description's addition is mostly return-content scope (which speed ratings, provisional flags, W/L/D totals), and since an output schema exists that content is largely redundant. It does not mention auth or rate limits.

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?

One front-loaded sentence with zero filler: verb and resource come first, and the parenthetical field list earns its place by defining scope rather than padding. Nothing to cut without losing information.

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?

For a single-parameter read-only lookup with a full output schema and complete annotations, the definition is essentially complete. The only minor gap is that most of its text describes return values that the output schema already documents, and no auth/rate-limit context is offered.

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?

The single parameter has 100% schema description coverage, including a pattern and a concrete example ('thibault') and the case-insensitivity note, so the schema carries the full burden. The description adds nothing about the username argument beyond implying profile lookup, which is the baseline-3 case for fully documented params.

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?

Specific verb ('look up') plus specific resource ('Lichess player'), and it enumerates the exact data scope (per-speed ratings, game counts, provisional flags, W/L/D totals, profile info). That scope makes it clearly distinguishable from siblings like get_game, recent_games, and opening_stats, which operate on games/openings rather than a player profile.

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?

Usage is implied by the verb and resource — an agent can infer this is the profile-lookup tool — but there is no explicit when-to-use statement and no reference to alternatives such as recent_games when the agent actually wants game history. No exclusions or prerequisites are stated anywhere.

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

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

Annotations already declare readOnly=true, idempotent=true, non-destructive and open-world, so safety is covered. The description adds genuinely useful non-obvious context: the solution payload is withheld unless reveal_solution=true, which tells the agent why a call may return no solution.

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?

One compact sentence plus a conditional clause; the verb and identifier are front-loaded and the return contents are delivered as a tight list. 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?

For a two-parameter lookup with a full schema and an output schema, the description covers the essentials. It omits where an agent obtains a puzzle id and any error behavior for invalid ids, but nothing critical to correct invocation 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 the baseline is 3. The description goes slightly beyond the schema by explaining the conditional effect of reveal_solution on the returned payload (solution remains hidden), which is the kind of effect detail that helps decide whether to set it.

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 ('Fetch a Lichess puzzle by id') and enumerates what comes back (FEN, side to move, rating, themes, source game). It does not, however, name or contrast itself with the close sibling puzzle_of_the_day, which also returns a puzzle, so an agent must infer the distinction.

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?

'By id' weakly implies you must already hold a puzzle id, which is an implied prerequisite rather than stated guidance. There is no explicit when-to-use statement and no routing to alternatives such as puzzle_of_the_day for a random/daily puzzle.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but the description adds a genuinely useful non-schema trait: the server requires LICHESS_TOKEN because Lichess now mandates sign-in for the explorer. That is a real operational constraint an agent must know before calling.

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?

Three sentences, no filler: the purpose and return contents are front-loaded, and the authentication requirement follows. Every sentence carries information the agent needs.

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 description need not explain return values, and it correctly focuses on what the tool does, what it accepts, and the token prerequisite. Nothing needed 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 description coverage is 100%, so the schema fully documents fen, moves, speeds, ratings and database. The description only restates what inputs are accepted ('move list or FEN') without adding format or constraint detail 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?

States a specific verb+resource ('Opening explorer statistics for a position') and enumerates the payload (opening name, move frequency, W/D/B results). It is clearly separable from siblings like get_game or evaluate_position, which do not return opening-tree statistics.

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?

Gives clear context for use: query a position via move list or FEN, and choose between the Lichess or Masters database. It does not explicitly say when NOT to use it versus a sibling such as evaluate_position, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuine behavioral trait not in the annotations: the solution is withheld unless reveal_solution=true, and the intended two-call coaching loop. It stops short of noting anything about freshness (that the puzzle changes daily) or failure behavior.

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 what the tool returns, and the second sentence immediately explains the one parameter's behavioral consequence. No filler or restated boilerplate.

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 no further explanation, and the annotations cover the read-only idempotent nature. The description closes the remaining gap an agent needs — that the solution field is conditional — making the definition complete for a zero-required-parameter read tool.

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?

With a single parameter at 100% schema description coverage, the schema already documents reveal_solution, its default, and the coach-then-reveal pattern. The description's mention of reveal_solution restates that same guidance rather than adding format or side-effect detail, 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?

States a specific verb and resource ('Today's Lichess daily puzzle') and enumerates what the response contains (FEN, side to move, rating, themes, source game). It implicitly differentiates from the sibling get_puzzle by scoping to 'today's daily', but never names that sibling explicitly, leaving a small gap for an agent choosing between the two.

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 supplies a concrete usage context and workflow: leave reveal_solution=false so a coach can let the player try, then call again with true. That is actionable guidance for the primary use case, but it gives no exclusions or direct comparison against siblings like get_puzzle or find_mistakes.

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

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.

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered without description help. The description adds the meaningful guarantee that results are exact perfect play rather than heuristics, but it does not state what happens when the 7-piece limit is exceeded or whether lookups can fail/be rate-limited.

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?

A single dense sentence leads with the resource and scope, then enumerates the outputs, then closes with the exactness caveat. No filler, no repetition of the title, and every clause carries information.

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 description needn't explain return values, and annotations cover safety; the one-parameter schema is fully documented. The remaining gap is the out-of-range failure mode and the absence of explicit sibling routing, which keeps it short of 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?

There is a single parameter (fen) with 100% schema description coverage, including a format example and the note that move counters may be omitted, so the schema does the heavy lifting. The description does not mention FEN at all and adds nothing beyond it, which is the expected baseline when coverage is complete.

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+resource: exact endgame result from the Lichess tablebase, with the piece ceiling (7 or fewer) and the returned fields (win/draw/loss, distance to mate or zeroing, ranked moves) spelled out. The clause 'perfect play, not an estimate' distinguishes it from the sibling evaluate_position, which is engine-driven and approximate.

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 '7 or fewer pieces' constraint is an effective precondition that tells the agent when this tool is applicable. However, it never explicitly names an alternative for positions outside that bound (e.g., evaluate_position), leaving the routing decision to inference.

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