Server Quality Checklist

Tool Scores

• holdC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'hold position' and does not reveal key behaviors such as whether the unit automatically attacks nearby enemies, whether current orders are canceled, or whether the command is reversible. This is a significant gap for a unit-command tool.

  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 a single short sentence with a parenthetical English clarification, so it is tightly packed and front-loaded. It avoids tautology and communicates the core action efficiently, though the brevity contributes to under-specification.

  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?

  For a simple one-parameter command, the description provides only the basic intent. Without annotations, an output schema, or any note about the effect on the unit, an agent cannot fully predict the outcome of invoking the tool. Sibling differentiation and behavioral context are missing, so the description is not complete enough for safe correct usage.

  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?

  Schema description coverage is 0%, so the description must compensate for the bare integer unit_id parameter. It implicitly identifies the unit as the target of the hold command, but it doesn't explain how to obtain a unit_id, what valid ranges exist, or any constraints beyond being an integer. Minimal added meaning.

  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 '让单位原地驻守(hold position)' clearly states a specific action on a specific resource: making a unit stay in place. It distinguishes the tool from move, attack, and gather by the explicit 'hold position' phrase. However, it doesn't clarify how 'hold' differs from 'stop' — both involve halting a unit — so it stops short of full differentiation.

  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?

  The description gives no guidance on when to use hold versus stop, move, or attack, and no preconditions or alternatives are mentioned. An agent must infer from the tool name and sibling list that it is a unit command, but there is no explicit usage context or exclusion criteria.

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

• buildB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It does warn that coordinates are tile-based, which prevents a common misuse, and it shows the expected argument order. However, it does not disclose side effects, prerequisites, resource costs, or failure behavior for a mutating game action, leaving important behavioral traits undefined.

  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: one action sentence, one coordinate-system warning, and a short example. It is front-loaded with the core purpose, and every sentence contributes value. It could be slightly more efficient by folding the coordinate note into the example, but it is well-structured for its size.

  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?

  For a tool with four required parameters, no output schema, and no annotations, the description leaves critical gaps: no valid building_type values, no indication of where worker_id comes from, no mention of preconditions or results of the build action. The example helps but does not sufficiently round out the context an agent needs to invoke the tool correctly across situations.

  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 0%, so the description must compensate. It does clarify that tile_x and tile_y are tile positions and provides an example mapping all four parameters to values, which helps infer parameter order and types. Yet it does not explain the valid range or format of worker_id, nor enumerate or describe acceptable building_type strings, leaving those parameters under-specified.

  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 action: have a specified worker build a building at tile coordinates, with an explicit example. The verb '建造' (build) and resource '建筑' (building) make the purpose unambiguous and distinguishable from siblings like train, move, or attack. However, it does not explicitly name or contrast sibling tools, so it stops short of a 5.

  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 usage through an example call and clarifies that coordinates are TilePosition, not pixels. It does not explicitly state when to choose this tool over alternatives, nor does it mention any exclusions or preconditions such as worker availability or resource requirements. Usage guidance is present only implicitly.

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

• gatherB
  3.1/5.0
  Behavior2/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 states the intended action but does not disclose behavior around invalid targets, busy workers, ownership, cancellation of previous orders, or failure modes. This is minimal for a command that mutates game state.

  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 one short sentence that immediately conveys the tool's purpose. There is no wasted text or unnecessary elaboration.

  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 two-parameter command, the description is minimally viable: it names the actor and target. However, with no annotations, no output schema, and no usage guidance, the agent still lacks information about valid conditions, side effects, and error 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 0%, but the description helps by identifying worker_id as the worker and resource_id as a mineral/gas resource point. It does not explain where these IDs come from or how they are structured, so it only partially compensates for the lack of parameter descriptions.

  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 that the tool commands a worker to gather a specified resource point (mineral/gas). It is specific enough to distinguish 'gather' from siblings like 'attack' or 'move', though it does not explicitly name an alternative.

  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?

  The description gives no guidance on when to use this tool versus alternatives like move/attack, nor does it mention prerequisites such as worker readiness or proximity to the resource. Usage context is only implied by the word 'gather'.

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

• attackB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the core operation. It does not explain whether the attack is a one-time action or a continuous order, whether the target must be an enemy, whether the unit needs to be in range, or what consequences occur.

  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 one short, direct Chinese sentence with no filler or redundancy. It is efficient and front-loads the core action, though it lacks any additional structured context that would make it richer.

  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 the low complexity (two simple integer parameters) and no output schema, a minimal description could suffice, but the absence of any behavioral context, range, or command persistence leaves an agent without enough information to invoke this tool correctly in varied game situations.

  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%, so the description must compensate. It does clarify the roles of the two parameters: the unit_id is the attacker and the target_id is the target. This adds a relationship that the bare schema names do not capture.

  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 states a specific verb (attack) and a concrete resource (the specified unit attacks a specified target unit). It clearly differentiates from siblings like move or gather by naming the combat action, but it does not explicitly contrast itself with any sibling.

  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 usage context is only implied: you use this when you want a unit to attack a target. There is no explicit guidance about when to prefer this tool over alternatives, no prerequisites, and no restrictions.

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

