Server Quality Checklist

Tool Scores

• minecraft_activate_blockB
  3.3/5.0
  Behavior4/5

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

  The description discloses that the agent 'walks within reach first' and lists error conditions ('no block there, or unreachable'). Annotations already indicate readOnly=false and destructive=false. The added behavior about movement and error handling goes beyond the structured data, providing useful context.

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

  Conciseness5/5

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

  The description is concise and front-loaded: two sentences cover the action and examples, followed by return value and error conditions. Every sentence adds useful information 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?

  The description covers the core purpose, behavior, and errors, and annotations provide safety profile. However, it omits details like coordinate system and does not address the overlapping functionality with sibling tools (e.g., open_container, use_furnace), which could lead to incorrect tool selection in complex scenarios.

  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%, leaving all three parameters (x, y, z) undocumented. The description only refers to them as 'given coordinates' without further detail, such as coordinate system, type, or valid ranges. This is insufficient for an agent to confidently provide correct values.

  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 right-clicks a block at coordinates and lists examples (chests, doors, buttons, levers). It is specific with a verb and resource, but does not explicitly distinguish itself from sibling tools like minecraft_open_container or minecraft_use_furnace, which could overlap.

  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 explicit guidance is given for when to use this tool versus alternatives. It implies general block activation, but there is no mention of when not to use it or which sibling tools might be preferred for specialized interactions (e.g., open_container, use_furnace).

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

• minecraft_toss_itemB
  3.4/5.0
  Behavior3/5

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

  The annotations already declare destructiveHint=true and openWorldHint=true. The description adds value by specifying the drop location ('in front of the bot') and the effect (removal from inventory), but does not disclose whether the item persists, can be recovered, or if there are any restrictions. This is some added context but not a complete behavioral disclosure.

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

  Conciseness5/5

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

  The description is exceptionally concise: two sentences that immediately state the core action and the return type. Every word adds value, and it is front-loaded with the verb and resource.

  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 drop-item tool, the description provides enough core information, but there are gaps: what happens to the dropped item (disappears or can be picked up), any restrictions on item types, and how 'in front' is determined. No output schema exists, so the return type statement is helpful, but more behavioral nuance would improve completeness.

  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 only 50% (count has a description, item_name does not). The description does not explicitly explain item_name or its format; it only says 'item(s)' which weakly implies the meaning. Given the low coverage, the description should compensate more but does not.

  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 a specific verb ('Drops') and clearly identifies the resource ('item(s) from inventory') and destination ('onto the ground in front of the bot'). This distinguishes it from sibling tools like container_deposit or give_item, which target different destinations.

  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. It lacks any mention of context, prerequisites, or exclusions, leaving the agent to infer usage solely from the purpose statement.

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

• minecraft_equip_itemA
  3.8/5.0
  Behavior3/5

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

  Annotations provide the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds the return format (message string) and a specific error condition (item not found in inventory). However, it doesn't disclose what happens to the previously equipped item or whether the item is consumed/removed from inventory, which could be relevant for the agent. This adds some value but not rich behavioral context.

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

  Conciseness5/5

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

  The description is two concise sentences: the first states the purpose, the second provides return/error info. Every word is useful, with no fluff or repetition. It is front-loaded with the main action, making it easy to scan.

  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 equip action, the description covers the core functionality, return type, and a likely error. The schema provides destination enum/default, and annotations clarify the safety profile. While it could mention side effects like item replacement or consumption, the lack of an output schema and the tool's simplicity make this reasonably complete. A small gap, but not a major omission.

  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 clarifies that 'item_name' refers to an item in inventory and 'destination' refers to hand or armor slots, but it doesn't explicitly mention the parameter names or the enum/default values. The description adds some meaning beyond the bare schema, but could be more explicit about how the two parameters map to the action.

  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 a specific verb 'Equips' and clearly identifies the resource: item from inventory to the bot's hand or an armor slot. This distinguishes it from sibling tools like 'use_held_item' or 'move_item_slot' by indicating it's about changing what the bot holds/wears, not using or moving items.

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

  Usage Guidelines3/5

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

  The description implies the tool is used when you want to equip an item (to hand or armor), but it doesn't explicitly state when to prefer this over alternatives like 'move_item_slot' or 'give_item'. No exclusion criteria or alternate conditions are provided, so usage context is only implied.

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

• minecraft_goto_playerA
  3.9/5.0
  Behavior4/5

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

  The description adds 'Blocking call' and error conditions (player not found/not loaded, unreachable), which go beyond the annotations. Annotations only cover read-only/destructive/idempotent hints, so the description carries the burden of conveying blocking behavior and failure modes. No contradiction with annotations.

  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?

  Three concise sentences cover purpose, return value, and errors. The description is front-loaded with the main action, and every sentence adds value 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?

  The return value and error cases are stated, and blocking behavior is noted. However, the 'range' parameter is not described, and there is no elaboration on how the 'near' behavior works. Given the tool's simplicity, this is mostly complete but has a notable gap in parameter semantics.

  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%, yet the description does not explain the 'range' parameter or the meaning of 'near'. The username is implicitly referenced as 'named online player' but not explicitly mapped to the parameter, leaving the numeric range undocumented.

  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 'Paths the bot to stand near a named online player', using a specific verb and resource. It distinguishes from siblings like minecraft_goto_position (coordinates) and minecraft_follow_player (continuous following).

  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 use case is implied by 'named online player', but there is no explicit mention of when to use this tool versus alternatives such as goto_position or follow_player. It provides context that it blocks until arrival but lacks exclusionary guidance.

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

• minecraft_give_itemA
  4/5.0
  Behavior4/5

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

  The description goes beyond the annotations by stating the creative-mode constraint, the direct insertion into inventory, and listing specific error conditions (not in creative mode, unknown item id, inventory full). This provides useful operational context. No contradiction with annotations (readOnlyHint=false, destructiveHint=false) was found.

  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 exceptionally concise: a single sentence for the purpose and a short list for returns/errors. Every sentence earns its place with no filler or repetition.

  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 tool with no output schema, the description covers the action, the precondition (creative mode), the return value, and common errors. It is sufficient for an agent to understand the tool's behavior, though the exact format of the returned message is not specified.

  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 already describes item_name and slot well (67% coverage), and the description does not add additional parameter-specific meaning, especially for 'count' which lacks a schema description. The default and limits are in the schema, so the description adds little beyond what structured data provides.

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

  Purpose5/5

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

  The description clearly states it spawns an item stack directly into the bot's inventory, using the specific verb 'spawns' and identifying the resource. It also includes the creative-mode requirement, which distinguishes it from sibling tools like minecraft_toss_item or minecraft_craft_item.

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

  Usage Guidelines3/5

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

  The description mentions the prerequisite that the bot must be in creative mode, which gives clear context for when the tool can be used. However, it does not explicitly compare with alternatives (e.g., using craft_item or collect_block) or state when not to use it, so guidance is limited.

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

• minecraft_read_signA
  4/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds the return shape { x, y, z, front, back } where back can be null. However, it does not disclose error behavior if the block is not a sign or whether the sign must be in a loaded chunk. The return format is valuable since no output schema exists.

  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 compact two sentences with the purpose in the first sentence and the return shape in the second. No unnecessary words or redundancy with annotations.

  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 read tool with good annotations, the description provides purpose and return shape, but it omits parameter semantics and failure behavior. Since there is no output schema, the return shape is covered, but the lack of error handling or coordinate details leaves gaps.

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

  Parameters2/5

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

  The schema has 0% description coverage; x, y, z are typed as numbers with no descriptions. The description only refers to 'the given coordinates,' adding no further meaning about coordinate system or units. It does not compensate for the schema's lack of parameter 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 'Reads the text written on a sign at the given coordinates,' using a specific verb and resource. This distinguishes it from sibling read tools like minecraft_get_block_at, which would return block types rather than sign text. The title 'Read Sign Text' reinforces the purpose.

  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 implies usage when needing sign text from a specific location, but it does not explicitly contrast with alternatives such as minecraft_get_block_at or minecraft_get_nearby_blocks. There are no exclusions or when-not-to-use guidance, so it falls at 'clear context, no exclusions.'

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

