The mcp-minecraft server allows a bot powered by Claude (LLM) to control a Minecraft character and interact with the game world through various commands:
Movement: Get position, move to coordinates, look at coordinates, jump, and move in specific directions
Flight: Fly directly to coordinates
Inventory: List items, find specific items, and equip items
Block Interaction: Place blocks, dig blocks, get block information, and find nearest blocks of specific types
Entity Interaction: Find nearest entities of specific types
Communication: Send in-game chat messages
Allows installation of the MCP server directly from GitHub using npx, making setup easier for users.
Required as a prerequisite for running the MCP server, providing the runtime environment for the Mineflayer-based bot.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-minecraft build a small wooden house with a door and two windows"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Currently supports Minecraft version 1.21.11. Newer versions may not work with this MCP server, but we will add support as soon as possible.
https://github.com/user-attachments/assets/6f17f329-3991-4bc7-badd-7cde9aacb92f
A Minecraft bot powered by large language models and Mineflayer API. This bot uses the Model Context Protocol (MCP) to enable Claude and other supported models to control a Minecraft character.
Git
Node.js (>= 20.10.0)
A running Minecraft game (the setup below was tested with Minecraft 1.21.8 Java Edition included in Microsoft Game Pass)
An MCP-compatible client. Claude Desktop will be used as an example, but other MCP clients are also supported
Related MCP server: ainpcengine
This bot is designed to be used with Claude Desktop through the Model Context Protocol (MCP).
Create a singleplayer world and open it to LAN (ESC -> Open to LAN). Bot will try to connect using port 25565 and hostname localhost. These parameters could be configured in claude_desktop_config.json on a next step.
Make sure that Claude Desktop is installed. Open File -> Settings -> Developer -> Edit Config. It should open installation directory. Find file with a name claude_desktop_config.json and insert the following code:
{
"mcpServers": {
"minecraft": {
"command": "npx",
"args": [
"-y",
"github:yuniko-software/minecraft-mcp-server",
"--host",
"localhost",
"--port",
"25565",
"--username",
"ClaudeBot"
]
}
}
}Double-check that right --port and --host parameters were used. Make sure to completely reboot the Claude Desktop application (should be closed in OS tray).
Make sure Minecraft game is running and the world is opened to LAN. Then start Claude Desktop application and the bot should join the game.
It could take some time for Claude Desktop to boot the MCP server. The marker that the server has booted successfully:
You can give bot any commands through any active Claude Desktop chat. You can also upload images of buildings and ask bot to build them 😁
Don't forget to mention that bot should do something in Minecraft in your prompt. Because saying this is a trigger to run MCP server. It will ask for your permissions.
Using Claude Sonnet could give you some interesting results. The bot-agent would be really smart 🫡
Example usage: shared Claude chat
Once connected to a Minecraft server, Claude can use these commands:
get-position - Get the current position of the bot
move-to-position - Move to specific coordinates
look-at - Make the bot look at specific coordinates
jump - Make the bot jump
move-in-direction - Move in a specific direction for a duration
fly-to - Make the bot fly directly to specific coordinates
list-inventory - List all items in the bot's inventory
find-item - Find a specific item in inventory
equip-item - Equip a specific item
place-block - Place a block at specified coordinates
dig-block - Dig a block at specified coordinates
get-block-info - Get information about a block
find-blocks - Find one or more nearby blocks of a specific type
smelt-item - Smelt items using a furnace-like block
find-entity - Find the nearest entity of a specific type
send-chat - Send a chat message in-game
read-chat - Get recent chat messages from players
detect-gamemode - Detect the gamemode on game
Feel free to submit pull requests or open issues for improvements. All refactoring commits, functional and test contributions, issues and discussion are greatly appreciated!
To get started with contributing, please see CONTRIBUTING.md.
⭐ If you find this project useful, please consider giving it a star on GitHub! ⭐
Your support helps make this project more visible to other people who might benefit from it.
Check if the bot can craft a specific item with current inventory
| Name | Required | Description | Default |
|---|---|---|---|
| itemName | Yes | Name of the item to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only mentions checking with current inventory but does not specify return type (e.g., boolean), error handling for unknown items, or whether recipe knowledge is required. Key behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word is essential for the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple check tool with one parameter and no output schema, the description is adequate but lacks precision on what 'can craft' entails (e.g., material availability, recipe existence). No return value explanation is given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter 'itemName' is described as 'Name of the item to check'. The description adds no additional meaning beyond the schema; the mention of 'current inventory' is context but not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'if the bot can craft a specific item with current inventory', distinguishing it from sibling tools like 'craft-item' (which actually crafts) and 'get-recipe' (which retrieves recipe details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking crafting feasibility before using 'craft-item', but it does not explicitly state when to use this tool over alternatives like 'get-recipe' or 'list-recipes'. No exclusion criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Craft an item using a crafting recipe
| Name | Required | Description | Default |
|---|---|---|---|
| outputItem | Yes | Name of the item to craft | |
| amount | No | Number of times to craft (default: 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention whether items are consumed, whether inventory is required, or what happens on failure. The phrase 'using a crafting recipe' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure (e.g., bullet points) and omits necessary details, making it borderline under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal description, the tool is not fully documented. Missing information about return values, error conditions, and consumption of materials limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Craft) and the resource (item using a crafting recipe). It distinguishes from some siblings (e.g., smelt-item), but could be more specific to differentiate from can-craft or get-recipe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like can-craft or smelt-item. The description lacks any context about prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect the gamemode on game
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only states 'detect', implying a read operation, but fails to mention side effects, permissions, or what exactly is returned (e.g., gamemode name or ID). Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) with no wasted text. However, it lacks any structured formatting or front-loading of key information, but for a simple parameterless tool, brevity is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is incomplete. The agent receives no information about what the tool returns (e.g., a string, number, or object). A detect tool should indicate the return value format for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is effectively 100%. The description adds no parameter semantics, but none are needed. Baseline of 4 is appropriate as the schema already captures all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects the gamemode on a game. The verb 'detect' and resource 'gamemode' are specific. It is distinct from sibling tools like 'get-block-info' or 'list-inventory', but does not elaborate on what gamemode entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or when not to use this tool. There are no alternatives mentioned, and no context about prerequisites or scenarios where detection is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dig a block at the specified position
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate | |
| y | Yes | Y coordinate | |
| z | Yes | Z coordinate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as whether digging destroys the block, requires permissions, or has 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Appropriate front-loading of the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. For a state-changing tool, the description lacks essential details about side effects, return values, or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with basic descriptions ('X coordinate'), and the description adds no additional meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'dig' and the resource 'a block at the specified position'. It distinguishes from siblings like 'place-block' and 'get-block-info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Equip a specific item
| Name | Required | Description | Default |
|---|---|---|---|
| itemName | Yes | Name of the item to equip | |
| destination | No | Where to equip the item (default: 'hand') |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, 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.
Find one or more nearby blocks of a specific type
| Name | Required | Description | Default |
|---|---|---|---|
| blockType | Yes | Type of block to find | |
| maxDistance | No | Maximum search distance (default: 16) | |
| count | No | Maximum number of blocks to return (default: 1; values above 256 are clamped) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only repeats that blocks are found nearby. It does not disclose any behavioral traits such as coordinate system, block existence guarantee, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. The verb and key constraints are front-loaded, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not mention return format or behavior when no blocks are found. For a simple find tool, it is acceptable but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions), so the description adds no new meaning beyond the schema. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'find' and resource 'blocks' with scope 'nearby of a specific type', distinguishing it from siblings like find-entity and find-item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when or when-not to use, nor alternatives mentioned. The context of 'nearby' is implied but not elaborated, and there is no comparison to other find tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the nearest entity of a specific type
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Type of entity to find (empty for any entity) | |
| maxDistance | No | Maximum search distance (default: 16) |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It 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.
Find a specific item in the bot's inventory
| Name | Required | Description | Default |
|---|---|---|---|
| nameOrType | Yes | Name or type of item to find |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Make the bot fly to a specific position
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate | |
| y | Yes | Y coordinate | |
| z | Yes | Z coordinate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states a simple action. It does not disclose behavioral traits such as whether the flight is instantaneous or animated, if it ignores obstacles, or if it has any prerequisites like being in the air. This is insufficient for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. However, it sacrifices informativeness for brevity; a slightly longer description could provide more guidance without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple coordinate flight tool with no output schema and no annotations, the description is minimally adequate. It conveys the core function but lacks details on behavior, return values, or prerequisites, which a more complete description would include.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (x, y, z) have descriptions in the schema, achieving 100% coverage. The tool description adds no additional meaning beyond the schema, so it meets the baseline without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fly' and the resource 'to a specific position', indicating the tool's purpose. However, it does not distinguish it from sibling movement tools like 'move-to-position', which may cause confusion for an AI agent choosing between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'move-to-position' or 'jump'. The description lacks context for appropriate usage, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a block at the specified position
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate | |
| y | Yes | Y coordinate | |
| z | Yes | Z coordinate |
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.
Is 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.
Given 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.
Does 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus 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.
Get the current position of the bot
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It indicates a read operation, but does not mention permissions, cost, or side effects. Adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no description of return format (e.g., coordinates, orientation). Leaves ambiguity about what the agent receives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current position', which is distinct from sibling tools like 'get-block-info' and movement commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or not use this tool compared to alternatives like 'fly-to' or 'move-to-position'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific recipe
| Name | Required | Description | Default |
|---|---|---|---|
| itemName | Yes | Name of the item to get recipe for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks details about return value, read-only nature, or any side effects. Only says 'Get detailed information' without specifying what 'detailed information' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. Efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and minimal description. Missing details about expected return format or how it differs from 'list-recipes'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description. Description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'detailed information about a specific recipe'. Distinguishes from siblings like 'list-recipes' and 'craft-item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make the bot jump
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'make the bot jump' and does not explain effects on movement, cooldowns, side effects, or requirements (e.g., being on ground). This is a significant gap for a mutation-like action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is highly concise and front-loaded, effectively communicating the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is adequate for an agent to invoke the action. However, it lacks situational context, such as typical use cases or potential constraints, which would enhance completeness in the broader environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially 100% covered. The description adds no parameter information, but none is needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does 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 and resource (the bot). It is specific and distinct from siblings like goto or look_at, but does not explicitly differentiate itself from alternatives or provide comparative context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The usage is implied by the action name itself but not elaborated, leaving the agent without situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all items in the bot's inventory
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description accurately conveys a read-only listing operation. Beyond that, no additional behavioral traits (e.g., side effects, permissions) are relevant for such a simple tool, so the description 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It is front-loaded and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is complete. It tells the agent exactly what the tool does—listing inventory items—without requiring additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params) and 100% schema description coverage, so the baseline is 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all items in the bot's inventory' uses a clear verb ('List') and specific resource ('items in the bot's inventory'), which is distinct from sibling tools like 'craft-item' or 'find-item' that involve different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs to know the bot's current inventory contents. Since there are no competing list tools for inventory (e.g., 'list-recipes' is different), clear context is provided, though no explicit exclusions or alternatives are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available crafting recipes the bot can make with current inventory
| Name | Required | Description | Default |
|---|---|---|---|
| outputItem | No | Optional: filter recipes by output item name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool lists recipes 'with current inventory', implying real-time filtering, but does not disclose any behavioral traits like idempotency, performance, or side effects. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence of 10 words with no unnecessary information. Front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description adequately covers what the tool does and the condition (current inventory). It does not explain return format, but that is inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any parameter-specific information beyond what the schema already provides for the 'outputItem' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'crafting recipes the bot can make with current inventory', which is specific and distinguishes it from siblings like 'get-recipe' and 'craft-item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for listing recipes the bot can currently make, but it does not explicitly state when to use it versus alternatives like 'can-craft' or 'get-recipe'. No guidance on when not to use or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make the bot look at a specific position
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate | |
| y | Yes | Y coordinate | |
| z | Yes | Z coordinate |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. 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.
Move the bot in a specific direction for a duration
| Name | Required | Description | Default |
|---|---|---|---|
| direction | Yes | Direction to move | |
| duration | No | Duration in milliseconds (default: 1000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral details. It fails to disclose if movement is relative to current facing, continuous or step-based, obstacle handling, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specifies important behavioral aspects. It front-loads the action but misses crucial details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given 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 incomplete. It does not explain return behavior, execution details (e.g., continuous movement), or edge cases like obstacles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no extra meaning beyond what the schema already provides (including the default for duration).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (move), the subject (bot), and key parameters (direction, duration). It distinguishes from siblings like 'move-to-position' which implies coordinate-based movement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use is provided. Usage is implied for directional movement, but alternatives like 'move-to-position' are not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move the bot to a specific position
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate | |
| y | Yes | Y coordinate | |
| z | Yes | Z coordinate | |
| range | No | How close to get to the target (default: 1) | |
| timeoutMs | No | Timeout in milliseconds before cancelling (min: 50, default: no timeout) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details beyond a generic move action. Lacks information on collision handling, pathfinding, blocking behavior, or whether the bot stops exactly at the position. No annotations provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear but very brief. It conveys the purpose without extra words, but could be more informative without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a movement tool with no output schema and no annotations, the description lacks essential details like whether the tool blocks, handles obstacles, or how timeout interacts with movement. Incomplete for an AI agent to anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters adequately (100% coverage). The description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves the bot to a specific position using coordinates. It distinguishes from siblings like fly-to or move-in-direction by the explicit mention of position, but could be more specific about the movement type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like fly-to or move-in-direction. No prerequisites or conditions for usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place a block at the specified position
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate | |
| y | Yes | Y coordinate | |
| z | Yes | Z coordinate | |
| faceDirection | No | Direction to place against (default: 'down') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not disclose important behavioral traits such as whether the block is consumed from inventory, whether permissions are required, or whether there are any side effects. No annotations are present to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence. While it is not verbose, it efficiently communicates the core action without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is minimally adequate. However, it omits information about what block is placed (e.g., the held item) and any success indicators, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning or context beyond what the schema provides, achieving baseline adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Place') and the resource ('a block'), and is distinctive from sibling tools like 'dig-block' or 'craft-item'. It leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that the block must be in the player's inventory, or that this tool is for building while 'dig-block' is for removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent chat messages from players
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of recent messages to retrieve (default: 10, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond being a read operation, such as permissions, latency, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that 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.
Given 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 is adequately complete, though it could mention that it returns an array of messages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no extra meaning beyond what the schema already provides for the 'count' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent chat messages from players' is clear and specific with a verb and resource, distinguishing it from the sibling 'send-chat' which sends messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to read vs send chat, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a chat message in-game
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to send in chat |
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.
Is 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.
Given 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.
Does 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a chat message') and 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives 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.
Smelt items using a furnace-like block
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate | |
| y | Yes | Y coordinate | |
| z | Yes | Z coordinate | |
| inputItem | Yes | Name of item to smelt | |
| inputCount | No | Amount of input to smelt (default: 1) | |
| fuelItem | Yes | Name of fuel item | |
| fuelCount | No | Amount of fuel to use (default: 1) | |
| takeOutput | No | Whether to take output when ready (default: true) | |
| timeoutMs | No | Timeout waiting for output in ms (default: 60000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states the basic action. It omits details like fuel consumption, output collection, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is too sparse. It lacks context on smelting mechanics, fuel requirements, or output handling, which is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond what is in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (smelt items) and the resource type (furnace-like block). It is specific and distinct from sibling tools like 'craft-item' or 'dig-block'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'craft-item' or 'can-craft'. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.2can-craftcraft-itemfind-blockfind-blocksget-recipelist-recipesmove-to-position1 field changedInput schema / properties / timeoutMsAdded value: +{
+ "description": "Timeout in milliseconds before cancelling (min: 50, default: no timeout)",
+ "minimum": 50,
+ "type": "integer"
+}smelt-itemv1.0.0detect-gamemode1 field changedInput schema / additionalPropertiesRemoved value: -falseget-position1 field changedInput schema / additionalPropertiesRemoved value: -falsejump1 field changedInput schema / additionalPropertiesRemoved value: -falselist-inventory1 field changedInput schema / additionalPropertiesRemoved value: -falseread-chatdetect-gamemodedig-blockequip-itemfind-blockfind-entityfind-itemfly-toget-block-infoget-positionjumplist-inventorylook-atmove-in-directionmove-to-positionplace-blocksend-chatScored across 22 tools
Each tool targets a distinct action or query, with clear boundaries between checking and performing (e.g., can-craft vs craft-item, list-recipes vs get-recipe). Movement tools are differentiated by mode (fly vs walk).
All tools follow a consistent verb-noun pattern with hyphens, using imperative verbs like 'dig', 'place', 'find', 'list', 'craft'. No mixing of conventions or vague names.
22 tools cover a broad range of Minecraft bot operations without being overwhelming. Each tool serves a distinct purpose, and the count aligns well with the domain's complexity.
Covers core workflows: movement, block manipulation, inventory management, crafting, smelting, chat, and entity detection. Missing actions like attacking or dropping items are minor gaps that don't severely hinder typical tasks.
MCP server for OpenAI Sora AI video generation
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server for Hailuo (MiniMax) AI video generation
MCP server for Grok Imagine AI video generation
