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 "Install 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?
No annotations are provided, and the description fails to disclose any behavioral traits such as what happens if the item is not found, whether the item is removed from inventory, or what valid destinations are. The description provides no value beyond the name.
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 short (one sentence) but it is under-specified rather than concise. It does not provide enough detail to be genuinely helpful, so it fails the 'earn its place' test.
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 two parameters, no output schema, and no annotations, the description is completely inadequate. Important context like valid destinations, item existence checks, and side effects are missing.
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 describes both parameters with clear descriptions. Schema coverage is 100%, so the description adds no new information. 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 'Equip a specific item' states the action and resource, but is generic and doesn't specify the context (e.g., from inventory to hand/slot). It is marginally clearer than the name alone.
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 like 'craft-item' or 'dig-block'. There is no mention of prerequisites or conditions.
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 full burden but only states the basic operation. It does not disclose what happens when no entity is found, whether it returns coordinates, or any side effects. Behavioral details are insufficient for safe invocation.
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 efficient sentence with no wasted words. However, it is slightly too brief given the lack of annotations and output schema, sacrificing completeness 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?
With no output schema and no annotations, the description should provide more context about return values, defaults, and edge cases. The one-sentence description is insufficient for an agent to fully understand the tool's 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 description coverage is 100% for both parameters, so baseline is 3. The description only loosely echoes the 'type' parameter but adds no new semantic value beyond what the schema already provides.
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 finds the nearest entity of a specific type, distinguishing it from sibling tools like 'find-blocks' and 'find-item' which target different resource types. The verb 'find' and resource 'entity' are specific, and the modifier 'nearest' adds clarity.
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 like 'find-blocks' or 'find-item'. The description does not mention scenarios where entity search is preferred or any prerequisites.
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, and the description does not disclose behavioral traits beyond the basic action. It does not explain what happens if the item is not found, whether it returns partial matches, or any 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 of 9 words that effectively communicates the purpose. Every word serves a function with no redundancy or filler.
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 simple input schema and no output schema, the description is minimally adequate but does not clarify the return value, behavior on missing items, or any limitations. It leaves gaps in understanding for the AI 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?
Schema coverage is 100% with the parameter 'nameOrType' having a description. The tool description adds no additional meaning beyond what the schema provides, so 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 clearly states the tool finds a specific item in the bot's inventory, using a specific verb and resource. It distinguishes itself from sibling tools like 'find-blocks' and 'find-entity' which operate on different resource types, and from 'list-inventory' which returns all items.
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 like 'list-inventory' or 'can-craft'. It does not specify prerequisites, conditions for use, or when to avoid it.
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?
No annotations are present, and the description does not disclose what 'information' is returned (e.g., block type, properties), nor its behavioral safety (though it is likely read-only). This is insufficient for an agent to understand the tool's 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 short sentence with no wasted words, but it could be front-loaded with more detail about return values.
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, the description fails to explain what information is returned. Given the tool's simplicity and 20+ sibling tools, this is incomplete.
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% for all three parameters (x, y, z coordinates), so the description adds no additional semantics beyond the schema. 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 explicitly states the verb 'Get information' and the resource 'block at the specified position', clearly distinguishing it from sibling tools like dig-block or find-blocks.
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 find-blocks or get-position. The description lacks context for tool selection.
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?
No annotations are provided, so the description carries full burden. It states the action but does not disclose if it's a one-time action, any cooldown, or prerequisites (e.g., must be on ground). For a simple action, this is adequate but not detailed.
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 concise sentence that front-loads the action. No wasted words; 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 no parameters or output schema, the description adequately covers the action. However, it could mention if the jump is in place or directional, but for a simple 'jump' it is nearly complete.
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, so the input schema already conveys all needed info. Baseline for 0 parameters is 4; the description adds no extra meaning but is not required to.
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 'Make the bot jump', a specific verb and resource. It distinguishes from sibling movement tools like 'fly-to' or 'move-to-position' as jumping is a distinct immediate action.
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 this tool versus alternatives like 'move-to-position' or 'fly-to'. The usage is implied (when a jump is needed), but no exclusions or conditions are provided.
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?
Without annotations, the description carries full burden but only states the action. It does not disclose whether looking is instantaneous, if it affects other actions, or if there are side effects. This is insufficient for a safe autonomous 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 sentence, concise and front-loaded. It is efficient for a simple tool, though could include a bit more detail without losing 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?
Given the simplicity of the tool (3 required parameters, no output schema), the description is adequate but lacks context like coordinate system reference (world vs local) or behavior (instant vs smooth). It does not leverage additional context from sibling tools.
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 x, y, z as 'X coordinate', etc. The description adds no additional meaning beyond 'specific position', so it meets baseline but provides no 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 'make' and the resource 'bot look at a specific position'. It effectively distinguishes from sibling tools like 'move-to-position' and 'fly-to' which involve movement, not gaze direction.
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. The description does not specify prerequisites, limitations, or context (e.g., whether the bot must be idle or in a certain state).
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?
No annotations are present, so the description carries full burden. It only states the action without disclosing behavioral traits such as rate limits, permissions, side effects, or what happens on success/failure. The agent has no context beyond the basic operation.
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?
Description is a single, front-loaded sentence with no unnecessary text. It efficiently conveys the tool's purpose without redundancy.
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), the description is adequate but minimal. It does not explain return behavior or error conditions, but for a straightforward chat send action, it may be sufficient. However, adding context about message length limits or confirmation behavior would improve 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% and the only parameter 'message' is described in the schema. The description does not add any additional meaning beyond the schema, so 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?
Description clearly states the tool sends a chat message in-game, using a specific verb and resource. It is unambiguous and distinguishes from the sibling 'read-chat' which likely reads 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 is provided on when to use this tool versus alternatives like 'read-chat'. The description does not mention any prerequisites, limitations, or best practices for sending a chat message.
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. Dates show when Glama detected each change.
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-chatEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yuniko-software/minecraft-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