• minecraft_till_soilA
  4/5.0
  Behavior4/5

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

  The description adds behavioral context beyond annotations: it equips a hoe, walks within reach first, returns a message, and lists error conditions. It does not contradict the annotations (readOnlyHint=false, destructiveHint=false) and provides useful execution details. It could disclose more (e.g., hoe durability, whether tilling affects block states beyond farmland), but for a simple tool it is adequately transparent.

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

  Conciseness5/5

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

  The description is concise and front-loaded. The first sentence conveys the primary purpose, the second adds a key behavioral detail (walking), and the final section lists return/error outcomes. There is no redundancy or irrelevant information; every sentence earns its place.

  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 tool with no output schema and minimal annotations, this description is fairly complete. It covers the core action, a prerequisite (hoe), a behavioral note (walking), and likely error cases. It does not explain the coordinate system in detail, which could be a minor gap, but given the simplicity and domain familiarity, it is adequately complete.

  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 for parameter semantics. It states 'at the given coordinates', which informs the agent that x, y, and z are Minecraft world coordinates specifying a block. However, it does not detail each parameter individually (e.g., y is vertical, coordinates are absolute). This is sufficient for a Minecraft domain but leaves room for interpretation, hence a middle score.

  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 action: 'Equips a hoe and tills the dirt/grass block at the given coordinates into farmland, ready for planting.' This uses a specific verb ('tills'), a specific resource ('dirt/grass block'), and a clear outcome ('farmland'). It distinguishes itself from sibling tools like plant_seed, dig_block, and place_block by focusing solely on tilling.

  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: preparing a block for planting by tilling dirt/grass into farmland. It does not explicitly state when to use versus alternatives, but the tool is unique among siblings and the description's mention of 'ready for planting' suggests its purpose. Errors indicate conditions to avoid, like 'already farmland', providing some negative guidance, though not explicitly framed as usage guidelines.

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

• minecraft_whisperA
  4/5.0
  Behavior3/5

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

  Annotations already indicate the tool is not read-only and not destructive, and the description adds context about using /msg or /tell. However, it doesn't disclose potential failure modes (e.g., player offline) or message length limits beyond the schema. It adds some value but could be richer.

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

  Conciseness5/5

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

  The description is two sentences, with the purpose front-loaded and the return value clearly noted. There is no unnecessary information, making it efficient and easy to parse.

  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 tool with two plain parameters and no output schema, the description covers the essential aspects: purpose, privacy, command mechanism, and return format. It doesn't elaborate on error handling or edge cases, but given the tool's simplicity and the annotations provided, it is sufficiently complete.

  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 not explicitly explain the parameters, though 'sends a private message to a specific player' implies a recipient (username) and content (message). The return value '{ message: string }' is mentioned, but no additional semantics are provided. The parameter names are self-evident, so the lack of detail is acceptable but not exemplary.

  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 function: sending a private message to a specific player, visible only to them. It uses a specific verb ('sends') and specifies the resource (player) and scope (private), distinguishing it from sibling tools like minecraft_chat. Mentioning the server's /msg or /tell equivalent adds clarity.

  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 implies when to use this tool: for private, player-specific messages rather than public chat. It doesn't explicitly state 'use this instead of chat when privacy is needed' or provide exclusion criteria, but the context is clear enough for an agent to infer the appropriate use case.

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

• minecraft_disconnectA
  4.1/5.0
  Behavior3/5

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

  Annotations already provide idempotentHint=true and destructiveHint=false, and the description reinforces idempotent safety by saying it is safe if not connected. The word 'cleanly' adds a subtle behavioral promise, but no new side effects or prerequisites are disclosed beyond what annotations already imply.

  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 immediately convey the purpose and the key safety trait, with no unnecessary words. The information is 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.

  Completeness5/5

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

  Given the tool's simplicity (no parameters, no output schema), the description completely covers what the agent needs to know. The combination of description and annotations is sufficient for a disconnect action without any clear gaps.

  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, so the description is not required to explain any parameter details. The baseline of 4 is appropriate because the schema already covers everything (100% coverage) and there are no params to clarify.

  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 ('disconnects') and the resource ('current world/server'), and the phrase 'cleanly disconnects' distinguishes it from sibling tools like connect and stop. It also adds a helpful safety note, making the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description notes that it is safe to call even if not connected, which implies it can be used as a cleanup step, but it does not explicitly mention when to prefer this over minecraft_stop or minecraft_connect. No alternatives or exclusions are given, leaving some inference to the agent.

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

• minecraft_get_light_atA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare the tool as read-only, open-world, idempotent, and non-destructive. The description adds value by specifying the return format (light and skyLight ranges 0-15) and the mob spawn rule, enhancing behavioral understanding beyond annotations.

  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, leading with the core function, then adding a practical use case and return format snippet. Every sentence earns its place with no unnecessary fluff.

  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 read-only tool with three numeric coordinates, the description effectively covers the purpose, return structure, and a relevant rule. The only noticeable omission is explicit parameter definitions, but the Minecraft context makes the coordinates fairly clear.

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

  Parameters2/5

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

  The input schema has 0% description coverage, and the description does not explicitly define x, y, and z. It only implies they are block coordinates through the phrase 'at a block' and the echoed output. This is a significant gap for an agent that needs precise parameter semantics.

  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 states 'Returns light levels at a block' with a specific resource and action. It clearly distinguishes from siblings like minecraft_get_block_at and minecraft_get_biome_at by focusing solely on light levels.

  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 gives a clear use case: 'useful for checking if an area is safe from mob spawns'. This provides context on when to use the tool, though it does not explicitly name alternatives or exclusions.

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

• minecraft_harvest_cropA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true, but the description adds valuable behavioral context: it checks maturity for known crop types and refuses to harvest early unless force=true. It also lists potential errors ('nothing there, crop not fully grown, or not diggable'). This goes beyond the annotations and informs the agent about the tool's safety checks and failure modes.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, then elaborates on maturity behavior and includes return/error info. Every sentence adds value, no fluff or repetition of schema/annotation content. It is concise and well-structured.

  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 tool with four parameters and no output schema, the description covers the main behavior, the force flag, return shape, and error conditions. It could mention what happens to the harvested crop (e.g., it drops into inventory) but that is generally implied by 'harvest'. The description is adequate for an agent to use it correctly without additional context.

  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 only 25% (only force has a description). The description mentions 'given coordinates' but does not explain the meaning of x, y, z (e.g., coordinate system, ordering, or units). It does clarify force=true as a way to bypass maturity checks, but the core positional parameters remain underdocumented. With low schema coverage, the description should compensate more, especially for x, y, z.

  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: 'Breaks a fully-grown crop block at the given coordinates.' It distinguishes itself from siblings like dig_block or collect_block by focusing on crops and maturity checking. The mention of known crop types and the force parameter further clarifies its specialized purpose.

  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 that this is for harvesting fully-grown crops, and implies it should be used when a crop is ready to harvest. However, it does not explicitly mention alternatives or when not to use it, such as for non-crop blocks or when you want to force harvest (which is covered by force=true). The context is clear but lacks explicit exclusions or alternative tool references.

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

• minecraft_place_blockA
  4.1/5.0
  Behavior4/5

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

  Beyond annotations (mutation, not idempotent), the description discloses auto-walking, the requirement for a solid neighbor, and the empty-space prerequisite. It also lists specific errors, adding transparency about limitations and failure modes.

  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 thorough yet concise, with each sentence providing meaningful detail (behavior, constraints, returns, errors). Structure is front-loaded with the core action and followed by necessary conditions and expected outcomes.

  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 tool with 4 parameters and no output schema, the description covers the essential behavioral contract, constraints, and error cases. It doesn't mention nuances like block orientation, but given the simplicity of the tool, the description is sufficiently complete.

  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 coverage is low (only block_name described). The description only mentions 'world coordinates' without clarifying the coordinate system or format for x, y, z. It does not compensate adequately for the missing schema descriptions of these parameters.

  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 places one block from inventory at given world coordinates, distinguishing it from sibling tools like minecraft_build_structure. The specific behavior of auto-walking and finding a solid neighbor further clarifies its unique purpose.

  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?

  Provides clear context for when this tool is appropriate: placing a single block at an empty, solid-adjacent location. It also implies you don't need to be in position due to auto-walking, but it doesn't explicitly contrast with alternatives like build_structure or place multiple blocks.

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

• minecraft_set_sprintA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate idempotentHint=true and non-read-only behavior. The description adds non-obvious behavioral context: sprint state persists until toggled off or the bot stops. This is valuable beyond the schema and does not contradict any annotations.

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

  Conciseness5/5

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

  The description is two short sentences with no redundant wording. It is front-loaded with the core action and adds only the essential behavioral detail. Every word earns its place.

  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 simple boolean toggle with solid annotations and no output schema, the description covers the necessary context: what it sets, and how long the state persists. The lifecycle detail ('until toggled off or the bot stops') is complete enough for an agent to understand the tool's effect.

  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 only parameter, sprint (boolean), has 0% schema description coverage, but the description compensates by explaining that the parameter controls whether sprinting is on or off. This directly maps true/false to the intended behavior, which is sufficient for a single boolean 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 specific action: 'Turns sprinting on or off.' It names the resource (sprint) and the behavior (on/off toggle), distinguishing it from sibling tools like minecraft_set_sneak. The added detail about persistence further clarifies the tool's scope.

  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 on when to use this tool versus alternatives such as set_sneak or jump. There are no exclusions, prerequisites, or contextual hints about when sprinting is appropriate, leaving the selection entirely to the agent.

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

