Skip to main content
Glama

mc_craft

Craft Minecraft items through the server's real crafting table, automatically planning intermediate steps, placing a workbench when needed, and reporting missing materials with next-step tool suggestions.

Instructions

🧱 合成物品(真合成,走服务端的合成台,不是作弊给物)。生存模式下"原木→木板→工作台→木镐"就靠它。 · 会自动补齐中间产物:给它 name:"wooden_pickaxe",它自己排"木板→木棍→木镐"的顺序一起做,不用你一步步算。 · 需要工作台时:附近有就直接用;附近没有但背包里有,就自己放到脚边再用(placeTable:false 可关)。 · 原料不够会告诉你缺什么、缺几个、现在有几个,并给出下一步该调哪个工具(比如先 mc_dig 砍原木)。 · name 可以写简称:planks 会自动选背包里那种原木对应的木板(选了哪个会写在结果里)。 · list:true 看配方/看当前能做什么;dryRun:true 只出计划不动手(拿不准就先 dryRun)。 · count 是"背包里一共要到几个"(默认 1):已经够了就一个都不做,结果会如实说"一个都没做"。要"再做 4 个"就写 {count:4, more:true}。 · 🔴 连着两三次都"超时"就先 mc_scan 复核现场(我每次动手前都会先把合成格里的材料点回背包)。 🔴 合成只动背包、不动世界,所以不受 mc_observe 门禁限制。

Input Schema

NameRequiredDescriptionDefault
xNo指定工作台坐标 x(可选,和 y/z 一起给)
yNo指定工作台坐标 y(可选)
zNo指定工作台坐标 z(可选)
listNo只看配方,不合成
moreNocount 当"再做几个"(在现有基础上加,默认 false = count 是"一共要到几个")
nameNo要合成的物品(英文 id 或简称,如 planks / stick / wooden_pickaxe)
countNo合成后背包里**一共**要有几个(默认 1)。要"再做 N 个"就加 more:true
tableNo允许用工作台(默认 true)
dryRunNo只出合成计划,不动手(默认 false)
radiusNo附近找工作台的半径(默认 4,最大 8)
placeTableNo附近没工作台时自己放一个(默认 true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

No annotations, so the description carries the full burden and does so thoroughly: auto-crafts intermediate products, auto-places the table from inventory, reports exactly what materials are missing, treats count as a total rather than an increment, resets the crafting grid before each action, and does not touch the world so it bypasses mc_observe gating. This is behavior an agent could not infer from the schema.

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

Conciseness4/5

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

Purpose is front-loaded and the bullets are individually informative with no repetition. It is on the long side with heavy emoji and formatting, but nearly every line earns its place by documenting a distinct behavior.

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

Completeness4/5

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

For an 11-param, no-annotation, no-output-schema mutation-ish tool this covers the critical behaviors: material shortfalls, table placement, count semantics, and grid cleanup. Return-value shape is only sketched ('结果会如实说一个都没做'), leaving minor gaps, but an agent has enough to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond it: name accepts aliases like 'planks' resolved against inventory logs, count is a total unless paired with more:true, and placeTable:false disables auto-placement. It does not add anything for x/y/z/radius/table, which the schema already covers.

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

Purpose5/5

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

States a specific verb+resource ('合成物品') and immediately distinguishes it from the cheating alternative ('真合成,走服务端的合成台,不是作弊给物'). An agent can tell it apart from mc_give without opening either schema.

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

Usage Guidelines5/5

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

Explicitly names the survival workflow it serves, tells the agent to dryRun when unsure, to use list:true to inspect recipes, to use mc_scan after repeated timeouts, and even to call mc_dig first when materials are missing. Clear when/when-not and routed alternatives.

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