Server Quality Checklist

Tool Scores

• lichess_player_profileC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description should disclose behavioral traits. It only states the return data type but does not mention rate limits, authentication, side effects, or response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Very short and front-loaded. However, the 'Args' section is separate and could be integrated. Still, no wasted words, earning a high score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool lacks output schema and annotations. The description does not explain what the returned profile contains, possible error conditions (e.g., invalid username), or any additional context like call limits.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The parameter 'username' is described as 'Lichess username', which adds minimal meaning beyond the schema's type. With 0% schema coverage, the description does not sufficiently compensate to clarify the parameter's usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Returns' and the resource 'player's Lichess profile, ratings, and stats'. This distinguishes it from sibling tools like lichess_fetch_games which deals with games, or lichess_import_pgn for imports.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives like lichess_fetch_games. There is no mention of context, prerequisites, or when not to use it.

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

• lichess_fetch_gamesB
  3.3/5.0
  Behavior2/5

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

  No annotations provided; description only says it fetches recent games. It does not disclose behavioral traits like rate limits, authentication needs, error handling, or what happens if the user doesn't exist. For a tool with zero annotation coverage, this is insufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise with a clear subject line and bullet arguments. It is front-loaded with the main purpose. However, it mixes languages (Czech description with English argument names), which slightly reduces clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema and no annotations, the description should explain return values, but it does not. It also lacks context about data format, pagination, or limitations. For a tool with moderate complexity (3 parameters, no output schema), this is incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description adds value for all three parameters: username is clarified to accept both Lichess and Chess.com usernames, max_games bound is specified as 1-50, and source options are explicitly listed as 'lichess' or 'chesscom'. This goes beyond the schema's defaults and titles.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool downloads recent games of a player from Lichess or Chess.com. The verb 'stahne' (downloads) and resource 'recent hry hrace' (recent games of a player) are specific, and it distinguishes from sibling tools like lichess_import_pgn or lichess_player_profile.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or when not to use it. The description simply states what it does without any usage boundaries.

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

• lichess_opening_explorerA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only states it looks up a position, without mentioning read-only behavior, authentication needs, rate limits, return structure, or side effects. The description adds minimal value beyond the basic purpose.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise with two sentences and a bullet list. It is front-loaded with the main purpose and efficiently explains both parameters. There is no wasteful or redundant text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has only 2 parameters, no output schema, and no annotations. The description covers the purpose and parameter meanings adequately. However, it omits any indication of return values (e.g., move statistics, games count) or error handling (e.g., invalid FEN). It is minimally viable but could be more complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It explains the 'fen' parameter as a FEN string and the 'source' parameter as a choice between 'lichess' and 'masters', including the default. This adds meaningful context beyond the schema titles, though format details for FEN could be added.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool looks up a position in the Lichess Opening Explorer, using a specific verb and resource. It is distinct from sibling tools like lichess_fetch_games or lichess_player_profile, which serve different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains the basic functionality and the parameters, but does not provide explicit when-to-use or when-not-to-use guidance. The context is clear given the name and siblings, but no exclusions or alternatives are mentioned.

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

• lichess_match_patternsA
  4.1/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It explains it returns confidence scores, evidence, mitigation advice, and compression validation, but does not explicitly state that it is read-only or requires prior library import.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear purpose statement, action details, and an Args section. It is somewhat verbose but not overly so.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, parameters, and return values. It could mention that the pattern library must be imported first, but overall it provides sufficient context for a 3-parameter tool without annotations or output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description adds value beyond the schema by explaining each parameter (username, max_games with range 5-50, depth with range 8-18) and their purpose, despite 0% schema coverage measurement.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it detects known playing patterns from a pattern library, using a specific verb and resource. It distinguishes from sibling tools like lichess_fetch_games and lichess_opening_explorer.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions analyzing recent games and matching against a pattern library, implying a prerequisite (library import), but gives no explicit when-to-use or when-not-to-use guidance compared to siblings.

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

• lichess_import_pgnA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses that PGN is parsed through a Stockfish pipeline, returns per-move evaluation and classification, and stores results in L2 Resources for later retrieval. This gives good insight into behavior without contradictions. It does not mention side effects like rate limits or authentication, but for a read-like import, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: 6 sentences plus a bullet list. The main action is front-loaded in the first sentence. Every sentence adds value: purpose, technical detail, use cases, and parameter explanation. No redundant or vague phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 4 parameters (1 required) and no output schema, the description covers purpose, parameters, and usage guidelines well. It explains what results are returned (evaluation, classification, phase detection) and storage mechanism. However, it lacks details on how to retrieve the stored results or the exact format of the analysis, which would aid completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description adds full parameter details via an Args block: pgn (full PGN string), color (white/black, default white), depth (integer range 8-24, default 14), game_id (optional, auto-detected from PGN Site header). This adds significant meaning beyond the schema alone, providing defaults, ranges, and usage context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with a clear action: 'Import and analyze a chess game from a PGN string.' It specifies the verb (import/analyze), resource (chess game), and input format (PGN string). The tool is distinct from siblings like lichess_fetch_games, which fetches from lichess, and lichess_match_patterns, which compares patterns. The resource scope is well-defined.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description lists four specific use cases: analyze your own games, import GM games, analyze opponent games, and build a custom library. It also references sibling tool lichess_match_patterns for comparison. However, it does not explicitly state when not to use this tool or provide alternative tools for different scenarios, missing some guidance.

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