• minecraft_container_withdrawA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=false and openWorldHint=true, so the description's mutation behavior is consistent. It adds error cases ('no container open, or item not present') and return shape ('{ message }'), providing useful context beyond annotations.

  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-sentence description plus return/error lines, no redundancy. Every sentence adds value: operation, prerequisite, and failure modes.

  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 straightforward withdrawal action with clear prerequisites and errors, the description covers the essential operational context. It omits post-withdrawal container state but that is inferable from the schema and sibling tools; not a significant gap.

  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 describes count as 'Omit to withdraw the entire stack found' and requires item_name with minLength. The description does not elaborate on parameters, but the tool's purpose makes item_name obvious; count semantics are already in schema. At 50% schema coverage, this is adequate but not exemplary.

  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 explicitly states 'Moves an item from the currently open container into the bot's inventory' – a specific verb, resource, and direction. This clearly distinguishes it from siblings like minecraft_container_deposit and minecraft_toss_item.

  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?

  Mentions prerequisite 'Call minecraft_open_container first' which tells when this tool is valid. Does not explicitly name alternatives but the direction (from container to inventory) contrasts with deposit, making usage context clear.

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

• minecraft_find_blockA
  4.2/5.0
  Behavior4/5

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

  Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already convey the safety profile. The description adds value by specifying the outward search behavior and the exact return format (found, count, blocks with x/y/z/name/distance), which is especially important since there is no output schema. It does not disclose internal details like search radius or failure behavior, but it supplements annotations well.

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

  Conciseness5/5

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

  The description is two sentences: the first delivers the main purpose with examples, and the second provides a compact return structure. There is no redundancy or filler. It is front-loaded with the core action and is easy to scan.

  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 read-only search tool with no output schema, the description sufficiently covers purpose, usage, and return format. It lacks explicit mention of the max_distance parameter's role (though the schema and parameter name hint at it) and does not address edge cases like 'no block found'. Given the tool's simplicity and strong annotations, these omissions are minor, making the description complete enough for most use cases.

  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 67% (count and block_name have descriptions; max_distance does not). The tool description does not add any parameter-level detail beyond the schema, and notably fails to clarify the meaning of max_distance. However, the schema already provides sufficient explanations for the common parameters, and the parameter names (max_distance) are fairly self-explanatory. The description's return format mentions 'distance', but that does not directly address parameter semantics. Overall, the description neither compensates for gaps nor adds extra value, so a baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Searches outward from the bot for the nearest block(s) matching a given block name.' This identifies the specific action (search), resource (block), and scope (nearest/outward). It also provides concrete use cases ('find me some water' / 'find diamond ore') which distinguish it from general block queries like get_nearby_blocks. The verb+resource+scope are explicit, making the purpose unambiguous.

  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 usage context: 'useful for ... before navigating or mining.' This signals when to use the tool, but it does not explicitly state exclusions or mention alternatives such as minecraft_get_nearby_blocks. Since it gives a clear context without saying when not to use it, it earns a 4 rather than a 5.

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

