Server Quality Checklist

Tool Scores

• systemD
  1.7/5.0
  Behavior1/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. The description fails to indicate whether this tool performs read-only operations, mutations, or both. It doesn't mention permissions needed, side effects, error conditions, or what happens when operations are performed. For a complex 15-parameter tool with no annotations, this is a critical gap.

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

  Conciseness3/5

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

  The description is brief (8 words) but under-specified rather than concise. It's structured as a feature list without clear organization. While not verbose, it fails to communicate essential information, making its brevity a liability rather than a strength.

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

  Completeness1/5

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

  For a complex tool with 15 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool does, when to use it, what behaviors to expect, or how parameters interact. The feature list provides minimal context that doesn't help an agent understand this tool's role in the system.

  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 the schema already documents all parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate schema coverage, but the description contributes zero additional parameter semantics.

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

  Purpose2/5

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

  The description lists system features (scoreboards, screen displays, player UI, game management) but doesn't state what the tool actually does. It's a vague feature list rather than specifying a verb+resource action. The name 'system' is generic, and the description doesn't clarify whether this is for configuring, querying, or manipulating these features.

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

  Usage Guidelines1/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. The description provides no context about appropriate use cases, prerequisites, or distinctions from sibling tools like 'player', 'sequence', or 'send_message' that might overlap with UI/messaging functionality.

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

