Skip to main content
Glama

Anvil migration path

anvil_migration_path

Compute the cheapest Minecraft anvil combine path to migrate an item's existing enchantments (and prior-work penalty count) to a target enchantment set. sourceItem and targetItem must be the same item id (e.g. both 'diamond_sword') — a mismatch is a tool error, not a silent conversion. Inventory usage is set by two optional inputs: with no availableSources the inventory is not used ("Don't use": every needed book/item is assumed obtainable); with availableSources the plan may use them when they help and assumes the rest is obtainable ("May use"); with inventoryOnly: true, which is never implied, only the listed items are considered, lower levels may be combined into higher ones (two same-level books into the next level) but no outside book is ever assumed ("Only use"; a plan the inventory cannot complete comes back as error 'blocked_plan'). Optional objective: 'min_xp' (default, fewest XP levels) or 'min_prior_work' (fewest anvil operations on the finished item so it stays cheap to upgrade later, then fewest XP levels); when set, the response also reports the objective used, the total XP and the result's prior-work count. Returns ordered combine steps, per-step and total cost, feasibility, and a plain-language summary. Fails clearly, as a tool error, if the target requires downgrading an enchantment level (not possible on a vanilla anvil).

Input Schema

NameRequiredDescriptionDefault
editionNoMinecraft edition; defaults to 'java'
versionNoGame version, e.g. '1.21.4'; defaults to the latest supported version for the chosen edition
objectiveNoWhat to optimise. 'min_xp' (default) finds the plan with the fewest total XP levels. 'min_prior_work' finds the plan whose FINISHED item has the lowest prior-work count (fewest anvil operations on it, so it stays cheap to upgrade again later — each extra operation doubles the prior-work penalty of any future combine), and among plans with that count picks the cheapest in XP. 'min_prior_work' may cost more XP; when this parameter is given the response also reports the objective used, the total XP and the result's prior-work count so the two modes can be compared. Omit for the original min_xp behaviour and response.
sourceItemYes
targetItemYes
inventoryOnlyNo"Only use": only if you set this to true (it is never implied, not even when availableSources is non-empty). The plan then considers only the items in availableSources (respecting each one's quantity/unlimited) and never assumes an outside book is obtainable. It may still start by combining lower levels into higher ones, for example two same-level books into the next level. If the inventory cannot reach the target, the result is feasible: false with error 'blocked_plan' (the cheapest plan assuming each missing book, with blockers). Omit it or pass false for the default ("Don't use" with no sources, "May use" with sources).
availableSourcesNoThe books/items the player already owns, i.e. the inventory. Omit it or pass [] for "Don't use": no inventory is provided, so the plan assumes every needed book/item is obtainable (a fresh single-enchantment book for each target enchantment). Pass one or more sources for "May use": the plan picks those that make it cheaper, ignores the ones that don't help, and still assumes anything the sources cannot provide is obtainable. Passing sources never implies "Only use"; that needs inventoryOnly: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/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: it discloses that a source/target id mismatch is an error rather than a silent conversion, that a downgrade is impossible on a vanilla anvil, that an incomplete inventory returns feasible: false with error 'blocked_plan', and that min_prior_work may cost more XP. It also describes the return shape (ordered steps, per-step and total cost, feasibility, plain-language summary).

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

Conciseness3/5

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

The purpose is front-loaded, which is good, but the body is one dense block of long parenthetical sentences that restate the three inventory modes already spelled out in the availableSources and inventoryOnly schema descriptions. It is informative but hard to scan and somewhat repetitive across the description/schema boundary.

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

Completeness5/5

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

For a 7-parameter tool with nested objects and no output schema, the description covers the essentials: what is computed, how the inventory modes change the answer, what the objective does, and how failures surface. An agent could invoke this correctly without inspecting the schema.

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

Parameters5/5

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

Schema coverage is 71%, and the description adds real meaning beyond it: the same-item-id constraint on sourceItem/targetItem, the fact that inventoryOnly is never implied even with sources, and the trade-off between min_xp and min_prior_work including what the response reports when objective is set. These are behavioral constraints the schema cannot express on its own.

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?

The opening sentence gives a specific verb and resource: compute the cheapest anvil combine path to migrate an item's existing enchantments to a target set. That is far more precise than the title alone and implies a planning tool rather than the sibling anvil_combine_cost. It never names or contrasts the sibling explicitly, so it stops short of full sibling differentiation.

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?

The description lays out the three mutually exclusive inventory modes with the exact input that selects each: no availableSources means 'Don't use', sources mean 'May use', and inventoryOnly: true means 'Only use' and is explicitly never implied. It also states when to pick each objective and which failure conditions (id mismatch, downgrade, blocked_plan) end in a tool error rather than a result.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources