Skip to main content
Glama

mc_act

Interacts with the Minecraft world to look, move, build, break, use items, attack entities, equip gear, and operate crafting stations such as enchant, anvil, and smithing.

Instructions

与游戏世界互动(优先用它,别用服务器指令)。mode: · look 看向坐标(x,y,z)或玩家(who):"看向我" = look + who · toward 看向并走近某个玩家(who) · place 放方块到 (x,y,z);悬空先垫脚(=搭高) · bridge 搭路:朝 (x,y,z) 一格格铺(铺在脚下一层),每块等服务端确认了才走;有坠落/岩浆风险就停 · break 破坏 (x,y,z):先自动换对的工具;换不上就拒绝 · use 使用方块或实体(who):开门、按钮、拉杆、喂动物;都不给=用手上的东西 · useitem 用手上的东西:扔眼睛/雪球、拉弓、喝药水 · attack 打实体:who 按名字找(中英文都认,24 格内会追);不给就打 4.5 格内最近的(怪优先)。约 10 秒 · equip 装备(name):护甲自动穿到对应格(盾→副手),其余拿到手上;to 指定格子 · enchant 附魔台:自动开窗放料;option:0-2 真附魔,不给只报选项 · anvil 铁砧:action:combine(默认) / rename;item + name · smithing 锻造台:item 底座、name 附加、template 模板 · toss 丢弃物品(name, count)

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
zNo
toNoequip 装哪格:head/torso/legs/feet/off-hand/hand;只给 = 脱掉
whoNo玩家或实体名(look/toward/use/attack)
holdNouseitem 按住毫秒(拉弓 1000)
itemNoenchant/anvil/smithing 哪件(默认手上)
modeNo见上面各 mode(默认 look)
nameNo方块或物品名(place/equip/toss/anvil/smithing 用)
countNotoss 丢几个(默认 1)
actionNoanvil:combine(默认)/ rename
optionNoenchant 第几项(0/1/2)
approachNotoward 走近吗(默认 true)
budgetMsNotoward 走近毫秒(默认 10000)
templateNosmithing 的模板(默认自己挑)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden, and it discloses genuinely useful behavior: bridge waits for server confirmation per block and halts on fall/lava risk; break auto-switches tools and refuses if none fits; attack chases named entities within 24 blocks and runs ~10s; equip auto-routes armor to slots; enchant opens the window automatically. It still omits session/auth prerequisites and what happens when place/use fail.

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?

The priority instruction is front-loaded, followed by a tight one-line-per-mode bullet list that stays efficient despite covering 14 modes. A few schema descriptions are echoed verbatim (e.g., the equip 'to' note), which is the only redundancy.

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 15-parameter, 14-mode tool with no annotations and no output schema, the definition covers mode selection, per-mode parameters, auto-behaviors, and safety halts well. It leaves out return/failure semantics per mode and any session prerequisite, which matters given the mode breadth.

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 80%, so the baseline is 3, but the description goes further and binds every mode to its parameters inside the mode bullets (who for look/toward/use/attack, to for equip slots, item/name/template for anvil/smithing, count for toss), adding real coupling semantics the flat schema cannot express.

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

Purpose4/5

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

It states a concrete verb-plus-resource ('与游戏世界互动') and enumerates 14 modes (look/toward/place/bridge/break/use/useitem/attack/equip/enchant/anvil/smithing/toss), so an agent knows exactly what it does. However, it never distinguishes itself from siblings who overlap heavily (mc_dig for break, mc_build for place/bridge, mc_move for toward, mc_chest for use), so the boundary remains ambiguous.

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

Usage Guidelines4/5

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

It gives explicit and clear guidance: 'prefer this, don't use server commands' (which routes against mc_command), plus per-mode triggers such as look+who for 'look at me', and risk-based stop conditions for bridge. It offers no exclusions against mc_dig, mc_build, or mc_move, which is the main missing piece.

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