• agentC
  2.6/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. While it hints at various actions, it doesn't describe what the tool actually does (e.g., executes commands in a Minecraft-like environment), potential side effects, permissions needed, or response format. This leaves significant gaps for a tool with 11 parameters and no output schema.

  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, efficient phrase listing action categories without unnecessary words. However, it's front-loaded with a broad scope that might not clearly guide usage, and it could benefit from more structure to clarify the tool's core function.

  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 complexity (11 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain the tool's context (e.g., Minecraft agent control), behavioral outcomes, or how to interpret results, leaving the agent with inadequate information to use the tool effectively despite the detailed 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 description coverage is 100%, providing detailed documentation for all 11 parameters including enums and constraints. The description adds no additional parameter information beyond the schema, so it meets the baseline of 3 for adequate coverage without adding value.

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

  Purpose3/5

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

  The description lists categories of actions ('movement, building, mining, inventory, exploration, construction, resource gathering') which gives a general sense of purpose, but it's vague and doesn't specify a clear verb+resource combination. It distinguishes from some siblings like 'camera' or 'world' by focusing on agent actions, but doesn't clearly differentiate from 'player' or 'sequence' tools that might overlap in functionality.

  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 on when to use this tool versus alternatives. The description doesn't mention any prerequisites, constraints, or comparisons to sibling tools like 'player' or 'sequence', leaving the agent to guess based on the action list alone.

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

• blocksC
  2.6/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 burden but offers minimal behavioral insight. It mentions 'placement, area filling, terrain queries' which implies both read and write operations, but doesn't disclose permissions needed, rate limits, destructive effects, or response formats. For a tool with 10 parameters and no annotations, this is inadequate disclosure.

  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 extremely concise (6 phrases separated by commas) with zero wasted words. It's front-loaded with key concepts. However, the comma-separated list format lacks grammatical structure and reads more like tags than a coherent description.

  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 complex tool with 10 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the relationship between parameters, doesn't clarify that 'action' determines which other parameters are relevant, and provides no information about return values or error conditions. The description fails to compensate for the lack of structured metadata.

  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 the schema already documents all parameters thoroughly. The description adds no specific parameter information beyond what's in the schema. It mentions 'placement, area filling, terrain queries' which loosely maps to some action values but doesn't explain parameter relationships or usage patterns. Baseline 3 is appropriate when schema does all the work.

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

  Purpose3/5

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

  The description lists multiple operations (placement, area filling, terrain queries) but doesn't specify a single clear purpose or verb. It mentions 'block operations' which is tautological with the tool name 'blocks'. While it gives a sense of scope, it lacks a specific action statement that distinguishes it from sibling building tools.

  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 the many sibling building tools (build_cube, build_sphere, etc.) is provided. The description mentions 'single blocks, large areas' which implies some scope but doesn't clarify when to choose this over specialized building tools. No explicit alternatives or exclusions are mentioned.

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

• worldC
  2.6/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 mentions 'management' which implies mutation capabilities (e.g., set_time, set_weather, run_command), but doesn't specify permissions required, side effects, or what happens with invalid inputs. It lists functional areas but doesn't describe how operations interact with the world or players. For a multi-action tool with potential mutations, this is inadequate.

  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, efficient phrase listing key functional areas. It's appropriately sized and front-loaded with the core purpose ('World management'). However, it could be more structured by grouping related actions or indicating primary vs. secondary functions, but it avoids unnecessary verbosity.

  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 tool's complexity (8 parameters, multiple action types including mutations like 'run_command'), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects, error handling, or return values, leaving significant gaps for an AI agent to understand how to use it effectively. The schema covers parameters well, but the description fails to compensate for missing context elsewhere.

  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 the schema already documents all 8 parameters thoroughly with descriptions, enums, and constraints. The description adds no parameter-specific information beyond what's in the schema—it doesn't explain relationships between parameters (e.g., how 'action' determines which other parameters are relevant) or provide usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose3/5

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

  The description 'World management: time, weather, environment, day/night cycles, world queries, connections' lists functional areas but lacks a specific verb or clear scope. It mentions 'management' which implies control operations, but doesn't distinguish this from sibling tools like 'execute_command', 'send_message', or 'sequence' which overlap with some of its capabilities. The description is somewhat vague about what exactly this tool does versus others.

  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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'execute_command', 'send_message', and 'sequence' that handle similar actions (e.g., running commands, sending messages, sequencing actions), there's no indication of when this tool's 'action' parameter should be preferred over those dedicated tools. No exclusions or prerequisites are mentioned.

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

• build_cylinderC
  2.8/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 mentions 'Requires: centerX,centerY,centerZ,radius,height. Optional: axis', which hints at input requirements but lacks details on what the tool actually does (e.g., whether it modifies the world, requires permissions, has side effects, or returns any output). For a build tool with no annotations, this is a significant gap in describing behavioral traits.

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

  Conciseness3/5

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

  The description is brief but could be more structured; it front-loads the purpose with synonyms but then lists parameters in a comma-separated format that might be less clear. It's not overly verbose, but the sentence 'Build CYLINDER: tower, pillar, column, chimney, pipe, tube.' could be more direct, and the parameter listing feels tacked on without full integration.

  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 complexity of a build tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how it affects the Minecraft world, or any error conditions. While the schema covers parameters well, the description fails to provide necessary context for safe and effective use by an AI agent.

  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 the schema already documents all 9 parameters thoroughly with descriptions, defaults, and constraints. The description adds minimal value by listing required and optional parameters but doesn't provide additional meaning beyond what's in the schema (e.g., it doesn't explain parameter interactions or usage tips). Baseline 3 is appropriate when the schema does the heavy lifting.

  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 as building a cylinder with synonyms like 'tower, pillar, column, chimney, pipe, tube', which helps clarify the type of structure. However, it doesn't explicitly differentiate from sibling tools like build_cube or build_sphere, though the cylinder shape is implied. The verb 'Build' is specific and the resource 'CYLINDER' is clear.

  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 provides no guidance on when to use this tool versus alternatives like build_cube or build_sphere, nor does it mention any prerequisites or exclusions. It only lists required parameters without contextual usage advice, leaving the agent to infer based on the tool name alone.

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

• build_paraboloidC
  2.8/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 burden for behavioral disclosure. It states 'Build PARABOLOID' which implies a creation/mutation operation, but doesn't specify permissions needed, whether it's destructive to existing blocks, rate limits, or what happens on success/failure. The parameter list adds some context but lacks critical behavioral details for a building tool.

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

  Conciseness3/5

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

  The description is brief but somewhat disorganized. It front-loads the purpose but then awkwardly lists parameters in a run-on format. While not verbose, the structure could be clearer (e.g., separating purpose from parameter guidance). Some sentences feel crammed together rather than optimally structured.

  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 10-parameter building tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or practical building considerations in Minecraft. While the schema covers parameters well, the description fails to provide the broader context needed for effective use in a game environment.

  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 the schema already documents all 10 parameters thoroughly. The description lists required and optional parameters but doesn't add meaningful semantic context beyond what's in the schema (e.g., explaining relationships between radius and height, or practical building tips). This meets the baseline for high schema coverage.

  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: 'Build PARABOLOID' with specific examples (satellite dish, bowl, dish, parabolic). It distinguishes from siblings like build_cube or build_sphere by specifying the geometric shape. However, it doesn't explicitly differentiate from similar tools like build_hyperboloid or build_ellipsoid, which keeps it from a perfect score.

  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 provides no guidance on when to use this tool versus alternatives. It lists required and optional parameters but doesn't mention when to choose a paraboloid over other shapes (e.g., sphere for domes, cylinder for towers) or contextual factors like Minecraft building scenarios. This leaves the agent without usage context.

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

• playerC
  2.8/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 burden for behavioral disclosure. While it lists actions like 'send_message (chat to player)' and 'give_item (add to inventory)', it doesn't address critical behavioral aspects: whether operations require permissions, if they're reversible, what happens on errors, rate limits, or authentication needs. The mention of 'sequences' is helpful but insufficient for comprehensive transparency.

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

  Conciseness3/5

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

  The description is somewhat front-loaded with 'PLAYER management: info/location/communication/inventory/abilities/gamemode' but then becomes a dense list of actions without clear organization. The second sentence is overloaded with 12+ action types, making it less scannable. While not excessively verbose, the structure could be improved for readability.

  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 complex tool with 14 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error handling, permission requirements, or operational constraints. While the schema covers parameter definitions, the description fails to provide the contextual understanding needed for safe and effective tool invocation.

  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 the schema already documents all 14 parameters thoroughly. The description adds minimal value beyond the schema - it lists action types but doesn't provide additional context about parameter interactions or usage patterns. The baseline of 3 is appropriate when the schema does the heavy lifting.

  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 this is for 'PLAYER management' with specific operations like info/location/communication/inventory/abilities/gamemode, distinguishing it from sibling tools like blocks, build_*, or execute_command. However, it doesn't explicitly differentiate from send_message or sequence tools which also handle player interactions, keeping it from a perfect score.

  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 mentions 'Supports sequences for chained player operations' which hints at usage with the sequence tool, but provides no explicit guidance on when to use this tool versus alternatives like send_message or sequence. There's no mention of prerequisites, error conditions, or tool selection criteria.

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

• build_cubeC
  2.9/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 burden for behavioral disclosure. It states the tool 'builds' shapes and 'supports sequences for automation', but doesn't disclose whether this is a destructive operation, what permissions are needed, rate limits, or what happens if coordinates overlap existing structures. The description is insufficient for a mutation tool with zero annotation coverage.

  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 efficiently structured in two sentences: first states purpose with examples, second covers coordinate ranges and automation support. It's appropriately sized with no redundant information, though it could be slightly more front-loaded with the core functionality.

  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 9-parameter mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, coordinate system details beyond positive/negative values, or how 'sequences for automation' work. The description should provide more context given the tool's complexity and lack of structured metadata.

  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 the schema already documents all 9 parameters thoroughly. The description adds minimal value beyond the schema - it mentions coordinates 'can be positive or negative' and 'supports sequences for automation', but doesn't explain parameter interactions or provide additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.

  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 builds geometric shapes (cubes/rectangles) using two corner coordinates, with specific examples like 'box, rectangle, wall, platform, room, house frame'. It distinguishes from siblings by focusing on rectangular prisms, though it doesn't explicitly contrast with other shape-building tools like build_sphere or build_cylinder.

  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 provides no guidance on when to use this tool versus alternatives like build_sphere or build_cylinder. It mentions 'sequences for automation' but doesn't explain when this is preferable over other building methods. No exclusions or prerequisites are stated.

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

• build_hyperboloidC
  2.9/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 burden for behavioral disclosure. It states 'Build' which implies a write/mutation operation but doesn't mention permissions needed, whether it's destructive to existing blocks, rate limits, or what happens on success/failure. The description is minimal and lacks critical behavioral context for a construction 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 brief and front-loaded with the core purpose. However, the second sentence listing parameters feels somewhat redundant given the comprehensive schema. Overall efficient but could be more polished.

  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 construction tool with 10 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what gets built (blocks placed in world), success conditions, error handling, or how it differs from similar building tools. The agent would lack crucial context for proper use.

  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 the schema already documents all parameters thoroughly. The description lists required parameters but adds no additional meaning beyond what's in the schema (e.g., it doesn't explain relationships between parameters or provide usage examples). Baseline 3 is appropriate when schema does the heavy lifting.

  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 verb 'Build' and resource 'HYPERBOLOID' with specific examples (cooling tower, hourglass, nuclear tower), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like build_cylinder or build_paraboloid, which would require 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like build_cylinder or build_sphere. It lists required parameters but offers no context about appropriate use cases, prerequisites, or comparisons to sibling tools.

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

• build_torusC
  2.9/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 burden for behavioral disclosure. While 'Build TORUS' implies a creation/mutation operation, it doesn't describe what actually happens (e.g., whether blocks are placed in the world, if it's destructive to existing structures, permission requirements, or rate limits). The description lacks critical behavioral context for a building 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 efficiently structured in two sentences: one stating purpose with examples, another listing parameters. However, the first sentence could be more focused by removing some redundant examples (e.g., 'donut, ring, circular fountain' convey similar concepts).

  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 9-parameter building tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool actually produces (e.g., a 3D structure in the world), how it interacts with the environment, or what happens on execution. The parameter listing doesn't compensate for missing behavioral context.

  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 the schema already documents all 9 parameters thoroughly. The description lists required parameters but adds minimal value beyond what's in the schema (e.g., it doesn't explain relationships between parameters or provide additional context not in parameter descriptions). Baseline 3 is appropriate when schema does heavy lifting.

  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 builds a torus with specific examples (donut, ring, etc.), providing a specific verb+resource. However, it doesn't explicitly differentiate from sibling tools like build_sphere or build_cylinder, which would require mentioning unique torus characteristics beyond the examples given.

  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 provides no guidance on when to use this tool versus alternatives like build_sphere or build_cylinder. It lists required parameters but offers no context about appropriate use cases, prerequisites, or comparisons to sibling tools.

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

