Server Quality Checklist

Tool Scores

• createGameA
  3.5/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden of disclosing side effects and behavior. It does state the core side effect (initializes a session) and that it returns a Game ID and instructions, but it omits any context about permissions, session lifecycle, whether repeated calls create multiple sessions, or type-dependent outcomes. For a state-changing tool, this is thin disclosure.

  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 consists of two short, front-loaded sentences: the first states the core action, the second the return value. There is no filler, and every sentence adds information. It is concise without sacrificing the essentials.

  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 no output schema and no annotations, so the description's 'Returns the Game ID and instructions' is the only return guidance. It does not specify the shape of the return value, how the Game ID should be used with sibling tools, or the fact that the return differs by opponent type (e.g., human returns UI). It is minimally adequate but leaves gaps for a stateful, multi-tool workflow.

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

  Parameters3/5

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

  Schema coverage for parameters is 100%, so the baseline is 3 even though the description adds no parameter-specific meaning. The description does not mention type, color, or difficulty, leaving all parameter semantics to the input schema, which is adequate.

  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 opens with 'Initializes a new chess game session,' which names a specific action (initializes) and resource (chess game session), and adds that it returns the Game ID and instructions. This clearly distinguishes it from sibling tools like waitForNextTurn or joinGame by focusing on session creation.

  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 verb 'initializes' implies that this tool is for starting a new game rather than joining (joinGame) or progressing an existing one, but no explicit when-to-use or when-not-to-use guidance is provided. The description does not name alternatives or conditions, leaving the agent to infer usage from the tool name and sibling list.

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

• joinGameA
  3.5/5.0
  Behavior2/5

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

  The description mentions the return value (board state and turn information) but does not disclose potential side effects (e.g., whether joining modifies the game state or requires authentication). Since no annotations are provided, the description carries the full burden, and this omission is significant.

  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?

  Two sentences, no filler. The first sentence states the action, the second describes the return. Efficiently front-loaded with key information.

  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?

  For a simple tool with one parameter and no output schema, the description is decent but lacks context on what happens if the game is full or requires authorization. Given no annotations, more completeness would be expected to guide correct usage.

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

  Parameters3/5

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

  The input schema provides a description for the single parameter (game_id) and covers 100% of parameters. The description does not add additional meaning beyond the schema, so a baseline of 3 is appropriate.

  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 action ('Joins') and the resource ('an existing chess game'). The sibling tools (createGame, finishTurn, waitForNextTurn) have distinct purposes, making joinGame's role unambiguous.

  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 implies the tool is for joining a game after it has been created, but it does not explicitly say when to use it versus alternatives like createGame. No prerequisites or conditions for use are stated.

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

• waitForNextTurnA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure, and it does reveal the blocking nature and timeout. However, it doesn't state what happens when the 30-second wait expires, whether it can be polled repeatedly, or what information it returns. The 'User's turn via Agent proxy' phrasing adds ambiguity rather than clarity.

  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 two short sentences, front-loads the core blocking behavior, and includes the critical timeout detail. Every phrase contributes meaning, with no redundancy or filler.

  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?

  For a simple one-parameter tool, the description covers the main purpose and timeout. However, the lack of an output schema and the absence of any statement about timeout behavior or return value leaves a notable gap. The ambiguity around 'User's turn via Agent proxy' also reduces completeness.

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

  Parameters3/5

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

  The only parameter, game_id, is fully described in the schema with 100% coverage. The description does not add any extra semantic detail about how game_id is used beyond the schema, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: it blocks until the Agent's turn, with a 30-second wait for the opponent. The verb 'blocks' and the resource 'turn' make the operation understandable, and it is distinct from siblings like finishTurn or joinGame, though it doesn't explicitly reference them.

  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 implies this should be used when waiting for an opponent after your turn, and mentions the 30-second timeout. However, it gives no explicit guidance about when to use it versus alternatives, nor what to do if the timeout elapses. Usage context is only implied, not stated.

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

• finishTurnA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of explaining behavior. It does disclose the return behavior ('returns the updated state or a precise failure'), which is useful, but it does not describe side effects, turn ownership requirements, or the meaning of the claim_win option. This is a reasonable partial disclosure.

  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?

  A single tight sentence front-loads the action and then gives the expected result. Every phrase contributes, with no repetition of the title or schema fields.

  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?

  For a simple move-submission tool with fully documented parameters, the description plus schema is nearly complete. It would benefit from a brief note on when it is valid to call (e.g., only during the player's turn), but the lack of an output schema is mitigated by stating the return behavior.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all three parameters already have meaningful schema descriptions (e.g., UCI format, claim_win semantics). The tool description adds little about the parameters, but it does not need to compensate for missing schema coverage.

  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?

  States a specific action ('Submits a move') and its result, clearly distinguishing it from sibling tools like waitForNextTurn, createGame, and joinGame. No ambiguity about what resource/operation this covers.

  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 context of submitting a move is implicit given the name and UCI-formatted move parameter, but the description never explicitly says when to call it or when to prefer a sibling such as waitForNextTurn. No alternatives or exclusions are named, so the agent must infer usage from the verb and parameter names.

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