Minecraft MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation3/5
While many tools are clearly distinct, there are overlapping concepts such as 'look-around' which duplicates 'get-status' and 'show-adjacent-blocks', and multiple movement/breaking tools with similar functions. However, descriptions are detailed enough to differentiate primary use cases.
Naming Consistency5/5All tool names follow a consistent lowercase verb-noun pattern, with hyphens separating words. Compound names like 'move-horizontally-by-mining' and 'toggle-swim-up-jump-up' are still readable and maintain the convention.
Tool Count1/5With 53 tools, the server is far beyond the typical well-scoped range. Even for a complex game like Minecraft, this is an extreme number and appears to be a collection of every possible action rather than a curated set.
Completeness5/5The tool set covers a broad range of Minecraft mechanics: movement, mining, building, chests, entities, villagers, trading, sleeping, fishing, elytra, chat, and status. There are no obvious missing major operations for typical gameplay.
Average 3.5/5 across 53 of 53 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Mine down multiple steps', which implies destruction, but it does not clarify that the player moves, that blocks are auto-mined based on the allowMiningOf mapping, that it creates a staircase-like pattern, or any details about failure, reversibility, or tool requirements. This is insufficient for a mining/movement tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences), but the second sentence is redundant and contains a typo ('wile' and likely 'vertically' instead of 'horizontally'), which harms clarity. It is concise but not well-structured or error-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex tool (mining, movement, nested parameters) with no annotations and no output schema. The description provides minimal context, leaving out crucial behavioral information such as the staircase pattern, how steps are executed, and what happens when mining is blocked. The schema param descriptions help but cannot compensate for the lack of overall tool behavior context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions, including the nested nextStepPos, so the schema provides the necessary semantics. The description adds no extra parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence 'Mine down multiple steps' gives a general action, but the second sentence 'Good for going vertically and down at the same time' is confusing and contains a likely typo ('vertically' instead of 'horizontally'), which contradicts the tool's name and muddies what the tool actually does. It does not clearly distinguish from the sibling tool 'move-horizontally-and-up-using-steps' beyond the direction word.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool over alternatives. 'Good for going vertically and down at the same time' is an implied use case, but it is vague and misleading due to the 'vertically' error, and it does not mention when not to use it or what distinguishes it from related tools like 'move-horizontally-by-mining' or 'dig-directly-down'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions mining steps but does not clarify the movement mechanics, how steps are created, failure handling, or whether the player is actually moved. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences, which is concise but under-specified. It does not waste words, but the brevity comes at the expense of essential elaborations on the tool's operation and selection. The text borders on being a slightly expanded restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, a nested object, no annotations, and no output schema, the description is far from complete. It does not explain return values, the actual movement process, when to use this tool over alternatives, or any safety/error implications. This is inadequate for a navigation action in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: all four parameters have descriptions, including the nested nextStepPos object with its own properties and explanations. The tool description adds no parameter-specific information, but the schema already provides adequate meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Mine up multiple steps' and 'Good for going forwards-and-up', which indicates a mining/ascending action, but it does not explicitly state that the tool moves the player horizontally and upward by mining steps. It does not differentiate from similar sibling tools like move-horizontally-by-mining.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Good for going forwards-and-up' provides a clear scenario where the tool is useful, implying usage when the player needs to ascend diagonally. However, it gives no explicit alternatives, exclusions, or comparison to other movement tools, so the guidance remains mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions sequential digging. It does not describe effects on inventory, tool handling, failure modes, or whether blocks are broken instantly or over time, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no redundant words, making it easy to parse quickly. However, it is so brief that it borders on under-specification, though it does earn its place as a clear single-sentence summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested objects, no output schema, no annotations), the description is woefully incomplete. It does not explain return values, prerequisites, or side effects, leaving the agent without sufficient context for a non-trivial operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with detailed explanations for each parameter including examples and defaults. The tool description itself adds no additional parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool digs multiple blocks sequentially, with a specific verb and resource. It distinguishes from siblings like 'dig-directly-down' by implying multiple positions, though it omits the adjacency aspect from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'dig-directly-down' or 'move-horizontally-by-mining'. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral information, but it offers none beyond the basic action. It doesn't disclose that items are removed from inventory, appear in the world, or are potentially lost, which are critical side effects for a drop operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. It earns high marks for brevity, though it could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema, no annotations), the description is minimally sized but lacks essential context about the action's result and when to use it. It doesn't explain the item's fate or any limitations, making it incomplete for effective agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (itemName and count), covering 100% of the schema. The description adds no additional meaning beyond the schema, so it meets the baseline but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drop') and resource ('items from inventory'), making it distinct from sibling tools like equip-item or eat-food. However, it doesn't specify the destination (e.g., onto the ground), so it's not fully explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like chest-deposit or activate-item. There are no exclusions, prerequisites, or context hints, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states 'Right-click/interact' without explaining side effects, failure conditions, whether line-of-sight is required, or what happens when no entity is found. This is insufficient for an interaction that could trigger entity-specific behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly states the purpose. It is front-loaded and contains no wasted words, making it highly efficient and easy to parse. Conciseness is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of overlapping sibling tools (entity-use-item-on, entity-mount, villager-open, block-activate, etc.), the description does not provide enough context to disambiguate. It also omits any description of return behavior or success/failure semantics, which is important since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters ('entityType' and 'maxDistance') having descriptions in the input schema. The tool description itself does not add parameter semantics beyond the schema, but the schema already covers them. Baseline for high coverage is 3, and the description neither adds nor detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Right-click/interact') and a clear target ('nearest entity'), which gives it a specific verb+resource. However, it does not explicitly differentiate from sibling tools like 'entity-use-item-on' or 'villager-open', which also involve interaction with entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool over alternatives. The description does not mention prerequisites, when to choose it over 'attack-entity' or 'find-entity', or any context about the interaction. This is a complete absence of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects. It only says 'Equip', which implies a state change, but does not mention whether the current item is swapped, if the item must be owned, or how destination affects 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is appropriately sized for the simple action it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there are only two parameters, the tool is a state-changing action with no annotations or output schema. The description fails to explain the meaning of 'equip' in the game context, such as what destination does or whether the item must be in inventory, leaving important gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (itemName and destination), covering 100%. The description itself adds no extra parameter nuance, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Equip a specific item' clearly states the action (equip) and resource (item). While it doesn't explicitly contrast with siblings like 'activate-item' or 'drop-item', the verb is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any prerequisites such as the item needing to be in inventory. The description is purely a flat action statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only restates the name's meaning and does not explain mutation effects, reversibility, permission requirements, or behavior when coordinates are invalid or the sign is missing. This matches the update_drive pattern where transparency was scored 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, front-loading the action. It avoids repeating schema details and has zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, and the description provides only a bare action statement. While the schema covers parameters, the description lacks essential context such as the role of coordinates, the behavior of the 'back' flag, and error cases. A few clarifying sentences are needed for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter's meaning (x, y, z, back, text) is already documented. The description adds no additional parameter semantics, fitting the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('update') and resource ('text on a sign'), clearly indicating the function. It distinguishes from sibling tools like place-block or write-book by focusing on signs, though it does not explicitly contrast with any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't mention when to use this tool instead of alternatives (e.g., block-activate or place-block), nor any prerequisites like proximity to the sign or the need for it to already exist. Context is only implied by the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only says 'Detect the gamemode', which implies a read-only operation, but it does not disclose what the return value looks like, whether errors can occur, or any other behavioral details. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately sized for a zero-parameter tool, though the phrase 'on game' is slightly redundant/unpolished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is nearly adequate, but since there is no output schema, it should clarify what the result of detection is (e.g., the specific gamemode value). It also lacks context regarding how this relates to sibling tools like get-status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, so there are no parameter semantics to explain. Per the rubric, 0 parameters warrants a baseline of 4; the description adds no parameter information but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Detect' with a clear resource ('gamemode'). It clearly states what the tool does, but the phrasing 'on game' is slightly awkward and it does not explicitly distinguish itself from siblings like get-status, though no sibling clearly targets gamemode detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get-status or other world-state tools. There are no exclusions, prerequisites, or context clues to help the agent choose this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states 'Activate' without explaining whether this toggles flight, requires rockets, consumes items, or has any other side effects. This is insufficient for a tool that likely needs conditions to be met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the action without wasted words. It is appropriately sized for a zero-parameter tool, though it could be slightly expanded to include behavioral context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is minimally viable. However, it lacks important contextual details such as prerequisites (e.g., elytra equipped) or whether it is a toggle. The sibling tool 'equip-item' hints at a workflow, but this tool does not explicitly reference it, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the schema confirms additionalProperties=false with no properties, so there is no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Activate elytra flight' uses a specific verb ('Activate') and resource ('elytra flight'), clearly indicating the tool's function. It is distinct from the sibling tool 'activate-item' because it explicitly targets elytra flight, though it does not explicitly contrast with other movement tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., equipping an elytra) or situations where this tool is appropriate, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description is the only source of behavioral info. It only states the action, but does not disclose effects such as whether the bot's position changes, if it's a single jump, or any prerequisites. This is minimal at best.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is appropriate for a simple zero-parameter action. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial tool, the description is nearly sufficient, but it fails to distinguish from siblings like 'jump-over-obstacle' or 'toggle-swim-up-jump-up', leaving the agent without enough context to select the correct tool. Slight gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to document. The schema already covers 100% (empty properties). The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Make the bot jump' clearly identifies the action (jump) and the subject (the bot). It distinguishes from siblings like 'jump-over-obstacle' and 'toggle-swim-up-jump-up' by focusing on a simple in-place jump, though it doesn't explicitly state 'in place'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not mention when to use this tool versus alternatives like moving horizontally or jumping over obstacles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must bear the full burden. It only says 'make the bot look at a specific position' without disclosing whether the bot's body rotates, whether the rotation is instant, whether any validation is performed, or any prerequisites. This is a minimal statement with no behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence of eight words. It is front-loaded and contains no extraneous information, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three numeric parameters and no output schema, the description is minimally adequate, but it does not clarify the effect (e.g., head vs body rotation), how it differs from 'look-around', or any constraints. Given its simplicity, it reaches a middle score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three parameters (X, Y, Z coordinates), so coverage is 100%. The description adds no extra detail about units, coordinate system, or whether the position is absolute or relative. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('look at') and the target ('a specific position'), which is distinct from moving or interacting. However, it does not explicitly differentiate from the sibling 'look-around' tool, so it is clear but not fully specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention conditions like aiming, looking before interacting, or that other tools handle movement. No exclusions or alternatives are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action 'write content.' It does not mention whether the operation overwrites existing content, requires the book in a specific slot, or has any page limits or side effects. This is minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, directly conveying the core action. It is well-structured and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description successfully conveys the tool's purpose and the parameters are fully documented, but it lacks behavioral context such as overwrite semantics or constraints. Given the simplicity of the action and complete schema, this is adequate but not exemplary, missing the nuance that could fully orient the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'slot' and 'pages' already described in the schema. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Write content to a book and quill'), clearly indicating the tool's function. It distinguishes from siblings like 'sign-update' by referencing the book-and-quill item, though it does not explicitly contrast with other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as 'sign-update' or other item interactions. The description is purely declarative without contextual usage cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only says 'Activate a block'. It does not disclose potential side effects (e.g., toggling redstone, consuming resources), prerequisites (e.g., proximity), or behavior when the block is not activatable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action and examples. 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too minimal. It does not explain what 'activate' entails, potential errors, or how to choose between this and 'activate-item'. The tool is simple, but the description leaves significant gaps for an agent to confidently select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters (x, y, z coordinates), achieving 100% coverage. The description adds no extra parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Activate') and the resource ('a block') with concrete examples (button, lever, door, trapdoor) that distinguish it from sibling tools like 'activate-item'. The purpose is immediately evident and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention the existence of 'activate-item' or other interaction tools, nor does it state any exclusions (e.g., 'use for blocks, not items').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits, but it only states the action. It omits search behavior (e.g., maxDistance), failure modes, and side effects, which are critical for an agent to anticipate what happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, direct, and free of filler. Every word earns its place, making it highly concise without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too thin for operational completeness. It doesn't mention that the tool searches for the nearest entity of the given type, any rideability constraints, or what happens if no entity is found, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains both parameters. The description adds no additional parameter semantics, but per the rubric, a baseline of 3 is appropriate when the schema handles it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Mount' and lists concrete examples (horse, boat, minecart), making it unmistakably clear what the tool does. This naturally distinguishes it from siblings like entity-dismount and entity-interact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, such as entity-interact or entity-dismount. No prerequisites or contextual hints are provided, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only indicates a search operation but does not explain what the tool returns, whether it's read-only, how 'nearest' is determined, or any edge cases. The description is notably sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to parse. There is no wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description is too sparse for the context. With no output schema and no annotations, the description should explain what the search returns or how to interpret results. It does not, leaving critical gaps for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described in the schema: 'type' with empty meaning any entity, and 'maxDistance' with default 16. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'nearest entity of a specific type', distinguishing it from sibling tools like find-item and find-blocks-by-type. It specifies a spatial search operation, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that items or blocks are excluded, nor does it reference sibling tools like find-item or find-blocks-by-type for those cases. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. The phrase 'Get information' clearly implies a read-only operation, but the description does not describe what information is returned (e.g., block type, properties), nor any potential errors such as out-of-bounds coordinates. It adds only the most basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and front-loaded sentence. Every word contributes to conveying the tool's purpose; there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This simple tool has no output schema and no annotations, so the description should explain what kind of information is returned and possibly distinguish it from siblings. It does neither, leaving the return value vague and the usage context unclear. The lack of any guidance on when to use this instead of 'get-blocks-info' is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the three parameters, each described as a coordinate. The description's phrase 'at the specified position' merely reinforces the schema's meaning without adding details about coordinate format, bounds, or how they are interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('Get information') and resource ('a block'), and scopes it to 'the specified position'. This distinguishes it from the sibling 'get-blocks-info' (plural) and 'get-nearby-block-types' to some degree, but it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling tools like 'get-blocks-info' or 'get-nearby-block-types'. There is no mention of prerequisites, limitations, or context in which this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavior disclosure. It explains the core jump-and-place behavior but fails to mention important traits like block consumption from inventory, the optional mining behavior (allowMiningOf), or potential risks. This is a significant gap for a movement tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and perfectly concise. The first sentence describes the core function, and the second adds a use-case hint. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested object parameter (allowMiningOf) and no annotations or output schema. The description is too short to cover important operational details such as how mining is triggered, material requirements, or limits. This makes it insufficient for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (height and allowMiningOf), so schema coverage is 100%. The description adds no additional meaning about how these parameters are used, sticking to the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Build a pillar by jumping and placing blocks below.' This specifies the verb and resource. It doesn't explicitly differentiate from sibling tools like 'move-horizontally-and-up-using-steps', but the mechanism is unique enough to be understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Good for trying to go way up,' which provides a clear context for usage. However, it doesn't mention alternatives or when not to use it, leaving the guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral details. It only states the action without mentioning side effects like inventory consumption, position restrictions, or failure conditions. It is not misleading but critically incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action. Every word contributes value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a world-modifying tool with no output schema or annotations, the description is severely lacking. It does not explain return values, error behavior, or prerequisites, leaving the agent without enough context to safely invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description itself adds no parameter-specific information, relying entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Place a block at the specified position' uses a specific verb and resource, clearly defining the tool's function. It distinguishes itself from sibling tools like 'dig-adjacent-blocks' or 'block-activate' by focusing on placement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., 'move-up-by-pillaring' which also places blocks). There is no mention of prerequisites, such as having the block in inventory or being near the target location.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Send a private message to a player' and does not disclose any behavioral details such as success/failure conditions, delivery guarantees, or additional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action. There is no wasted wording, making it easy to read and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with well-documented parameters, the description lacks usage guidelines and behavioral transparency. It does not explain how this tool fits into the broader context of communication tools, nor does it clarify what happens if the player is offline or any other edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (username and message), covering 100% of the schema. The description adds no additional meaning beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('send') and resource ('private message to a player'), clearly stating the action. It distinguishes itself from the sibling 'send-chat' tool by emphasizing the 'private' nature of the message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like send-chat. The description simply states what it does without any contextual usage cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action ('Execute a trade') and the prerequisite ('open villager'), but does not disclose side effects (e.g., item consumption), failure modes, or what happens on invalid trade index. The lack of detail is a significant gap for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence ('Execute a trade with an open villager') with no unnecessary words. It is front-loaded and immediately clear, earning the highest score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only two parameters and no output schema, the description provides insufficient context. It does not explain the outcome of a trade, error conditions, or whether the villager must be opened beforehand beyond the implicit 'open villager'. For a mutation tool with no annotations, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (times, tradeIndex) having descriptions in the schema. The tool description itself adds no parameter information, so the baseline score of 3 is appropriate; the schema handles the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute a trade') and context ('with an open villager'), distinguishing it from sibling tools like villager-open. While it does not explicitly name alternatives, the verb and resource are specific enough to understand the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with an open villager' implies that a villager must be opened first (likely via villager-open), providing implicit usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites beyond the open villager.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavioral traits. It only states 'using available materials,' hinting at material consumption, but fails to explain failure modes (e.g., insufficient materials), side effects, or what happens when the crafting table parameter is false. This lack of detail undercuts transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words, and it is front-loaded with the key verb. However, it is almost too brief for a tool with multiple parameters and no annotations, lacking an explicit structure that could present additional useful context. Still, it is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description is incomplete. It does not explain the crafting process, prerequisites like having materials or a crafting table, or the effect of the count parameter. The description leaves the agent with insufficient context to handle failure or nuanced use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema's parameter descriptions; it merely says 'using available materials,' which is a general hint. Since the schema fully documents the parameters, this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Craft an item using available materials' clearly states the tool's verb (craft), resource (item), and context (using available materials). It effectively distinguishes from sibling tools like smelt-item, which handles a different process. 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for crafting items, but it does not provide explicit guidance on when to use this tool versus alternatives like smelt-item. There is no mention of exclusions or preferred contexts beyond the basic purpose, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. The phrase 'Wake up from bed' does not mention any preconditions (e.g., being in a bed), side effects, or what happens if the action fails. This is minimal and insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no unnecessary words. All words contribute to the meaning, and the key information is front-loaded. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about the tool's effects and requirements. It does not explain what happens if the player is not in bed or what the result of the action is. The simple statement leaves too much implicit for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description adds no parameter-level detail, which is appropriate. The baseline for 0 params is 4, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Wake up from bed' clearly states the action with a specific verb and object. It distinguishes itself from the sibling tool 'bed-sleep', which is its inverse, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used after sleeping, nor does it name any sibling tools like 'bed-sleep' as a complement. This lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose failure conditions (e.g., chest full, insufficient items), partial deposit behavior, or any distance/line-of-sight requirements. This is a minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly and efficiently states the tool's function, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, there are no annotations, no output schema, and the description omits preconditions, edge cases, and failure scenarios. It is minimally adequate but leaves important behavioral context unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 5 parameters (coordinates, itemName, count), covering 100% of parameters. The tool description does not add any parameter-specific semantics beyond the overall purpose, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb ('Put') and resource ('items from the inventory into a chest'). It distinguishes from sibling tools like chest-withdraw (taking items out) and drop-item (dropping on ground).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives. It implies usage for depositing items, but there is no guidance comparing it to chest-withdraw or drop-item. The sibling list is provided but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Take items from a chest into the inventory' only states the core action and lacks details about side effects (e.g., items being removed from the chest), prerequisites, potential failures (e.g., insufficient space, empty chest), or any additional behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It earns its place by conveying the essential action and direction. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description should provide more context about outcomes, edge cases, or any special conditions. It simply states the action without mentioning what happens on success or failure, whether the chest loses items, or any requirements like proximity or opened inventory. This is inadequate for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 5 parameters (coordinates, itemName, count). The description adds no additional parameter semantics, so the baseline of 3 is appropriate. The parameter names and descriptions already carry the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Take'), specifies the resource ('items from a chest'), and clarifies the destination ('into the inventory'). It clearly distinguishes from sibling tools like chest-peek (view only) and chest-deposit (opposite direction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (moving items from chest to inventory) but does not explicitly mention when to use it versus alternatives like chest-peek or chest-deposit. There is no exclusion or alternative guidance, but the core context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It reveals sorting order but does not mention what the tool returns (e.g., coordinates), how 'distance' is measured, or whether it is a read-only operation. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and object, and includes a useful behavioral qualifier. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain return values and edge cases. It does not state what a successful result looks like, how distance is computed, or behavior when no blocks are found. This makes the description incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, so the baseline is 3. The description's sorting detail relates to maxDistance and maxResults but does not add new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource ('Find blocks of a specific type') and adds a distinctive sorting detail ('sorted by distance, closest first'). This distinguishes it from sibling tools like find-item and get-nearby-block-types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description: use when you need to locate blocks by type. However, there is no explicit mention of when to choose this over alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the tool's purpose without describing what happens on success/failure, what data is returned (e.g., slot, count), or whether the search is exact or partial. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or repetition. It is concise and front-loaded, earning a high score for structure even though it omits some behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is still incomplete. It lacks essential context about return values, search behavior, and error handling, which is especially important because the agent cannot infer these from the schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter with a clear description ('Name or type of item to find'). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'find' and clearly identifies the resource as 'a specific item in the bot's inventory'. This distinguishes it from sibling tools like list-inventory (which lists all items) and find-blocks-by-type/find-entity (which search in the world, not inventory).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific item is needed by name or type, but it does not explicitly contrast with list-inventory or other alternatives. No 'when to use' or 'when not to use' guidance is provided, so the context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core behavior ('Send a chat message') which is transparent, but it does not mention whether the message is broadcast to all players, potential rate limits, or required permissions. This is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It is appropriately brief and front-loaded with the action verb, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is nearly complete. It would benefit from specifying that the message is public chat, but the core action and parameter are adequately covered for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%: the 'message' parameter is fully documented as 'Message to send in chat'. The tool description adds no additional parameter semantics beyond what the schema already provides, 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a chat message') and the resource ('in-game'). It distinguishes from read-chat and player-whisper by virtue of the verb and resource, though it does not explicitly specify public versus private messaging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as player-whisper (private message) or read-chat (reading messages). The description lacks any contextual cues about public vs. private chat or prerequisites like being in-game.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full burden. It does not disclose effects like item consumption, cooldowns, failure conditions, or what happens after use. The examples only illustrate the action, not behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-crafted sentence with concrete examples. It is highly concise, front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema), the description provides adequate purpose but lacks behavioral details like return values or failure modes. It is sufficient for a simple action but could be slightly more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the offhand parameter. The tool description adds no extra parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (use) and the resource (currently held item), with specific examples (shoot bow, raise shield, throw snowball, drink potion) that distinguish it from sibling tools like equip-item or block-activate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples imply when to use the tool (e.g., when wanting to shoot or raise shield), but there is no explicit guidance on when not to use it or alternatives. For a tool with many siblings, this is minimal but acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention prerequisites (e.g., item must be equipped), potential effects, failure cases, or whether the item is consumed, leaving significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that includes illustrative examples without verbosity. Every word contributes to clarifying the tool's function, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and full schema coverage, the description provides adequate context for a simple action tool, but it lacks explicit guidance on when this tool is preferred over similar sibling tools like entity-interact. Missing behavioral specifics also reduce completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for both parameters, so the description does not need to explain them. The examples in the description add mild illustrative value but do not add significant meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Use held item on entity' plus concrete examples ('shears on sheep, dye on wolf'), making the action and target clear. It distinguishes itself from sibling tools like attack-entity or entity-interact by emphasizing the item-based interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by mentioning held items and examples, but it does not explicitly state when not to use it or contrast with alternatives such as entity-interact or attack-entity. The usage context is understandable 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must communicate safety and side effects. It doesn't explicitly state that this is a read-only operation, nor does it describe the return format, coordinate system, or units. This leaves significant behavioral ambiguity for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise, and contains no filler. It effectively communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no params, no annotations), the description is adequate but leaves the return value unspecified. There is no output schema to compensate, so the agent still doesn't know what the response will look like. Slightly more detail about the format would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, making parameter semantics trivial. The baseline of 4 is appropriate since no parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource ('current position of the bot'). It is distinct from sibling tools like 'get-status' or 'look-around', which suggest different concerns, so 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when this tool should be used versus alternatives. There is no mention of prerequisites or contexts where this is preferred. The description only states the function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the basic loop (mine, walk, repeat) but omits critical behavioral constraints: it does not mention that only blocks in the 'allowMiningOf' mapping are mined, how failures are handled (e.g., unminable blocks), or potential side effects like dropping items or causing falls. This is insufficient for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently captures the core action and purpose. It could have included a second sentence for constraints without becoming bloated, but as-is it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that modifies the world (mining) with 6 parameters and no output schema or annotations, a one-sentence description is incomplete. It lacks information about failure modes, relationship between target coordinates and numBlocksForwards, stopping conditions, and what the agent should expect after execution. The schema covers parameters but not the behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds minimal value by referencing 'the specified number of blocks,' which aligns with 'numBlocksForwards' but does not clarify the role of targetX/Y/Z or the semantics of 'allowMiningOf' beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Mines blocks ahead and walks forward, repeating for the specified number of blocks.' It clearly distinguishes this tool from siblings like 'move-horizontally' by specifying the mining mechanism and its underground 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'to make progress underground.' This implies the tool is for horizontal movement through blocks, which differentiates it from plain movement tools. However, it does not explicitly state when not to use it or mention alternative tools for non-mining movement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation ('Get information') but does not disclose what information is returned, how errors are handled, or any preconditions. This is a minimal description that leaves many behavioral aspects unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and one fully documented parameter, the description is mostly sufficient. However, without an output schema, it would benefit from specifying what kind of information is returned, but for a simple query tool it doesn't feel severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the 'positions' parameter with an example and type definition, so the description adds no additional semantic value. The 100% schema coverage means 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Get information about multiple blocks') with a specific verb and resource. The mention of 'multiple' distinguishes it from 'get-block-info' and other block-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like get-block-info or find-blocks-by-type. The description does not include any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It accurately describes the read-only nature and the return data (counts and closest distance), but lacks details on the exact area bounds, potential costs, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that immediately conveys the tool's action and output. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers the core output, but without an output schema or parameter guidance, the agent must infer the exact response structure. The 'nearby area' is also ambiguous without distance context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the purpose of individual parameters, and the schema itself leaves maxDistanceUpDown undocumented. While it contextualizes 'nearby area', it fails to compensate for the missing parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving unique block types and entity types in the nearby area, along with counts and closest distance. This distinguishes it from sibling tools like get-block-info and find-blocks-by-type, which focus on specific blocks or types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for surveying the nearby environment but does not explicitly state when to use it over alternatives like get-blocks-info or show-adjacent-blocks. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It states the action ('get') but does not explicitly confirm that this is a read-only operation with no side effects, nor does it mention ordering, limits, or any error conditions. The minimal statement leaves gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It is front-loaded and efficiently conveys the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description adequately conveys what it does ('get recent chat messages'). While it could be more explicit about the exact return format or ordering, the simplicity of the tool means this level of detail is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter 'count' with a default and description (100% coverage), so the baseline score of 3 applies. The tool description adds no additional parameter context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('recent chat messages from players'), distinguishing it from siblings like send-chat or player-whisper. The purpose is unambiguous and immediately understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is the tool for reading recent chat messages. However, it does not explicitly state when to use it versus alternatives or provide exclusions, though the context makes this fairly clear for a simple read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly states the action but does not address failure conditions (e.g., no villager within maxDistance), potential UI side effects, or whether it requires the player to be idle. This is adequate for a simple action but lacks edge-case transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded, conveying the exact purpose with no unnecessary words or repetition. Perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 core functionality well. Missing details like fallback behavior when no villager is found are minor and do not significantly impede understanding or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, maxDistance, is fully documented in the schema with a description and default value. The tool description adds no extra meaning beyond the schema's explanation, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('open') and resource ('trade window with nearest villager'), clearly distinguishing it from trading itself (villager-trade) and other interactions. The scope ('nearest') adds precision 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 Guidelines2/5Does 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 like villager-trade or entity-interact. The description implies it is the first step for trading but does not explicitly state exclusions or prerequisites, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the basic action and does not mention potential risks (e.g., falling, lava), the constraint that only blocks listed in allowMiningOf are mined, or stopping behavior. This is a significant gap for a mining tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and a useful usage hint. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and usage but misses critical context such as safety implications, behavior when encountering unminable blocks, and the role of allowMiningOf. Given the simplicity of the tool and the schema richness, the description is adequate but not complete for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (digTimeout, allowMiningOf, blocksToDigDown) already described in the schema. The tool description adds no additional parameter meaning, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Dig straight down by mining blocks directly below the bot.' This distinct verb+resource+scope differentiates it from sibling tools like dig-adjacent-blocks or move-horizontally-by-mining.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Good if the target is far down' provides a clear usage context. However, it does not explicitly exclude other scenarios or name alternative tools, stopping short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the primary behavior (consuming food) and the effect (restoring hunger), which is useful. However, it does not mention failure conditions (e.g., no food in inventory) or any cooldown requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, 'Consume food to restore hunger', with no wasted words. It is appropriately sized for a tool with one optional parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional param, no output schema), the description is adequate but leaves some gaps: it does not mention that itemName is optional or that auto-selection occurs, nor does it explicitly state prerequisites like requiring food in inventory. It provides a basic, but not fully comprehensive, context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the parameter itemName is described with 'Name of the food item to eat (auto-select if not provided)'. The tool description adds no extra parameter information, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Consume' and the resource 'food', with the purpose 'restore hunger'. This is specific and distinguishes the tool from siblings like craft-item, smelt-item, and activate-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when hunger needs restoring, but does not explicitly state when to use this tool versus alternatives such as activate-item or explicitly mention when not to use it. Guidance is present only by inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states the action, without addressing edge cases such as what happens if the player is not currently mounted, whether the operation can fail, or any other 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple parameterless action but lacks context about preconditions or failure modes. An agent might benefit from a note like 'No effect if not currently mounted' to fully understand the behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100% (vacuously). The description need not explain parameters, and the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Dismount from current mount' uses a specific verb ('dismount') and resource ('current mount'), clearly indicating the action. It distinguishes from the sibling tool 'entity-mount', which performs the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It is implied that one should use it when mounted and wanting to dismount, but no context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions checking state and collecting output, which implies a mutating action, but does not elaborate on side effects (e.g., removing items from furnace, inventory full handling), prerequisites (e.g., proximity to furnace), or failure modes. This is a significant transparency gap for a tool that modifies 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the primary action ('Check furnace state') and packs in the specifics (input/fuel/output/progress) and the secondary action (collect output). No unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the state check returns. It lists the components (input/fuel/output/progress) but does not specify the return format or any error conditions. It is adequate for a simple tool but leaves some ambiguity about the 'state' result and collection behavior when no output exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (x, y, z) including the default for x being the nearest furnace. The tool description adds no additional meaning about these parameters, so it does not go beyond the schema. Baseline of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check furnace state') and specifies the scope ('input/fuel/output/progress') as well as a second action ('collect any smelted output'). This distinguishes it from siblings like smelt-item and craft-item, which focus on initiating or transforming items, and from chest-peek which is for chests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to inspect a furnace and retrieve smelted items. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous given the tool's name and sibling list. The lack of explicit 'when not to use' guidance prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds useful behavioral detail by specifying that only X and Z axes are affected and that the bot remains within the current block. However, it does not disclose potential side effects or failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the action and scope without unnecessary words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema action, the description covers the essential behavior thoroughly, though it could briefly mention if there are any failure conditions or prerequisites for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the schema is empty and the description does not need to explain parameter details. The description's clarity about the action fully compensates for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'center' with a clear target 'bot in both X and Z axes within the current block', making its function distinct from sibling movement tools like move-horizontally or look-at.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives, nor any exclusions or prerequisites. It simply states the action without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Get' implies a read-only operation, but the description does not explicitly state side effects, permission requirements, or limitations. With no annotations provided, behavioral transparency is only lightly addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that immediately states the tool's function, with no wasted words or redundancy. It front-loads the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions health, food, and other status information, but the vague 'other' leaves some ambiguity about the full return set. For a zero-parameter read tool, this is mostly adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description is not required to explain parameter formats. The tool is trivially parameter-free, meriting the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and identifies the resource as 'the bot's health, food, and other status information.' This clearly distinguishes it from action-oriented sibling tools, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like get-position or get-block-info. There is no mention of exclusions or preferred contexts, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the equipment requirement, but does not explain what happens after starting fishing (e.g., whether the agent waits for a bite, needs water, or how the action ends), leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence expresses the action and its key prerequisite. It is front-loaded with 'Start fishing' and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and the simple nature of the action, the description is adequate but still leaves out conditions like proximity to water or the duration of the fishing action. It meets the minimum viable level without exceeding it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially complete. The description adds no parameter details, but none are needed; the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start') and resource ('fishing'), making it immediately clear what the tool does. It also distinguishes itself from sibling tools by mentioning the equipment requirement, which is unique to this action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition ('requires fishing rod equipped'), giving the agent explicit context for when the tool is valid. It does not mention alternatives or exclusions, but for a simple start action, this is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It states the core behavior (jumping over an obstacle in the direction of the target) and a limitation (obstacle height 1). However, it does not disclose failure modes (e.g., what happens if the obstacle is too tall), prerequisites (must be on ground), or whether it moves the bot to the other side. The description is not misleading but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no superfluous information. The first sentence states purpose, the second gives a usage criterion. Both earn their place and are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three required parameters and no output schema. The description explains the action and a key limitation (obstacle height 1) but does not describe what happens on failure, whether the action is instantaneous, or how it relates to alternative movement tools. It is minimally complete for deciding when to use, but lacks richer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, with each parameter described as 'Target X/Y/Z coordinate to determine direction.' The description reinforces this by noting the jump is 'in the direction toward target' but does not add new semantics beyond the schema. Baseline 3 is appropriate when the schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Jump over a small obstacle ahead of the bot in the direction toward target.' It specifies the resource (obstacle), the verb (jump over), and the direction logic (toward target). This distinguishes it from siblings like 'jump-in-place' (no directional movement) and 'move-horizontally' (no obstacle clearing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by noting it is 'Good for obstacles of height 1 (blocking the bot's feet but not head).' This implies when to use it (short obstacles) but does not explicitly name alternatives or state when not to use it (e.g., for taller obstacles). It gives clear context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It implies a read-only operation via 'List', but does not explicitly state lack of side effects, permission requirements, or return format. This is adequate for a simple read operation but not fully 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully explains what it does. It is complete and self-contained, leaving no critical gaps about its functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds meaning by specifying 'all items', clarifying the scope of the listing. No additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all items in the bot's inventory'), making it clear and distinct from sibling tools like find-item or equip-item. There is no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for getting a full overview or that find-item should be used for searching a specific item. No exclusions or contextual cues are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the key limitation that it avoids digging/building, but it does not disclose other important behaviors such as obstacle handling, pathfinding, or failure modes. This is a meaningful but incomplete 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the primary purpose and immediately follows with the limitation, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, absence of annotations, and lack of an output schema, the description covers the essential purpose and limitations but lacks information about obstacle handling, error behavior, or explicit alternative suggestions. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (each parameter has a description like 'Target X coordinate'). The tool description adds no additional meaning to the parameters beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Move the bot toward a target block that is more or less the same height (Y) as the bot.' It specifies the action (move), the subject (bot), the target (block at similar Y), and explicitly distinguishes from siblings by noting it does not dig down or build up.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 (target roughly same Y) and an explicit when-not: 'Doesn't dig down (for a low Y target), doesn't build up (for a high Y target), so bad for those.' However, it does not name specific alternative tools, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavior of repeated attacking until death, which goes beyond the annotation-free schema. However, it does not mention potential risks or side effects such as attracting other mobs or the agent taking damage, and there are no annotations to fill this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no extraneous words, front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional params, no output schema), the description is sufficient for an agent to understand the tool's action, though it does not mention return values. The schema covers parameter details, so the combination is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes both parameters (type and maxDistance) with clear descriptions, including default and behavior when type is omitted. The description adds no additional parameter semantics beyond the schema's 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'attack' and identifies the resource as 'nearby entity', with the clarifying behavior 'repeatedly until it dies'. This clearly distinguishes it from sibling tools like entity-interact or entity-use-item-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for attacking/killing entities, but it does not explicitly state when not to use it or mention alternatives. However, the purpose is unambiguous given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Look at' implies a non-destructive read, which is transparent, but it does not disclose limitations like line-of-sight requirements, what happens if the chest is empty, or whether the action can fail. This is a plain statement of behavior without additional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, making it highly concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: 3 position parameters, no output schema, no annotations. The description adequately conveys the operation and implies the return will be the chest's contents. It does not specify return format or error behavior, but given the low complexity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptive names ('X coordinate', etc.) and types. The description's phrase 'specified position' adds no meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Look at the contents of a chest at the specified position'. It clearly differentiates from sibling tools like chest-deposit and chest-withdraw, which modify contents, and look-at, which targets general blocks/entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for inspecting chest contents at a given position, but it does not explicitly mention alternatives or when not to use it. The context is clear enough for an agent to select this over deposit/withdraw tools, but no explicit exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It discloses the asynchronous nature (returns once the furnace is lit, not when smelting completes), which is valuable. However, it doesn't explicitly state that items and fuel are consumed, nor does it mention prerequisites like needing a furnace nearby. This is a notable gap for a resource-consuming tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and immediately followed by the key return behavior and follow-up instruction. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description covers the core action, the immediate return condition, and directs to the appropriate follow-up tool. It doesn't cover edge cases like an already-lit furnace or failure scenarios, but the essentials are present and the workflow is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for all three parameters (itemName, count, fuelName) with 100% coverage. The description adds no additional parameter semantics beyond reiterating that items and fuel are loaded, which is already clear from the schema. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: load a furnace with items and fuel and start smelting. It uses a specific verb+resource and distinguishes it from siblings like craft-item (crafting) and furnace-check (checking progress/collecting output).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: use this tool to start smelting, then use furnace-check later to see progress and collect the output. It implies when to use the tool and directs to the appropriate follow-up, though it doesn't explicitly list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job disclosing the loop, stopping condition, and jump state management. It could mention edge cases like obstacles, but overall it is transparent about the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three succinct sentences that each add key information: the action, the mechanism, and the ending state. There is no irrelevant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description provides substantial behavioral detail. It covers what the tool does, how it stops, and the final state, though it does not address potential failure modes or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema, meeting the high coverage baseline. The description refers to 'target position' but does not add further detail beyond the coordinate names, so it remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('swim horizontally') and target resource, and distinguishes it from movement siblings by specifying aquatic movement and loop behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use in water and mentions the final jump state, but it does not explicitly state when to use this versus other movement tools like move-horizontally. Usage context is inferred from the word 'swim' rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the two main behaviors: skipping the night and setting the spawn point. It does not mention failure conditions or prerequisites, but for a simple action this is reasonably 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the key verb and resource. Every word contributes to meaning without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description adequately explains its purpose and effects. It does not describe return values, but no output schema exists and the action is straightforward. The main gap is lack of mention of potential failure conditions, but this is a minor omission for a 3-param action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter (x, y, z) having a basic description like 'X coordinate'. The tool description does not add additional meaning to the parameters, but since the schema already describes them adequately, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sleep in a bed') with its two primary effects: skipping night and setting spawn point. It distinguishes itself from sibling tools like bed-wake, and is specific about the resource and outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 (to skip night and set spawn point). It does not explicitly mention exclusions or alternatives, but the stated purpose serves as a strong usage guideline. Given there are no annotations, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the behavior: toggling jump state on/off and the conditional effect when underwater. It adds context beyond the schema by explaining that holding jump (when enabled) causes upward swimming, which is not inferable from the parameter alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences that front-load the primary action, then provide a key conditional behavior, and end with a usage suggestion. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean toggle with one parameter, the description covers the essential behavior: what toggling does, the underwater nuance, and how to control swimming/jumping. It does not mention return values, but given the tool's simplicity and lack of output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'enabled' with a clear description. The tool description reinforces this meaning but does not add significant new details beyond what the schema states, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'toggle' and identifies the resource as the bot's jump state, which clearly distinguishes it from siblings like 'jump-in-place' or 'move-horizontally'. It also explains the underwater swim-up behavior, further clarifying its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Use this to control swimming or jumping state,' providing clear context for when to use this tool. It implies that this tool is for maintaining a jump state rather than performing a one-off action, but it does not explicitly rule out alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full transparency burden. It explains the exact spatial coverage (horizontal directions and height levels) and the bot's 2-block height, which adds significant behavioral context. The verb 'show' implies a read-only operation, though return format and side effects are not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, with the core purpose in the first sentence and additional context in the second. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description defines the scope of blocks shown, it does not mention what information is returned for each block (e.g., type, position, visual representation). With no output schema, this is a notable gap, though the tool's simplicity and clear purpose make it usable as-is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the baseline score is 4. The description appropriately adds no parameter-specific details, as none exist; the schema alone is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Show') and resource ('all blocks directly adjacent to the bot'), with explicit details on horizontal directions and height levels. This clearly distinguishes it from sibling tools like get-nearby-block-types or get-block-info, which have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Good first call when stuck' provides explicit usage guidance, making it clear when to use this tool. While it does not name alternative tools or exclusions, this contextual hint is sufficient for a simple reconnaissance tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently lists all data returned and implies a read-only operation via 'Get' and 'snapshot'. It does not explicitly state side effects or limitations, but for a zero-parameter situational lookup this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long. The first sentence front-loads the core function and enumerates the data returned; the second sentence gives usage guidance. Every word earns its place, with no unnecessary padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description clearly enumerates all major data categories (position, health/food, held item, inventory summary, time, nearby entities, adjacent blocks), making the return value understandable. It does not specify exact formats or ranges, but this is sufficient for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The description adds no parameter details because none are needed; per the rubric, 0 params receives a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('full situational snapshot') and enumerates all included data: position, health/food, held item, inventory summary, time of day, nearby entities, and adjacent blocks. This clearly distinguishes it from targeted sibling tools such as get-position, look-at, and list-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Good first call after spawning or when unsure what's going on'), providing clear context. However, it does not name alternatives or explicitly say when not to use it, so it stops 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.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hibukki/minecraft-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server