• execute_commandC
  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 carries full burden for behavioral disclosure. 'Execute a Minecraft command' implies a potentially powerful action but doesn't specify permissions required, whether commands are reversible, what happens on failure, or any rate limits. For a tool that could significantly alter game state, this is inadequate.

  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 maximally concise - a single sentence that communicates the core function without any wasted words. It's appropriately sized for a tool with one parameter and good schema documentation.

  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 that executes potentially powerful Minecraft commands with no annotations and no output schema, the description is insufficient. It doesn't explain what commands are valid, what permissions are needed, what happens on success/failure, or what the return value might be. Given the complexity of Minecraft command execution, more context is needed.

  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%, with the single parameter 'command' clearly documented in the schema. The description doesn't add any additional parameter information beyond what the schema provides, such as command syntax examples or valid command types. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 action ('execute') and the resource ('a Minecraft command'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its many siblings (like 'send_message', 'player', or 'world'), which all operate in the Minecraft context but perform different functions.

  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 provides no guidance on when to use this tool versus alternatives. With 18 sibling tools in the Minecraft ecosystem, there's no indication of whether this is for administrative commands, gameplay actions, or how it differs from tools like 'send_message' or 'player'.

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

• build_rotateB
  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 of behavioral disclosure. It mentions the tool 'rotate and copy,' implying a mutation operation that creates new structures, but doesn't specify behavioral traits such as whether it requires specific permissions, if it destroys the original structure, rate limits, or error handling. The description adds some context with examples but misses critical details for a mutation tool with many parameters.

  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 and well-structured, with two sentences that efficiently convey the purpose and examples. The first sentence states the core function, and the second provides illustrative use cases. There's no unnecessary verbosity, and it's front-loaded with the main action. However, it could be slightly more comprehensive given the tool's complexity.

  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 tool's complexity (13 parameters, 11 required, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral aspects like mutation effects, permissions, or output format, and doesn't compensate for the absence of annotations. While it states the purpose, it doesn't provide enough context for safe and effective use by an AI agent, especially for a tool with many parameters and no structured safety hints.

  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 description coverage is 100%, meaning all parameters are documented in the input schema. The description adds minimal value beyond the schema, as it doesn't explain parameter semantics, interactions, or provide additional context like how coordinates define regions or how rotation works practically. It mentions 'pivot point' which relates to origin parameters, but this is already covered in the schema. Baseline 3 is appropriate given high schema coverage.

  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: 'Rotate and copy a structure around a pivot point.' It specifies the verb ('rotate and copy'), resource ('structure'), and context ('around a pivot point'), with examples like buildings and decorations. However, it doesn't explicitly distinguish this from sibling tools like 'build_transform' or other build tools, which might offer similar transformation capabilities.

  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 provides implied usage guidelines through examples: 'Perfect for creating rotated copies of buildings, making symmetrical structures, or spinning decorations.' This suggests contexts like architectural design or decorative arrangements. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'build_transform' or other sibling tools), and doesn't mention prerequisites or exclusions.

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