• minecraft_look_atA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare openWorld, idempotent, not destructive, and not read-only. The description adds valuable context beyond that: 'Purely cosmetic/aiming — doesn't move the bot.' This clarifies the effect on position, which is critical for a bot control tool. It does not contradict annotations. It doesn't disclose other potential side effects but none seem relevant for this simple action.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core action. Every word earns its place: action, effect ('doesn't move'), use cases. No redundancy or fluff.

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

  Completeness4/5

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

  The tool is simple, but the description covers purpose, behavioral effect, and use cases. The lack of output schema is fine. The main gap is parameter semantics, which are not explained, but the description's clarity about 'point' and the typical context make it sufficiently complete for an agent to select and invoke it correctly. It also aligns well with sibling tools 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 has 0% coverage, so the description must compensate for x, y, z. The phrase 'face a specific point' implies x, y, z are coordinates of that point, but it gives no details about coordinate system, units, or whether they are absolute. This is minimal but adequate given the tool's simplicity and the conventional meaning of x/y/z in a game context.

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

  Purpose5/5

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

  The description uses a specific verb ('Turns') and resource ('bot's head/body') to clearly state the action. It also distinguishes from siblings by noting it aims at a point rather than moving, which sets it apart from movement tools and even minecraft_look_direction (which likely sets a direction). The purpose is unambiguous.

  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?

  Explicitly states when to use: 'Useful before minecraft_attack_entity or minecraft_activate_block for precision.' It also clarifies what it does NOT do ('doesn't move the bot'), implying when not to use it (for movement). However, it does not mention alternatives like minecraft_look_direction or explicitly state exclusions beyond movement.

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

• minecraft_move_item_slotA
  4.2/5.0
  Behavior3/5

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

  Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds a valuable slot map and a return message type, but does not disclose edge-case behaviors such as whether items swap or stack when the target slot is occupied, nor what the message content means. No contradiction with annotations.

  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 front-loaded: first the action, then the slot map, then the return type. No wasted words or redundant repetitions of the schema.

  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 2-parameter tool the description is mostly adequate, but it omits important operational details: what happens when moving to a non-empty slot (swap, stack, or drop), behavior on invalid slots, and the meaning of the returned message. Since there is no output schema, the vague 'Returns: { message }' does not fully satisfy the need for return-value documentation.

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

  Parameters5/5

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

  The input schema only provides integer ranges, but the description fully compensates by mapping every slot number to an inventory region (0 crafting output, 1-4 crafting grid, 5-8 armor, 9-35 main inventory, 36-44 hotbar, 45 off-hand). This makes the parameters' meaning explicit and actionable.

  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 ('Moves an item stack'), the resource ('inventory slot'), and the purpose ('for organizing the hotbar/inventory'). It distinguishes itself from sibling tools by focusing on internal inventory reorganization rather than tossing, equipping, or container transfers.

  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 phrase 'for organizing the hotbar/inventory' provides a clear context for when to use this tool. However, it does not explicitly mention when not to use it or point to alternatives like container_deposit/withdraw for container-related moves.

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

• minecraft_plant_seedA
  4.2/5.0
  Behavior4/5

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

  The description adds meaningful behavioral details beyond the annotations: it requires farmland/soul sand, may fail if the space above is occupied, and checks inventory for the seed. It also discloses return type and possible errors, which is especially useful given the sparse annotations (only openWorldHint true). No contradiction found.

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

  Conciseness5/5

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

  The description is concise and well-structured: a clear one-sentence purpose, a parenthetical prerequisite, a list of supported items, and a brief returns/errors section. Every sentence adds value without unnecessary padding.

  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 tool with four parameters, no output schema, and minimal annotations, the description covers the core behavior, valid inputs, required preconditions, and failure modes. It does not explicitly state whether the seed is consumed or the exact message format, but these are minor compared to what is provided. Overall, it gives sufficient context for an agent to use the tool correctly.

  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 low (25%) with only seed_item described. The description compensates partially by expanding valid seed_item examples ('carrots, potatoes, beetroot_seeds, melon/pumpkin seeds, nether_wart') and adding context about soul sand, but x, y, z semantics remain implicit (they are just 'given coordinates'). This is adequate but not fully compensating for the coverage gap.

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

  Purpose5/5

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

  The description clearly states the verb 'Plants' and the resource 'a seed item on farmland at given coordinates', with a parenthetical note to till first. It distinguishes itself from related sibling tools like minecraft_till_soil and minecraft_harvest_crop by specifying the planting action and supported plantable items.

  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 explicit usage context by instructing to 'till it first with minecraft_till_soil' and lists which items are plantable, including nether_wart on soul sand. It does not explicitly state when not to use the tool, but the scope is clear enough for an agent to select it appropriately.

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

• minecraft_set_sneakA
  4.2/5.0
  Behavior4/5

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

  The description adds behavioral context beyond the annotations: it discloses that sneaking prevents falling off edges and hides the bot's nametag from some mobs. This is useful and not contradictory to the idempotentHint and openWorldHint annotations, though it does not describe server-side effects or response behavior.

  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, well-structured sentence that front-loads the verb and purpose. It contains no filler and every word contributes meaning.

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

  Completeness4/5

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

  Given the low complexity (one boolean parameter, no output schema), the description covers the key behavioral effects and purpose. It lacks explicit when-to-use vs alternatives, but that is a minor gap for a simple toggle tool. The effects mentioned (fall prevention, nametag hiding) enrich the context beyond the schema.

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

  Parameters4/5

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

  With one boolean parameter and 0% schema description coverage, the description compensates by explaining that the tool turns sneaking on or off, which directly maps to the boolean value (true=on, false=off). It does not explicitly name true/false, but the meaning is clear and sufficient for a single 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 states precisely that the tool turns sneaking (crouching) on or off, with a specific verb and resource. It also distinguishes itself from the similar sibling tool minecraft_set_sprint by detailing unique effects (preventing falls, hiding nametag from mobs).

  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 when to use the tool (when you want to avoid falling or hide from mobs) but does not explicitly compare it to alternatives like minecraft_set_sprint or provide exclusion criteria. It is usable but not fully explicit.

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

• minecraft_shoot_bowA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark the operation as destructive/open-world, and the description adds valuable context: full draw damage scaling, short draw behavior, return message, and 'no bow' error. It does not mention arrow consumption or possible block damage, but this goes beyond the annotation flags.

  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 compact sentences plus a return/error line convey the action, damage trade-off, and failure case without redundancy. The structure is front-loaded with the verb sequence and keeps each line purposeful.

  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 4-parameter tool with no output schema, the description covers the main behavior, return message, and primary error. A notable gap is arrow requirements/consumption—critical in Minecraft—but the overall picture is still well-rounded.

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

  Parameters4/5

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

  Schema coverage is 0%, but the description explicitly names the target point (target_x/y/z) and charge_ms, connecting them to aiming and draw duration. This compensates for the empty schema descriptions, though coordinate conventions and charge_ms units are left to the schema's integer type/default.

  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 a specific verb sequence—equips, aims, draws, fires—tied to a distinct resource (bow), clearly distinguishing it from siblings like minecraft_attack_entity or minecraft_use_held_item.

  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 (firing a bow with charge mechanics) is implied clearly, but the description provides no explicit when-to-use or when-not-to-use guidance relative to sibling tools. It would be stronger with an alternative such as 'use minecraft_attack_entity for melee attacks'.

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

• minecraft_sleepA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate this is a mutating, non-idempotent, non-destructive world interaction. The description adds valuable context about time-of-day constraints, safety checks, and explicit error conditions, going beyond the structured metadata.

  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, using two sentences for the main behavior and a concise return/errors list. Every sentence adds meaningful 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?

  Given the lack of output schema and parameter descriptions, the description covers the essential behavior, conditions, return format, and error cases. It does not fully detail edge cases like occupied beds or exact coordinate semantics, but it is substantially complete for a tool of this complexity.

  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 0% schema description coverage, the description partially compensates by explaining that coordinates are optional and used to target a specific bed instead of the nearest one. However, it does not clarify whether partial coordinate triples are allowed or the exact meaning of numeric values.

  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 action: finding the nearest bed (or at given coordinates) and sleeping in it. This specific verb+resource distinguishes it from all sibling tools, none of which overlap with sleeping.

  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?

  It explicitly states when the tool works (night/thunderstorms) and necessary conditions (bed safe, no monsters). While it doesn't mention alternatives, there is no other sleep tool among siblings, so the context is sufficient.

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

• minecraft_tradeA
  4.2/5.0
  Behavior4/5

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

  The annotations already indicate this is a non-read-only, non-idempotent operation with no destructive world effects. The description adds valuable behavioral context by stating the stateful prerequisite (currently open villager) and enumerating specific error scenarios. It also states the return format as a simple message. That said, it does not explicitly mention that the trade consumes or produces items, which would further clarify the change in 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 compact, with the action and precondition in the first sentence, followed by a clear Returns/Errors structure. No filler or redundancy; every clause adds operational 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?

  Given the lack of an output schema, the description still covers the return value as { message } and lists common failure modes. The tool's simplicity and the annotations reduce the need for extensive explanation. It could be more complete by describing the inventory effect of a trade, but overall it provides sufficient context for basic usage.

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

  Parameters3/5

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

  The schema documents the 'times' parameter with a description and range, but 'trade_index' has no schema-level description. The description's 'by trade index' provides minimal additional meaning, and the error list mentions 'invalid trade index', reinforcing validation. However, it does not clarify whether the index is zero-based or one-based, and it adds little beyond what the parameter name implies.

  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 'Executes' with the resource 'trade' and includes the precondition of an open villager, clearly distinguishing it from sibling tools like minecraft_open_villager or minecraft_use_held_item. It also mentions the trade index parameter directly. This leaves no ambiguity about the tool's function.

  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 explicitly states 'call minecraft_open_villager first', which is a direct prerequisite. It also lists error conditions such as 'no villager open' and 'missing required items', informing the agent when the tool will fail. However, it does not discuss alternatives or exclusion cases beyond the prerequisite, so it lacks some of the comparative guidance seen in higher-scoring examples.

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

• minecraft_attack_entityA
  4.3/5.0
  Behavior4/5

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

  Beyond annotations (destructiveHint, etc.), the description discloses that the tool performs a single weapon swing, requires the entity to be in reach (out of reach error), and may fail if no hostile mob is nearby. This adds meaningful behavioral context about how the attack executes.

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

  Conciseness5/5

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

  The description is concise and well-structured. The first sentence states the action and target selection, the second explains the attack mechanic, and the return/errors are clearly labeled. No superfluous words.

  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 tool with one optional parameter and no output schema, the description is complete: it specifies input source, behavior, return type, and possible errors. This gives the agent all necessary information to invoke and interpret the tool correctly.

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

  Parameters3/5

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

  The input schema already has 100% coverage, describing entity_id as 'Entity id from minecraft_get_nearby_entities. Omit to attack nearest hostile mob.' The tool description repeats this information without adding extra parameter semantics, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool attacks a specific entity by id or the nearest hostile mob if omitted. It includes the source of the id (minecraft_get_nearby_entities) and distinguishes this attack action from other tools by specifying the single-swing behavior.

  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 gives clear usage context: use the entity_id from minecraft_get_nearby_entities, or omit to attack the nearest hostile mob. It also advises calling repeatedly for multiple hits. No explicit alternatives or exclusions are mentioned, but no other combat tool exists among siblings, so this is sufficient.

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

• minecraft_collect_blockA
  4.3/5.0
  Behavior4/5

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

  Discloses that it is destructive (mines), involves movement (walks over), and may fail partway. Aligns with destructiveHint=true and adds error conditions not present in annotations. Could specify count behavior more precisely but overall strong.

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

  Conciseness5/5

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

  A compact paragraph covering action, contrast, return, and errors. Every sentence adds value; no filler.

  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?

  Covers main behavior, purpose, return type, and error modes. Minor gap: no explicit mention of how count affects behavior or what 'nearest' range is, but sufficient for a simple tool.

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

  Parameters2/5

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

  The schema documents block_name with examples but count lacks any description. The tool description does not mention count at all, leaving its semantics (e.g., how many blocks to collect) to inference. This is a gap given 50% 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?

  Clearly states it finds, mines, and picks up blocks, with a concrete example. Explicitly differentiates from minecraft_dig_block by noting it also collects drops.

  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?

  Gives a specific use-case ('when you actually want the item in inventory') and names the alternative tool. Includes an example query, making when-to-use obvious.

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

• minecraft_container_depositA
  4.3/5.0
  Behavior4/5

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

  The annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds the return format ('Returns: { message }') and two specific error conditions ('no container open, or item not carried'), which are not visible in annotations. This deepens behavioral understanding without contradiction.

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

  Conciseness5/5

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

  The description is extremely concise: a one-sentence action, a one-line prerequisite, and a returns/errors section. Every sentence earns its place; no redundant or vague content.

  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 simple inventory-to-container operation, the description covers all essential aspects: the action, the prerequisite, the return value, and likely error cases. No additional context is needed given the straightforward nature of 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?

  The schema describes 'count' well (omit to deposit entire stack) but 'item_name' has no description. The tool description only indirectly hints at item_name via the error 'item not carried,' but does not clarify expected format (e.g., Minecraft item ID). With 50% schema coverage, the description partially compensates but leaves item_name semantics incomplete.

  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: 'Moves an item from the bot's inventory into the currently open container.' This distinguishes it from sibling tools like minecraft_toss_item (discards) and minecraft_container_withdraw (removes from container). The verb 'Moves' and the resource are explicit.

  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 explicitly instructs 'Call minecraft_open_container first,' providing a clear prerequisite for use. It does not explicitly mention alternatives or when-not-to-use conditions, but the open-container requirement gives enough contextual guidance.

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

• minecraft_get_biome_atA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, so the description does not need to restate these. It adds value by disclosing the return format, including the nullable 'biome' field, which is not present in the schema.

  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, focused sentences. The description is front-loaded with the core purpose and includes only necessary detail about the return object. No wasted words.

  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?

  The tool is a simple read-only lookup; annotations cover safety, the return shape is described, and the parameter meaning is clear from context. With the schema and sibling tools providing additional environment context, the description is complete for an agent to invoke correctly.

  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 input schema only names x, y, z as numbers with no descriptions. The description adds meaning by calling them 'exact world coordinates', which clarifies the coordinate system. This compensates for the missing schema-level parameter 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 a specific action ('Looks up') and a specific resource ('biome at exact world coordinates'). It distinguishes itself from sibling tools like get_block_at and get_light_at by specifying biome as the target.

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

  Usage Guidelines3/5

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

  The description implies the usage context (querying biome data at coordinates) but does not explicitly compare with or exclude alternative tools. There is no mention of when not to use it or which sibling tools serve a different purpose.

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

• minecraft_get_block_atA
  4.3/5.0
  Behavior4/5

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

  Annotations already provide safety hints (readOnly, idempotent, non-destructive). The description adds valuable runtime behavior: return format and the error case for unloaded chunks, going beyond what annotations convey.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the primary action, followed by a succinct return format. Every word earns its place with no redundancy.

  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?

  This is a simple read-only lookup with fully documented parameters and annotations. The description includes the return shape and failure condition, making it complete for an agent to invoke confidently.

  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 already fully describes each parameter ('World X coordinate', etc.). The description adds only 'exact' coordinates without providing additional unit or precision details, so it stays at 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 a specific action ('Looks up a single block') and resource ('at exact world coordinates'), distinguishing it from sibling tools like get_nearby_blocks or find_block.

  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?

  It implies usage for inspecting a single block at precise coordinates and notes when it fails (chunk not loaded), but does not explicitly contrast with alternatives or state when not to use it.

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

• minecraft_get_positionA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral detail by listing the exact return fields (x, y, z, yaw, pitch, standingOn, dimension) and the notion of 'exact' coordinates, which is useful for the agent. There is no contradiction.

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

  Conciseness5/5

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

  The description is two sentences, front-loading the purpose and then providing the return structure. No redundant or irrelevant information is present.

  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 no-parameter, annotation-covered read tool, the description gives the exact return shape, which is essential given the absence of an output schema. It is complete for the tool's simplicity and does not require further detail.

  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, so the schema provides complete coverage. The description does not need to add parameter semantics, and the explicit return format covers the only input/output concern.

  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 a specific verb ('Returns') and identifies the exact resource ('the bot's exact current coordinates, facing direction, and which block it's standing on/in'). This clearly distinguishes it from sibling tools like 'minecraft_get_block_at' or 'minecraft_get_nearby_blocks'.

  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 when the agent needs the bot's current position, but it does not explicitly mention when to use this tool versus alternatives or provide exclusion criteria. For example, it could note that this is the dedicated tool for the bot's position rather than other position-based queries, but it doesn't.

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

• minecraft_get_timeA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the exact return structure and data ranges (e.g., ticks 0-24000, moonPhase 0-7), which goes beyond the annotations and clarifies output behavior.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main purpose, and every sentence adds value. No redundant or extraneous information.

  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?

  Despite lacking an output schema, the description fully specifies the return object with types and units. For a zero-parameter read tool with rich annotations, this is complete.

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

  Parameters4/5

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

  The tool has zero parameters, and the input schema confirms this. Baseline for zero parameters is 4, and the description does not need to add parameter information.

  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 'Returns the current in-game time and weather' with a specific verb and resource. It also enumerates the return fields (timeOfDay, day, isDay, moonPhase, isRaining), distinguishing it from sibling action-oriented tools.

  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 does not explicitly state when to use this tool or mention alternatives, but the function is self-evident as a query for time and weather. Usage is implied rather than directly guided.

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

• minecraft_jumpA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate that the tool is not read-only, not idempotent, and not destructive. The description adds useful context by specifying 'once in place,' clarifying that it is a single, stationary action. This goes beyond what the annotations provide.

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

  Conciseness5/5

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

  The description is extremely concise—a single short sentence that fully communicates the action without any wasted words. It is front-loaded and easy to parse.

  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 simple no-parameter action, the description is complete: it states what the tool does. The annotations cover safety and side-effect hints, and there is no output schema to worry about. Nothing more is needed.

  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 coverage is 100% (empty properties). With no parameters to explain, the baseline of 4 applies. The description does not need to add parameter information.

  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: 'Makes the bot jump once in place.' It uses a specific verb (jump), identifies the subject (bot), and specifies the scope (once, in place), distinguishing it from other movement-related tools like goto_position.

  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 does not explicitly state when to use this tool versus alternatives, but the usage is implicitly clear: it is for making the bot perform a single jump in place. No alternative jumping tool exists among siblings, so the lack of explicit guidance is acceptable.

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

• minecraft_list_playersA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds value by specifying the exact return structure, including the count and player fields with ping and gamemode, which is not covered by annotations. This goes beyond the structured metadata.

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

  Conciseness5/5

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

  The description is extremely concise, consisting of two short sentences. It front-loads the core action and resource, then provides a clear return format example. Every word earns its place, with no redundancy or fluff.

  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?

  Given the tool's simplicity (no parameters, zero required inputs) and the rich annotations, the description is fully complete. It explains both the behavior and the return format, which is essential since there is no output schema. Nothing important is missing.

  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?

  This tool has zero parameters, so schema coverage is vacuously 100%. The baseline for no-parameter tools is 4, and the description does not need to explain any parameter semantics. The focus is solely on the operation and output, which is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb ('Lists'), a precise resource ('every player currently online'), and additional details (ping and gamemode). It distinguishes itself from sibling tools like minecraft_status and minecraft_get_nearby_entities by its explicit scope of all online players across the server.

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

  Usage Guidelines3/5

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

  The description implies the tool is used when you need a list of online players, but it does not explicitly state when to use this over alternatives or provide any exclusions. No sibling tool is mentioned as an alternative, so the guidance remains only implicit.

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

• minecraft_look_directionA
  4.3/5.0
  Behavior4/5

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

  The description adds useful behavioral context beyond the annotations: 'Purely cosmetic/aiming — does not move the bot' clarifies the nature of the state change and distinguishes it from movement tools. Annotations already indicate non-read-only and idempotent, and the description complements these without contradiction.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the action, and every word contributes to understanding. It efficiently covers what the tool does and a key non-movement caveat without wasted text.

  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 tool with a single enum parameter and no output schema, the description is fully sufficient. Combined with annotations (idempotent, non-destructive), it gives the agent all needed information to select and invoke the tool correctly.

  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 description repeats the enum values from the schema (north/south/east/west, up/down) but adds no additional meaning beyond what the enum itself provides. Since schema description coverage is 0%, the description does not fully compensate, but the parameter is simple and self-explanatory, so a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb ('turns') and resource ('the bot'), and specifies the exact scope (compass directions and up/down). It also distinguishes from sibling tool minecraft_look_at by emphasizing compass direction rather than looking at a specific target.

  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 the tool: it's for cosmetic aiming and explicitly states it does not move the bot, implying it's not for movement. However, it does not explicitly name alternatives or provide a 'when not to use' scenario beyond 'does not move', so it falls short of a 5.

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

• minecraft_mountA
  4.3/5.0
  Behavior4/5

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

  Annotations indicate a non-read-only, open-world mutation. The description adds that the agent will walk to the target and specifies return and error behavior, going beyond the annotation flags. This adds meaningful context about what the tool does during execution.

  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?

  Three concise sentences cover the action, target selection, walking behavior, and returns/errors without any unnecessary detail. The most important information is front-loaded.

  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 tool with one optional parameter and no output schema, the description covers the core behavior, target selection, movement, and error case. It is self-contained and gives an agent everything needed to invoke it effectively.

  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 100%, and the entity_id parameter description already explains both use cases (omit for nearest rideable entity). The description only reiterates this, adding no new semantic information beyond what the schema provides.

  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 'Mounts' and explicitly lists rideable entity types (boat, minecart, horse, etc.), clearly distinguishing it from other actions like minecraft_dismount. It also specifies how to select the target (by entity id or nearest), making the purpose unambiguous.

  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?

  It provides clear context on target selection (by entity id from minecraft_get_nearby_entities or nearest rideable entity) and notes it will walk within reach first, which is useful for planning. It does not explicitly name alternatives or exclusions (e.g., dismount), but the context is sufficient for correct tool selection.

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

• minecraft_follow_playerA
  4.4/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond the annotations: it discloses that following is continuous and non-blocking, and that it persists until stopped. This goes beyond the safety hints (readOnlyHint=false, destructiveHint=false) by explaining the background execution model and stop conditions. It does not contradict the annotations.

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

  Conciseness5/5

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

  The description is concise and well-structured: a single sentence delivers the core function and key difference from a sibling, followed by a second sentence explaining background behavior and stop conditions, then a return type. Every sentence adds value without fluff.

  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 tool with continuous background behavior, the description covers the main aspects: what it does, how it differs from alternatives, when it stops, and the return type. It doesn't cover edge cases like what happens if the target player is lost or the bot is obstructed, but the core usage is sufficiently described given the schema and annotations.

  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 low (33% with only 'stop' having a description), so the description compensates by explaining the meaning of each parameter in plain language: 'named player' covers username, 'set distance' covers range, and 'stop=true' covers the stop parameter. This adds semantic meaning that helps an agent map natural language to the parameters.

  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 function: 'Starts (or stops) continuously following a named player at a set distance.' It uses a specific verb and resource, and explicitly contrasts with minecraft_goto_player by noting it does NOT block. This differentiates it from a closely related 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 Guidelines4/5

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

  The description provides clear usage context: it is non-blocking and runs in the background. It also explains how to stop following (via minecraft_stop or stop=true) and contrasts with minecraft_goto_player, which blocks. While it doesn't explicitly spell out 'when not to use,' the comparison with the alternative gives strong guidance.

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

• minecraft_waitA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral context by explaining the purpose (pausing for game state changes) and the timing, which is useful beyond the annotations. It does not contradict any annotation.

  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?

  One concise, front-loaded sentence effectively communicates the action and purpose with no wasted words. It includes a dash-separated list of use cases that are immediately relevant to an agent.

  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 simple, single-parameter wait tool with strong annotations, this description is complete. It states what the tool does, when to use it, and why it matters. No output schema is present, but the return behavior is trivial and not worth additional explanation.

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

  Parameters2/5

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

  The schema defines the 'seconds' parameter with type number and min/max constraints, but the description only says 'a number of seconds', which adds no additional meaning beyond the property name. With 0% schema description coverage, the description should compensate, but it does not.

  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 ('Pauses for a number of seconds') and the resource (time). It distinguishes this tool from all sibling tools by being the only one that waits, and it adds specific use cases (smelting, mob spawning, water flowing) that clarify its unique role.

  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 explicitly guides when to use this tool: 'useful for letting things settle ... between other tool calls.' It gives concrete scenarios and implies it should be used after triggering time-dependent actions, which is clear guidance for an agent selecting between this and other tools.

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

• minecraft_build_structureA
  4.5/5.0
  Behavior5/5

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

  Description discloses valuable behavioral traits beyond annotations: builds bottom-up for solid support, caps region at 500 blocks with truncation, skips already-matching blocks, and reports unsupported blocks as failed rather than aborting. This significantly enriches the annotations (readOnlyHint=false, openWorldHint=true, etc.) with operational details.

  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 well-structured and front-loaded: the first sentence states the core purpose, followed by a concise args list and clear return/behavior notes. Every sentence adds value, and the length is appropriate for a multi-parameter tool.

  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?

  Despite no output schema, the description fully documents the return shape ({ placed, skipped, failed, message }) and key behaviors (truncation, skip, failure handling). It covers use cases, build order, and limitations, making it complete for an agent to invoke correctly without further guesses.

  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 low (13%), with only block_name described. The description adds meaning for 'hollow' (outer shell vs solid) and clarifies that coordinates are 'two corner coordinates', but does not explain each coordinate pair's semantics or the relationship between x1/y1/z1 and x2/y2/z2. It partially compensates for the schema gap but is not comprehensive.

  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 'Fills a cuboid region between two corner coordinates with a block from inventory', specifying the verb, resource, and intent. It differentiates from siblings like place_block (single block) and clear_area (removal) by describing bulk filling for walls, floors, platforms, and boxes.

  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?

  Provides clear context for when to use the tool ('for walls, floors, platforms, boxes') and implies bulk building vs single placement. Does not explicitly mention alternatives or exclusions, but the use cases are sufficiently clear for an agent to select it appropriately.

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

• minecraft_close_containerA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds the specific no-op behavior ('Safe to call even if nothing is open') and enumerates the types of UIs affected (container, furnace, villager-trade). This goes beyond the structured hints and provides useful behavioral context.

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

  Conciseness5/5

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

  The description is two clear sentences with no filler. It leads with the primary function and follows with the safety note. Every word earns its place, making it highly scannable and efficient.

  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, idempotent utility tool with good annotations and no output schema, the description fully covers what it does, the scope of UI types, and the safe-to-call behavior. Nothing essential is missing.

  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 input schema is empty with zero parameters, so there is no parameter meaning to add. Per the rubric, a baseline of 4 applies for 0-parameter tools. The description correctly avoids inventing unnecessary parameter details.

  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 function: 'Closes whatever container, furnace, or villager-trade UI is currently open.' It specifies the verb (closes) and the resources (container/furnace/villager-trade UI), effectively distinguishing it from sibling tools like minecraft_open_container and minecraft_trade.

  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 phrase 'Safe to call even if nothing is open' provides explicit guidance that this tool can be invoked unconditionally without prior state checks. It implies the primary use case—when a UI is open—and that no alternative is needed when nothing is open. It does not name alternative tools, but the context is clear.

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

• minecraft_craft_itemA
  4.5/5.0
  Behavior4/5

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

  With annotations indicating readOnlyHint=false and openWorldHint=true, the description adds valuable behavioral context: ingredient requirements, crafting table proximity, return format, and common errors. This goes beyond the annotations without contradicting them.

  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 front-loaded with the main action, then covers crafting table usage, return format, and errors in a compact, well-organized manner. Every sentence contributes essential information with no redundancy.

  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?

  Despite no output schema, the description explicitly states the return shape and error conditions. It also provides prerequisite guidance (ingredients, crafting table) and cross-references to sibling tools for setup. This is complete for a crafting tool with 3 parameters.

  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 67%. The description adds meaningful explanation for use_crafting_table (when true, requires nearby table) and clarifies item_name via example. The count parameter is self-evident from its name, schema constraints, and default.

  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 'Crafts' and clearly identifies the resource (an item via a recipe). It distinguishes from siblings like minecraft_give_item by emphasizing the recipe-based crafting process.

  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?

  Provides clear context for when to use a crafting table (3x3 recipes) and directs to minecraft_find_block or minecraft_place_block for setup. It doesn't explicitly contrast with alternative tools, but the prerequisites and error conditions give strong usage guidance.

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

• minecraft_dismountA
  4.5/5.0
  Behavior4/5

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

  The description adds behavioral context beyond the idempotentHint annotation by explicitly stating the no-op behavior when not mounted. It also clarifies the scope ('whatever entity/vehicle') without contradicting the annotations.

  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, with the first sentence stating the core action and the second providing a safety guarantee. Every word is valuable; no redundant phrasing.

  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, zero-output tool with strong annotations (idempotent, non-destructive), the description sufficiently covers functionality and edge-case behavior. The tool is simple, and the description fully addresses its use.

  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?

  With zero parameters, schema coverage is inherently 100%. The baseline is 4, and no parameter explanation is needed. The description appropriately focuses on behavior rather than arguments.

  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 'Dismounts whatever entity/vehicle the bot is currently riding' uses a specific verb and resource, clearly differentiating from siblings like minecraft_mount and minecraft_stop. It states exactly what the tool does without ambiguity.

  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 phrase 'Safe to call even if not mounted' provides clear guidance that this tool can be invoked unconditionally, avoiding state checks. It implies when to use it (while riding) and clarifies that no error occurs if not mounted, though it does not explicitly name alternatives.

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

• minecraft_eatA
  4.5/5.0
  Behavior4/5

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

  Annotations provide basic hints (readOnly=false, idempotent=false), but the description adds valuable context: it equips the food first, then eats it to restore hunger, and includes error cases. It also implies consumption of the food item without contradicting the destructiveHint=false annotation (since that likely refers to the environment).

  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 concise sentences cover purpose, return value, and error conditions. No wasted words; the essential information is front-loaded.

  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 simple 1-param tool with no output schema, the description is complete: it states the action, the prerequisite (food in inventory), the effect (restore hunger), and all relevant error cases. No additional context is needed.

  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 schema already has 100% coverage for the single param, and the description additionally clarifies that the item must be a food item from inventory. The schema's examples ('cooked_beef', 'bread', 'apple') are reinforced by the description's 'a food item from inventory'.

  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 states a specific verb+resource: 'Equips a food item from inventory and eats it to restore hunger.' It clearly distinguishes from siblings like use_held_item, equip_item, or toss_item by specifying the eat action and the hunger restoration purpose.

  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 implies usage when the bot needs to restore hunger, and it lists error conditions including when the bot can't eat (food already full). It does not explicitly name alternative tools, but the context is clear enough for an AI agent to know when to invoke this tool.

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

• minecraft_get_inventoryA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by detailing the exact return structure (items array with fields, heldItem, armor mapping), which goes beyond the annotations. No contradictions.

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

  Conciseness5/5

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

  The description is concise: one sentence stating purpose and a code block showing the return format. It is front-loaded with the core functionality, and every element earns its place. No redundant fluff.

  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?

  With no parameters and no output schema, the description carries the full burden of explaining the return value. It provides a complete inline JSON schema, including nested fields like items, heldItem, and armor, making it fully sufficient for an agent to interpret results.

  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, so the schema has complete coverage and there is nothing to explain. The description correctly avoids inventing parameters, and the baseline of 4 applies since no parameter documentation is needed.

  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 specific verb 'Returns' and the resource 'everything the bot is carrying', enumerating hotbar/inventory items, held item, and armor. This distinguishes it from other get tools like position or nearby blocks, and aligns with the title 'View Bot Inventory'.

  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 clearly implies when to use the tool: whenever you need to inspect the bot's carried items. However, it does not explicitly mention alternatives or exclusions, such as 'use get_nearby_entities for entities' or 'only works when connected to a world.' The context is clear but not fully explicit.

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

• minecraft_get_nearby_blocksA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful details beyond this: it returns non-air blocks only, sorts closest first, caps results at 400, and specifies the radius range/default. This provides operational context but doesn't explain nuances like line-of-sight vs. loaded chunks.

  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 well-structured and appropriately sized: a one-sentence overview, a purpose statement, then clearly labeled Args and Returns sections. Every sentence contributes value 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?

  The description supplies a return-shape sketch and the 400-result cap, compensating for the lack of an output schema. It covers both optional parameters and their defaults. Minor ambiguities remain (e.g., what 'can see' means precisely and whether coordinates are absolute), but it is largely complete for a read-only scan tool.

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

  Parameters5/5

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

  The schema only describes block_names, leaving radius without a description. The description compensates fully: it explains radius as a block distance with min/max/default, and clarifies block_names with examples and the omission behavior ('Omit to return all non-air blocks'). This adds significant meaning beyond the raw schema.

  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 function: 'Scans the world around the bot and lists non-air blocks it can see, closest first.' It uses a specific verb ('Scans') and resource ('the world around the bot'), and adds a helpful analogy ('the bot's eyes for terrain/structures') that differentiates it from sibling tools like get_block_at or find_block.

  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?

  It gives an explicit when-to-use instruction: 'use it before building or navigating.' However, it does not name alternative tools or state when not to use it, so it lacks full exclusion/alternative guidance that would earn a 5.

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

• minecraft_goto_positionA
  4.5/5.0
  Behavior5/5

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

  The description goes well beyond the annotations, disclosing key behavioral traits: pathfinding capabilities (obstacles, stairs, gaps), that it is a blocking call with a 60s timeout, and possible errors (unreachable, timeout, no path). It also specifies the return structure in the absence of an output schema, providing valuable operational context.

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

  Conciseness5/5

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

  The description is concise and well-structured, with two short paragraphs. The main action is front-loaded, returns and errors are clearly separated, and every sentence contributes essential information without redundancy.

  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?

  Given the tool's complexity (pathfinding, blocking, timeout, error conditions) and lack of an output schema, the description adequately covers the return value, error cases, and key behavioral constraints. It is complete enough for an agent to understand what the tool does and what to expect, leaving no critical 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 coverage is only 25% because x, y, z lack descriptions. The description clarifies that they form a 'target position' and the return shows position as {x, y, z}, but it does not specify coordinate origin or units. The 'range' parameter is fully described in the schema, so the description adds minimal extra meaning for that. Some compensation for the low schema coverage exists but not complete.

  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 'Paths the bot to a target position using pathfinding', specifying the resource (bot) and action (walk) with a coordinate target. This distinguishes it from sibling movement tools like goto_player and follow_player, making the purpose unambiguous.

  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: when the agent needs to navigate to specific coordinates, with pathfinding accounting for obstacles. It does not explicitly mention alternatives like goto_player, but the focus on coordinate-based movement and the sibling names imply the distinction. No exclusions are stated.

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

• minecraft_open_containerA
  4.5/5.0
  Behavior5/5

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

  Beyond the annotations, the description discloses that the agent walks within reach first, that opening maintains a persistent state until closed, and that deposit/withdraw operate on this open container. It also provides return value details and error conditions. This significantly enriches the behavioral profile beyond the minimal readOnly/openWorld/idempotent hints.

  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 front-loaded: the first sentence states the primary action and target. It efficiently communicates the persistent state, return format, and errors without unnecessary verbiage. Every sentence earns its place.

  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?

  The description fully explains the tool's behavior, including movement, stateful relationship with other container tools, return shape, and error cases. Since there is no output schema, the manual return/error documentation is essential and well provided. The tool is sufficiently complex (stateful, coordinates) and the description covers all essential 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 provides only x, y, z with type number and no descriptions. The description clarifies these are 'given coordinates', which adds some semantic meaning but does not specify the coordinate system, range, or whether integers are required. Given the low schema coverage, the description should compensate more thoroughly for parameter semantics, so this is adequate but not exceptional.

  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 specifically states it opens containers (chest, trapped chest, barrel, shulker box, dispenser, dropper) at given coordinates and lists contents. This clearly distinguishes it from sibling tools like minecraft_close_container, minecraft_container_deposit, and minecraft_container_withdraw by describing the persistent open state that those tools depend on.

  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 explains that the container stays open until minecraft_close_container is called and that deposit/withdraw act on the currently open container, implying this tool should be used before those operations. It also mentions errors, giving context for when it may fail. However, it does not explicitly contrast with alternatives such as minecraft_activate_block or minecraft_use_furnace.

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

• minecraft_statusA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds value by disclosing that the tool may return connected: false, implying a prerequisite state, and provides the full return shape, which is not covered by annotations.

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

  Conciseness5/5

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

  The description is concise and well-structured: a one-sentence overview, the return schema explaining the output, and a conditional usage note. Every element is necessary, especially the return schema since there is no output schema in structured form.

  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?

  The description is complete for a stateless read-only tool with no parameters. It includes the full return object, a conditional follow-up instruction, and is consistent with the annotations. No missing aspects are apparent.

  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?

  With zero parameters, the baseline is 4. The description does not need to explain parameters but instead enriches the tool's meaning through the extensive return object, which is helpful even though not directly about parameters.

  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 returns the bot's current health, hunger, position, gamemode, dimension, time, weather, XP, and online players. This distinguishes it from specialized siblings like get_position and get_time, establishing it as the comprehensive status endpoint.

  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 gives clear context by noting 'Call minecraft_connect first if this returns connected: false', providing a temporal usage instruction. However, it does not explicitly mention alternatives like get_position or list_players when only partial status is needed, so it lacks explicit exclusion guidance.

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

• minecraft_stopA
  4.5/5.0
  Behavior4/5

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

  The description discloses concrete behavioral effects: canceling pathfinding goals and releasing movement keys. This adds context beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by detailing what exactly the tool does to the agent's movement 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 two sentences long, with the primary action in the first sentence and usage guidance in the second. Every word earns its place, and the structure is perfectly front-loaded.

  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 simple, zero-parameter action tool with clear annotations and no output schema, the description fully covers purpose and usage. It also appropriately references the kinds of goals it cancels (goto/follow), making it complete for the agent's needs.

  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, so the description has no parameter details to provide. The mention of 'goto/follow' is contextual rather than parameter-related. Baseline 4 is appropriate for zero-param tools where the schema already shows an empty object.

  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 action: 'Cancels any active pathfinding goal (goto/follow) and releases all movement keys.' This distinguishes it from sibling movement tools like goto_position, goto_player, and follow_player, making its purpose unambiguous.

  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 explicit usage context with 'Use this to interrupt movement in progress.' While it does not name alternative tools or specify when not to use it, it gives a clear directive for when this tool is appropriate.

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

• minecraft_chatA
  4.6/5.0
  Behavior4/5

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

  Annotations already indicate a non-read-only, non-idempotent, non-destructive action. The description adds useful behavioral context: messages are visible to all players, and command execution depends on permission. This goes beyond the annotation hints without contradicting them.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the primary purpose and followed by the edge-case behavior. No redundant or irrelevant content.

  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 simple one-parameter tool with no output schema, the description covers the main use case, the public visibility, and the command-caveat. It is fully sufficient for an agent to select and invoke this tool appropriately.

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

  Parameters5/5

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

  Despite 0% schema description coverage, the description explains the critical behavior of the 'message' parameter: if it starts with '/', it is treated as a chat command subject to permission. This adds significant semantic meaning beyond the schema's simple string type.

  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: 'Sends a message in in-game chat, visible to all players on the server.' It also highlights support for chat commands ('/'), which distinguishes it from sibling tools like minecraft_whisper (private messaging) and minecraft_list_players.

  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: this tool is for public chat messages and works with commands when the message starts with '/' and the bot has permission. It does not explicitly mention alternatives or exclusions, but the public/command usage is well established.

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

• minecraft_dig_blockA
  4.6/5.0
  Behavior5/5

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

  Annotations already indicate destructive and non-read-only behavior, but the description goes further by detailing what happens to drops, the auto-walk behavior, and the return/error scenarios. It also notes the required tool condition ('missing required tool') without contradicting the annotations—this adds significant behavioral context beyond the structured data.

  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 tightly structured: main action, key behavior, alternative-use note, and then returns/errors. Every sentence earns its place, and the most critical information is front-loaded. It is concise without being under-specified.

  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 simple tool with three numeric parameters and no output schema, the description covers the essential aspects: what it does, how it behaves, what to expect in return, and likely errors. It also situates the tool relative to a key sibling. No major gaps are apparent for an agent to invoke it correctly.

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

  Parameters2/5

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

  The input schema provides no descriptions for x, y, z, and the description merely says 'at the given coordinates' without explaining that these are block coordinates, what range they accept, or any units. With 0% schema coverage, the description fails to compensate, leaving parameter meanings vague and potentially ambiguous for an AI agent.

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

  Purpose5/5

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

  The description opens with a specific verb and resource ('Mines/breaks the block at the given coordinates') and immediately distinguishes from the sibling tool minecraft_collect_block by noting the difference in drop pickup. This makes the tool's purpose unambiguous and well-differentiated.

  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 explicitly names an alternative tool ('use minecraft_collect_block instead if you also want the bot to auto-pick-up the drops'), which serves as a clear when-not condition. It also communicates an important behavior ('Automatically walks within reach first') that tells the agent it need not pre-position the bot. This is explicit, actionable guidance.

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

• minecraft_get_nearby_entitiesA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: results are ordered 'closest first' and the type_filter semantics ('mob' means non-hostile). It doesn't introduce additional unstated 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 concise and well-structured: a one-sentence overview, a compact args list, and a returns line. Every sentence adds value with no redundancy.

  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 simple two-parameter read-only tool, the description is complete: it explains purpose, parameters, and return format. With annotations providing safety context and no output schema, nothing essential is missing.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description carries the full burden. It thoroughly explains both parameters: radius with range and default, and type_filter with each enum value and special meaning for 'mob'. This goes far beyond the bare schema.

  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 function: 'Lists players, mobs, and other entities near the bot, closest first.' This uses a specific verb ('Lists') with a clear resource ('entities') and scope ('near the bot'). It also differentiates from siblings like get_nearby_blocks (blocks vs entities) and list_players (global vs nearby).

  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 implies when to use this tool: when the bot needs awareness of entities around it. However, it does not explicitly mention alternatives or exclusions (e.g., 'use list_players for all players'). This provides clear context but misses explicit when-not-to-use guidance.

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

• minecraft_use_held_itemA
  4.6/5.0
  Behavior4/5

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

  Annotations already convey it's non-read-only, non-idempotent, and non-destructive. The description adds the semantic of 'right-click-and-hold', examples of interactions, and a return message format. It does not enumerate all side effects (e.g., item consumption), but the examples provide useful behavioral context.

  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: two sentences plus a return format note. It front-loads the core action and uses examples only where they add clarity, with no redundant or filler content.

  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 tool with only two parameters and good annotations, this description is complete enough: it explains what the tool does, gives use cases, and integrates with a sibling tool. A minor gap is not stating when not to use it (e.g., for eating use minecraft_eat), but the sibling list and examples make the intended scope clear.

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

  Parameters4/5

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

  The description elaborates on the 'action' parameter by explaining start/stop with item examples, compensating for the missing schema description on that parameter. The 'offhand' parameter is well described in the schema, so coverage is adequate. The description could have explicitly mentioned offhand but is not required given 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 function: it starts or stops the generic 'use' action on the currently equipped item, with specific examples (shields, bows, potions, fishing rods) that distinguish it from more specific actions like shooting a bow. This gives a clear verb+resource+scope.

  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 explicitly advises pairing with minecraft_shoot_bow for a ready-made bow-firing flow and calls out direct use for shields/potions. This is concrete when-to-use guidance that names an alternative tool and clarifies the integration.

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

• minecraft_respawnA
  4.7/5.0
  Behavior4/5

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

  The description adds context beyond annotations by explaining the auto-respawn dependency and the health-check prerequisite. Annotations already declare idempotentHint=true and destructiveHint=false, so the description doesn't contradict them. It could enrich further by describing what happens if the bot isn't dead, but this is a minor gap for a simple action.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the main action, and no filler. The second sentence adds crucial usage guidance without redundancy. Every word earns its place.

  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 parameterless, output-less tool, the description fully covers purpose, conditions of use, and a verification step. The annotations provide supplementary safety/idempotency information, and no output schema is needed. This is complete for the tool's complexity.

  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 schema coverage is 100% (vacuously), so there is nothing to add. The description naturally focuses on the action, and the baseline for 0 params is 4.

  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 a specific verb 'Respawns' and identifies the resource (the bot) and destination (spawn point/bed). It clearly scopes the action to 'after dying,' which distinguishes it from siblings like minecraft_sleep or minecraft_connect.

  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?

  Explicitly states when the tool is needed ('Only needed if the server's auto-respawn is disabled') and gives a concrete precondition ('check minecraft_status for health 0 first'). This provides clear usage context and a diagnostic step, going beyond a mere mention of alternatives.

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

• minecraft_clear_areaA
  4.8/5.0
  Behavior5/5

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

  Beyond the annotations (destructiveHint=true), the description adds valuable behavioral details: digs top-down, skips non-diggable blocks, caps at 500 blocks, and includes a return summary with dug/skipped counts. This enriches the agent's understanding beyond the basic mutation flag.

  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 tight and effective: a clear first sentence stating the operation, a single-sentence caveat about the cap, and a concise return type. No filler; every sentence earns its place.

  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?

  With six unannotated parameters and no output schema, the description covers what the parameters mean, the behavior (top-down, skip non-diggable), the size limit, and the return structure. It is fully sufficient for an agent to use the tool correctly.

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

  Parameters5/5

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

  The input schema has zero descriptions for its six numeric parameters. The description compensates by explaining that the parameters are two corners defining a cuboid region, which gives full meaning to the coordinate pairs. It also clarifies the 500-block cap on the region size, adding crucial constraint context.

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

  Purpose5/5

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

  The description clearly states the action ('Digs out (breaks) every non-air, diggable block') and the resource ('a cuboid region between two corners'). It distinguishes from siblings like minecraft_dig_block (single block) and minecraft_build_structure (construction) by specifying the region-based clearing use case.

  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?

  Provides explicit context for when to use it: 'for clearing land or hollowing out a room.' It implies this is for bulk removal rather than single-block digging, though it does not name alternative tools directly or provide exclusions.

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

• minecraft_use_furnaceA
  4.8/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses the full action sequence, the waiting behavior based on wait_seconds, the fact that it collects whatever is ready and can be called again, and lists errors. This gives an agent a clear model of side effects and state changes without contradiction.

  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 front-loaded with a concise summary, followed by a structured argument list, returns, and errors. Every section adds value without redundancy, and the language is precise and actionable.

  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 multi-step tool with 7 parameters and no output schema, the description covers the entire process, all key parameters, the return shape, error conditions, and the nuance of multiple calls for collecting output. This is sufficient for an agent to invoke it correctly without missing expected behavior.

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

  Parameters5/5

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

  Schema coverage is 0%, and the description fully compensates by explaining each argument's role, providing concrete examples for input_item and fuel_item, clarifying that fuel_item can be omitted if pre-loaded, and explaining wait_seconds in the context of vanilla smelting time. Coordinates are self-evident, but semantic parameters are well documented.

  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 opens a furnace, loads input and fuel, waits for smelting, collects output, and closes the furnace, explicitly saying 'One call handles the whole loop.' This specific verb+resource+process distinguishes it from sibling inventory or container tools by automating the entire smelting workflow.

  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: it is a high-level smelting operation, and it gives usage tips like omitting fuel_item if already loaded and calling again to collect more after completion. However, it does not explicitly mention when not to use this tool or name alternatives such as open_container/container_deposit, so it stops short of full when/when-not guidance.

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

• minecraft_open_villagerA
  4.9/5.0
  Behavior5/5

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

  The description discloses the full behavioral flow: walking, opening, listing trades, staying open, and the error condition ('no villager nearby/found'). It adds context beyond annotations by explaining the stateful nature (stays open) and the exact return format, which is not present in annotations.

  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: a clear action sentence, a follow-up on lifecycle, then a concise Returns/Errors block. No redundancy or filler; every sentence adds value.

  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 one-parameter tool with no output schema, the description provides all needed context: action, parameter source, lifecycle, return shape, and error conditions. The annotations cover safety/open-world aspects, and the description handles the rest, making it complete for selection and invocation.

  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 single parameter (entity_id) already has a clear schema description, and the tool description reinforces it by adding context: 'from minecraft_get_nearby_entities' and the fallback to nearest villager. This adds meaning beyond the schema's basic description, earning above baseline.

  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 a specific verb ('Walks to and opens trade') with a resource ('villager') and clearly states the outcome ('lists its available trades'). It distinguishes itself from siblings like minecraft_trade (which executes a trade) and minecraft_open_container (which is generic) by focusing on villager-specific trade opening.

  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?

  It explicitly mentions that the trade stays open until minecraft_close_container is called and directs the user to use minecraft_trade to execute a trade. It also specifies the input source (entity id from minecraft_get_nearby_entities or nearest villager), giving clear when-to-use and flow context.

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

• minecraft_connectA
  5/5.0
  Behavior5/5

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

  The description discloses behavioral details beyond annotations: it must precede all other minecraft_* tools, returns a confirmation message with spawn position, and lists specific error conditions (connection refused, wrong port, version mismatch, auth-mode mismatch). It also explains the consequence of choosing the wrong auth mode, which is not encoded in the annotations.

  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 front-loaded with the core operation, followed by practical auth and LAN instructions, then a succinct return/error summary. Every sentence adds a distinct piece of information; the length is justified by the tool's complexity.

  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?

  The tool has no output schema, but the description covers return values and common error cases. Given the complexity of authentication modes and prerequisite ordering, the description provides all necessary context for an agent to use this tool correctly and distinguish it from the many sibling tools.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds contextual meaning: it maps auth='offline' to TLauncher/cracked/LAN servers and auth='microsoft' to online-mode servers, explains how to obtain host and port from a LAN world ('host="localhost"'), and notes port is shown in chat. It also clarifies that version can be omitted for auto-detection.

  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 states 'Connects the bot to a running Minecraft Java Edition world' and enumerates specific connection targets (server, LAN world, local server jar). This clearly differentiates it from sibling tools like minecraft_disconnect and minecraft_status, which serve 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 Guidelines5/5

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

  It explicitly states 'Must be called before any other minecraft_* tool', providing a clear prerequisite. It also gives conditional guidance on auth mode ('Use auth="offline"' for TLauncher/cracked/LAN, 'auth="microsoft"' for real accounts) and step-by-step instructions for connecting to a singleplayer world via Open to LAN.

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