• stopB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description must disclose behavior itself. It does state the primary effect—stopping the unit's current command—but it does not mention edge cases, what happens to the unit afterward, whether the action is idempotent, or any failure conditions.

  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 one short, front-loaded sentence with no wasted words. It is appropriately efficient for a simple one-parameter tool, though it sacrifices some useful contextual 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 command tool with one parameter and no output schema, the description conveys the core action. However, it lacks guidance on when to use it relative to sibling tools, what the unit does after stopping, and what happens if there is no current command, leaving some ambiguity.

  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 schema has a single required parameter, unit_id, with no documentation. The description mentions 'unit' but does not explicitly explain the unit_id parameter or add format or semantic details beyond the property name. However, the property name is self-explanatory for a single integer parameter.

  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 function: making a unit stop its current command. It identifies both the action and the target resource, and it is distinct in meaning from the sibling tools even though it does not explicitly differentiate itself.

  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 is provided about when to use this tool instead of alternatives such as 'hold' or other command-related tools. The description only states what it does, not the conditions or context that should trigger its use.

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

• moveB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the basic action. It does not mention whether the order is immediate or queued, whether obstacles or invalid coordinates are handled, whether the unit must be owned/controllable, or what result the agent should expect.

  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 a single concise sentence with no filler. The core action and destination are front-loaded, and every word contributes useful information.

  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 3-parameter move command with no annotations and no output schema, the description covers the essential elements: what the tool does, which unit it affects, and what the destination coordinates mean. Some behavioral details are missing, but the tool is simple enough that an agent can likely invoke it correctly from this description alone.

  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 0%, so the description must compensate. It does add meaning by mapping x/y to 'pixel coordinates' and unit_id to 'specified unit,' which goes beyond bare integer names. However, it lacks details such as coordinate system origin, allowed ranges, or unit ownership requirements.

  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 ('move'), the target resource ('specified unit'), and the destination ('pixel coordinates (x, y)'). This distinguishes it from sibling tools like attack, gather, stop, and hold, making the tool'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 Guidelines2/5

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

  No guidance is given about when to use this tool versus alternatives such as attack, gather, or stop. The name implies movement for repositioning, but there is no explicit context, precondition, or exclusion to help an agent choose it confidently.

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

• chatA
  3.5/5.0
  Behavior2/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 of behavioral disclosure. It only states that a chat/text is sent in the game, without explaining whether the message is public, costs an action, or has any constraints. This is a minimal action description without added behavioral transparency.

  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 a single sentence with no redundant information. The verb and object are front-loaded, making it easy to parse.

  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 is adequate but lacks context about whether chat is a free action or consumes a turn, and what the in-game effect is. Since there is no output schema or annotations, the description alone doesn't fully cover these behavioral aspects.

  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 schema has 0% description coverage, and the tool description only mentions '聊天/文字' (chat/text), which implies the 'text' parameter holds the message content. It does not provide details on length, format, or other semantics, so the compensation for the missing schema description is only partial.

  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 uses the specific verb '发送' (send) and resource '聊天/文字' (chat/text), clearly identifying the tool's function. None of the sibling tools (get_game_state, train, build, move, attack, gather, stop, hold) relate to messaging, so it is easily distinguished.

  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 gives no explicit guidance on when to use chat vs alternatives. However, the sibling tools are all distinct game actions, making the intended use (sending a message) reasonably implied. There is no mention of exclusions or alternative communication methods.

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

• trainA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It reveals one key behavior: bridge automatically finds a friendly building capable of training the unit and issues the command. However, it does not cover failure cases, resource costs, or queueing behavior, leaving notable gaps.

  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 short sentences: the first states the action with examples, the second explains the bridge behavior. No filler, front-loaded, and every sentence earns its place.

  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 one-parameter tool, the description is mostly adequate for initial invocation, with examples and a behavioral note about building selection. Missing failure-mode handling, valid unit enumeration, and resource requirements leave moderate gaps, especially given no annotations and no output schema.

  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 is 0%, so the description must compensate. It adds value by showing example values and implying unit_type is a unit identifier, but it does not enumerate allowed unit types or specify validation rules. This is only partial compensation.

  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 uses a clear verb+resource pattern ('训练单位' = train unit) and provides concrete examples such as train("Terran_SCV") that make the operation unambiguous. It does not explicitly distinguish this from the sibling build tool, so it misses the top score.

  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 intended use is implied by the description and examples—call this when you want a unit trained—but it never states when not to use it or names alternatives like build. Guidance is inferable rather than explicit.

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

• get_game_stateA
  4.3/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 behavioral disclosure burden. It openly discloses that it returns only the latest frame, includes visible enemy units, and lists the unit fields (id/type/x/y/hp/sh/player/owner). This is adequate for a simple getter, though it does not explicitly say it has no side effects.

  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 compact and well-structured: it states the purpose first, then enumerates the return groups and unit fields. Every line provides useful information, with no redundant filler.

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

  Completeness5/5

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

  For a zero-parameter, simple game-state getter without an output schema, the description covers the key return contents and field names. There is no missing information that an agent would need to invoke it correctly or interpret its output.

  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 tool has zero parameters, and the schema is empty with 100% coverage, so there is no parameter documentation burden. The description correctly omits irrelevant parameter details, matching the baseline for a parameterless tool.

  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 a specific verb ('获取') and resource ('当前游戏状态'), and further specifies what is returned: self (矿/气/供给/单位列表) and enemies (可见敌方单位). This fully distinguishes it from action-oriented siblings like train, build, and move.

  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 its usage as a read-only state inspection tool, especially in contrast to the action-heavy sibling tools, but it does not explicitly state when to use it or when an alternative would be preferable. Usage context is clear but left to inference.

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