• cameraB
  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 the full burden of behavioral disclosure. It mentions 'Requires cheats enabled,' which is a critical behavioral trait, but fails to describe other important aspects like whether actions are reversible, if there are rate limits, what happens on errors, or the visual/auditory effects of actions. For a tool with 19 parameters and no annotations, this is a significant gap.

  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 front-loaded with key actions and uses efficient bullet-like phrasing. However, the second sentence ('Perfect for filming...') is somewhat redundant with the first, and the structure could be tighter by integrating the cheats requirement earlier. Overall, it's concise but not perfectly structured.

  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 complexity (19 parameters, no annotations, no output schema), the description is incomplete. It lacks details on return values, error handling, prerequisites beyond cheats, and behavioral nuances. While it covers basic purpose and usage, it doesn't provide enough context for safe and effective tool invocation in a complex environment.

  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 the schema already documents all parameters thoroughly. The description lists action types (e.g., move_to, smooth_move) and mentions 'cinematic sequences,' adding some context beyond the schema, but it doesn't explain parameter interactions or provide examples. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 as controlling the camera with specific actions (move_to, smooth_move, etc.), distinguishing it from sibling tools like player or world. However, it doesn't explicitly differentiate from sequence (which might handle sequences differently) or other build tools, keeping it from a perfect 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 description implies usage for 'filming, showcasing builds, or creating camera movements' and states 'Requires cheats enabled,' providing some context. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., sequence for sequences, player for player-related actions) or when not to use it, leaving room for ambiguity.

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

