Skip to main content
Glama

mc_furnace

Smelts ores, sand, logs, and food in a real Minecraft furnace, auto-places a carried furnace, selects fuel, and returns so you can collect finished items later.

Instructions

🔥 熔炼(真熔炼,走服务端的熔炉,不是作弊给物)。生存模式下"粗铁 → 铁锭 → 铁镐"就靠它。 · 能烧:矿石/粗矿(铁、铜、金、远古残骸…)、沙 → 玻璃、圆石 → 石头、原木 → 木炭、生肉/马铃薯 → 熟的、黏土球 → 砖、海带 → 干海带、仙人掌 → 绿色染料 等等。 · 写产物名也行:name:"iron_ingot" 会自动找背包里的粗铁/铁矿石去烧。 · 附近没有熔炉、但背包里有,就自己放到脚边再用(placeFurnace:false 可关);都没有会告诉你去 mc_craft {name:"furnace"} 做一个(8 个圆石)。 · 自己挑燃料:按要烧的数量算,一次放够 —— 有煤炭/木炭就先烧煤(木棍、原木、木板是合成料,只有没有正经燃料时才拿来烧);要烧 1 个放 1 块煤(够烧 8 个),要烧 9 个放 2 块。可以 fuel:"coal" 指定;list:true 看背包里有哪些燃料。 · 🔴 装好料就返回,不用盯着:炉子在服务端自己烧。默认不盯(maxWaitSec 默认 0,最多给 10 秒);过一会儿再叫一次 mc_furnace 就能收成品(不用重新装料)。要烧很多就少量多次(一次最多装 8 个)。 · takeOnly:true = 只把熔炉里已经烧好的拿走(不新塞东西);dryRun:true 只出计划。 🔴 熔炼会动世界里的熔炉,所以受 mc_observe 门禁限制(强制模式要先看)。

Input Schema

NameRequiredDescriptionDefault
xNo指定熔炉坐标 x(可选,和 y/z 一起给)
yNo指定熔炉坐标 y(可选)
zNo指定熔炉坐标 z(可选)
fuelNo指定燃料(可选),如 coal / stick;不给就自己挑
listNo只看熔炼表和燃料(不烧)
nameNo要烧的东西(英文 id 或简称,如 raw_iron),也可以写产物名(如 iron_ingot)
countNo想要几个产物(默认 1,一次最多装 8 个)
dryRunNo只出计划,不动手(默认 false)
radiusNo附近找熔炉的半径(默认 6,最大 12)
takeOnlyNo只取已经烧好的,不新塞(默认 false)
maxWaitSecNo最多盯多少秒(**默认 0 = 不盯**;最多 10)
placeFurnaceNo附近没熔炉时自己放一个(默认 true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses server-side async smelting, maxWaitSec default 0 (no babysitting), auto-placing the furnace (placeFurnace default true), the 8-item batch limit, and that it is gated by mc_observe. It stops short of describing return values or what happens when materials are missing beyond the furnace case, keeping it at 4 rather than 5.

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?

Front-loaded with purpose, then scannable bullets covering fuel logic, wait behavior, and modes. It is long, but justified by a 12-parameter tool; some defaults are restated from the schema, which is the only mild waste.

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

Completeness4/5

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

For a 12-parameter, no-output-schema, no-annotation mutation tool, the description covers defaults, side effects on the world, the observation gate, and failure routing to crafting. Only the precise return shape and non-material error modes are unaddressed, which is acceptable given no output schema.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning: fuel auto-selection math (1 coal per 8, list to inspect), the ability to pass a product name and have raw material located automatically, and the fuel-priority rule (sticks/logs are crafting stock). This goes well beyond the schema's one-line parameter notes.

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 (server-side furnace smelting, explicitly 'not cheating to give items') and anchors it to a concrete goal ('rough iron → iron ingot → iron pickaxe'). It distinguishes itself from crafting by routing furnace-crafting to the mc_craft sibling, so an agent can tell it apart without opening schemas.

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

Usage Guidelines5/5

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

Gives explicit when-to-use, the alternative path when no furnace is nearby (mc_craft {name:"furnace'}), and per-mode guidance for takeOnly, list, and dryRun. The 'load and return, don't babysit' guidance and the batch-size recommendation remove the main decision ambiguity.

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