• build_helixB
  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 full burden but only states what parameters are required/optional. It doesn't disclose behavioral traits like whether this is a destructive operation (likely yes, given it's a build tool), what permissions are needed, rate limits, or what happens when invoked (e.g., immediate construction, preview mode).

  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 efficiently structured in two sentences: first stating purpose with examples, second listing parameters. Every element serves a purpose with zero waste, though it could be slightly more polished in formatting.

  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 12-parameter build tool with no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and parameter categories but lacks important context about the tool's behavior, side effects, and relationship to other build tools, leaving significant gaps.

  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 the schema already documents all 12 parameters thoroughly. The description adds minimal value by listing which parameters are required vs optional but provides no additional semantic context beyond what's in the schema descriptions.

  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 builds HELIX/SPIRAL structures with specific examples (spiral staircase, corkscrew, DNA model, twisted tower), which distinguishes it from sibling tools like build_cube, build_sphere, etc. The verb 'Build' is explicit and the resource 'HELIX/SPIRAL' 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like build_cylinder or build_torus for similar curved structures. It lists required and optional parameters but gives no context about appropriate use cases or comparisons with sibling tools.

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

• build_transformB
  3.3/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 full burden. It describes what transformations are possible but doesn't disclose critical behavioral traits: whether this is a destructive operation (does it modify the source structure?), what permissions are needed, whether there are size/coordinate limits, what happens if transformations overlap existing structures, or what the output looks like. For a complex 12-parameter tool with no annotations, this is a significant gap.

  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 appropriately sized with three sentences. The first sentence states the core purpose, the second provides use cases, and the third offers popular options. Each sentence adds value, though the 'Popular options' section could be integrated more smoothly. It's front-loaded with the main functionality.

  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?

  Given the tool's complexity (12 parameters, no annotations, no output schema), the description is moderately complete. It covers the transformation types well and provides some parameter context, but lacks critical behavioral information about the operation's effects, constraints, and output. For a tool that manipulates game world structures, more context about side effects and limitations would be helpful.

  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 100%, so the baseline is 3. The description adds meaningful value by explaining transformation types with plain-language equivalents ('copy=duplicate, mirror_x=flip horizontally, scale_up=make 2x bigger') that go beyond the enum values. It also clarifies the material parameter's behavior ('leave empty to copy original blocks'). This provides helpful semantic context beyond the schema's technical 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 the tool transforms structures through copying, rotating, mirroring, or scaling, with specific examples like duplicating buildings and creating mirror images. It distinguishes from siblings by focusing on transformation of existing structures rather than building new shapes from scratch (like build_cube, build_sphere). However, it doesn't explicitly differentiate from build_rotate, which appears to be a sibling tool.

  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 provides implied usage context through examples ('Perfect for duplicating buildings, creating mirror images, or making scaled versions') and mentions 'popular options' for transformations. However, it doesn't explicitly state when to use this tool versus alternatives like build_rotate or when not to use it. No prerequisites or constraints are mentioned.

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

• build_sphereB
  3.4/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 full burden. It mentions the tool builds spheres and gives coordinate examples, but lacks critical behavioral details: it doesn't specify if this is a destructive operation (overwrites existing blocks), what permissions are needed, whether there are rate limits, or what happens on failure. For a construction tool with zero annotation coverage, this is a significant gap.

  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 appropriately sized and front-loaded with the core purpose. Every sentence adds value: the first defines the tool with examples, the second specifies parameters, and the third gives usage context. However, the initial list of synonyms ('ball, dome, round structure, planet, orb') is slightly redundant with 'SPHERE' in the name.

  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?

  Given the complexity (construction tool with 7 parameters), no annotations, and no output schema, the description is moderately complete. It covers the purpose, parameters at a high level, and usage context, but lacks behavioral transparency (e.g., destructive effects, error handling) and doesn't explain return values. This leaves gaps for an AI agent to safely invoke the tool.

  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 the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema: it mentions coordinates can be positive or negative with examples, and implies radius sizing (Small/Medium/Large), but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 builds spheres with specific examples (ball, dome, round structure, planet, orb) and mentions the required parameters (center coordinates + radius). It distinguishes from siblings like 'build_cube' and 'build_cylinder' by focusing on spherical structures, though it doesn't explicitly contrast with 'build_ellipsoid' or 'build_torus' which are also curved shapes.

  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 provides clear context for when to use this tool ('Perfect for domes, decorations, planets, bubbles') and implies usage by specifying coordinate ranges and examples. However, it doesn't explicitly state when not to use it or name alternatives among sibling tools (e.g., use 'build_ellipsoid' for non-uniform spheres or 'build_torus' for ring shapes).

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

• build_lineA
  3.6/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 mentions what the tool does ('build a straight line of blocks') but lacks critical behavioral details such as whether it overwrites existing blocks, requires specific permissions, has rate limits, or what happens on execution failure. The example adds some context but doesn't cover operational traits.

  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 appropriately sized with two sentences: the first states the core purpose with examples, and the second provides a concrete example with coordinates. It's front-loaded with the main functionality, though the example could be slightly more concise. Every sentence adds value without redundancy.

  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?

  Given the tool's moderate complexity (8 parameters, no output schema, no annotations), the description is adequate but incomplete. It explains what the tool does and provides an example, but lacks behavioral transparency, error handling information, and output expectations. For a building tool with multiple parameters, more operational context would be beneficial.

  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%, providing comprehensive parameter documentation. The description adds minimal value beyond the schema by mentioning 'blocks' and giving an example coordinate range, but doesn't explain parameter interactions, constraints, or provide additional semantic context. This meets the baseline for high 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?

  The description clearly states the tool's purpose with a specific verb ('build') and resource ('straight line of blocks between two points'), distinguishing it from sibling tools like build_cube or build_sphere by focusing exclusively on linear construction. It provides concrete examples of applications (paths, roads, fences, etc.) that reinforce its distinct functionality.

  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 implicitly suggests usage contexts through examples ('Perfect for paths, roads, fences, bridges...'), but does not explicitly state when to choose this tool over alternatives like build_cube or build_cylinder. It provides a clear example of a diagonal line use case, offering practical guidance without naming specific sibling tools or exclusion criteria.

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

• send_messageA
  3.6/5.0
  Behavior3/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 mentions that the message is sent to the 'connected Minecraft player', implying a real-time interaction, but doesn't cover aspects like rate limits, delivery confirmation, or error handling. It adds some context but leaves gaps in behavioral traits.

  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 front-loaded with the core purpose and includes a usage guideline, making it efficient. However, the second sentence could be more tightly integrated, and it slightly repeats the schema's emphasis on the required parameter, reducing optimal conciseness.

  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?

  Given the tool's low complexity (single parameter, no output schema, no annotations), the description is moderately complete. It covers the basic purpose and usage but lacks details on behavioral aspects like response handling or limitations, which would be beneficial for an AI agent in this context.

  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 description coverage is 100%, so the input schema already documents the 'message' parameter thoroughly. The description reinforces that 'ALWAYS provide a message parameter' but doesn't add semantic meaning beyond what the schema provides, such as examples or formatting tips, meeting the baseline for high coverage.

  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 action ('Send a chat message') and target ('to the connected Minecraft player'), which is specific and actionable. However, it doesn't explicitly distinguish this tool from sibling tools like 'execute_command' or 'player', which might also involve communication, so it misses full sibling differentiation.

  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 provides clear context for when to use this tool ('to communicate with the player about build progress or instructions'), which is helpful. It doesn't specify when not to use it or name explicit alternatives among the siblings, such as 'execute_command' for other types of commands, so it lacks full exclusion guidance.

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

• build_ellipsoidA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It clearly indicates this is a creation/mutation tool ('Build an ellipsoid'), but doesn't disclose important behavioral traits like whether it overwrites existing blocks, requires specific permissions, has rate limits, or what happens on failure. The example helps but doesn't cover behavioral aspects.

  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 appropriately sized with three sentences that each earn their place: stating the purpose, providing use cases, and giving an example. It's front-loaded with the core functionality. Could be slightly more concise by combining some concepts, but overall efficient.

  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 9-parameter creation tool with no annotations and no output schema, the description provides adequate purpose and context but lacks important behavioral information. It doesn't explain what the tool returns, error conditions, or mutation implications. Given the complexity and lack of structured safety information, more completeness would be helpful.

  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?

  With 100% schema description coverage, the baseline is 3. The description adds some value by explaining that different radii create unique shapes and providing an example with specific values, but doesn't add significant semantic meaning beyond what's already well-documented in the schema descriptions for each parameter.

  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 builds an ellipsoid structure, specifying it's a stretched/oval sphere. It distinguishes from siblings like build_sphere by emphasizing different radii create unique shapes, and provides concrete use cases (egg shapes, stretched domes, oval rooms, artistic sculptures).

  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 provides clear context for when to use this tool (for egg shapes, stretched domes, oval rooms, artistic sculptures) and distinguishes it from build_sphere by mentioning different radii. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among siblings like build_hyperboloid or build_paraboloid.

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

• sequenceA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's an execution tool for chaining actions, supports timing control with 'wait_time', includes error handling options ('on_error for handling failures'), and lists supported tool categories. However, it doesn't mention potential side effects, rate limits, or authentication requirements.

  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 efficiently structured with zero waste: first sentence states core purpose, second provides use case example, third lists supported tools, and fourth highlights key parameters. Every sentence adds essential information without redundancy.

  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 complex orchestration tool with no annotations and no output schema, the description provides good context about what the tool does, when to use it, and behavioral aspects. However, it doesn't explain what happens after execution (e.g., success/failure responses) or potential constraints, leaving some gaps in 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?

  With 100% schema description coverage, the baseline is 3. The description adds some value by mentioning 'wait_time for delays, on_error for handling failures' and providing a concrete example, but doesn't significantly enhance parameter understanding beyond what's already documented in the detailed schema descriptions.

  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's purpose with specific verbs ('Execute CROSS-TOOL SEQUENCES', 'Chain actions from multiple tools together with timing control') and distinguishes it from sibling tools by explaining it orchestrates actions from tools like player, agent, camera, etc. rather than performing individual actions directly.

  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 provides clear context for when to use this tool ('Perfect for complex automation' with examples) and mentions it 'Supports all tools' with a list, but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for simpler cases.

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

• minecraft_wikiA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It effectively describes key behaviors: the tool returns accurate, up-to-date information from the official wiki, excludes Java Edition features, and recommends sequence-based approaches to manage response complexity. It doesn't mention rate limits, authentication needs, or error handling, but provides substantial operational guidance.

  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 and front-loaded with core functionality, followed by usage recommendations. Every sentence adds value: the first establishes scope, the second addresses data quality, the third provides operational guidance. It could be slightly more concise but maintains good information density without redundancy.

  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 complex tool with 7 parameters, no annotations, and no output schema, the description provides substantial context about scope, data sources, and recommended usage patterns. It doesn't describe return formats or error conditions, but given the schema's comprehensive parameter documentation and the description's operational guidance, it's reasonably complete for an information retrieval tool.

  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 the schema already documents all 7 parameters thoroughly. The description adds minimal parameter-specific information beyond what's in the schema - it mentions using 'sequence' for step-by-step gathering but doesn't explain parameter interactions or provide examples beyond what the schema already contains. Baseline 3 is appropriate when schema does heavy lifting.

  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 searches the Minecraft Wiki for specific editions (Bedrock and Education) and content types (commands, blocks, items, entities, mechanics), explicitly excluding Java Edition features. It distinguishes itself from sibling tools like 'execute_command' or 'blocks' by focusing on information retrieval rather than game interaction.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool versus alternatives: it specifies using the 'sequence' action for step-by-step information gathering to avoid overwhelming responses, and outlines a specific workflow (search → get page → get section). This gives clear operational context beyond basic tool invocation.

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