Cheapest Minecraft anvil combine order and exact XP cost for Java and Bedrock Edition.
Scored across 2 tools
anvil_combine_cost is explicitly a single-operation simulator, while anvil_migration_path handles multi-step planning; each description names the other and states when to use it. Their scopes are clearly disjoint, so an agent can select correctly.
Both tools use the same anvil_<noun>_<noun> snake_case convention with a shared prefix. The pattern is predictable and readable, with no mixing of styles.
Two tools is thin for most servers, though this domain is narrow (single anvil simulation plus path planning). Per the rubric, 1–2 tools is borderline.
The surface covers the core workflows: one-step combine costing and multi-step migration planning, including inventory constraints and objectives. Minor gaps remain (e.g., repair/durability cost or enchantment lookup), but core lifecycle is covered.
Simulates exactly one Minecraft anvil operation — combining item (the base, left slot) with sacrifice (the right slot), optionally renaming the result — with no search or planning: it's a direct simulation of that specific in-game anvil use, not a 'find the cheapest way to reach X' query. Returns the XP-level cost, feasibility, and the resulting enchantments. A sacrifice enchantment the base item cannot take (e.g. Efficiency from a book onto a sword) is ignored by the anvil: cost 0, transferred: false. For finding the cheapest multi-step path from a current state to a target enchantment set, use anvil_migration_path instead.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | ||
| edition | No | Minecraft edition; defaults to 'java' | |
| newName | No | Desired custom name for the result. A rename is included only if this differs from item.name (use '' to clear an existing name) — cost is a flat +1 XP level, the actual text has no effect on cost. Omit to leave the name untouched. | |
| version | No | Game version, e.g. '1.21.4'; defaults to the latest supported version for the chosen edition | |
| sacrifice | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the return payload (XP-level cost, feasibility, resulting enchantments), the rename pricing rule (flat +1 level, text content irrelevant), and a concrete edge case (an inapplicable sacrifice enchantment is ignored: cost 0, transferred: false). It stops short of explaining the 'too expensive' ceiling behavior tied to priorWorkCount or what 'feasibility' concretely encodes, which matters for a simulator whose whole output is a cost verdict.
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 scope constraint and the slot mapping are front-loaded in the first sentence, and the routing hint sits at the end where it belongs. Three sentences all earn their place, though the 'not a find the cheapest way' disclaimer partially restates the routing sentence that follows.
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 nested item/sacrifice objects, five parameters, and no output schema, the description does the essential work of naming the returned fields and covering the rename rule and the ignored-enchantment case. What is missing is the cost-accumulation context (prior-work penalty, the 39-level cap) that determines whether the 'feasibility' field comes back true, which an agent would otherwise have to rediscover.
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?
At 60% schema coverage the description adds real semantics the schema does not: it maps item to the base/left slot and sacrifice to the right slot, and clarifies newName behavior ('included only if this differs from item.name', '' clears, text has no effect on cost). It says nothing about how priorWorkCount or version/edition alter the computed cost, leaving that half of the parameter space to inference.
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?
Uses a precise verb and resource: 'Simulates exactly one Minecraft anvil operation — combining item (the base, left slot) with sacrifice (the right slot), optionally renaming the result.' It also explicitly disclaims the broader interpretation ('not a find the cheapest way to reach X query'), so the agent can distinguish it from anvil_migration_path 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the exact condition for use (a single, already-decided anvil operation with known left/right slots) and names the alternative by name for the other case: 'For finding the cheapest multi-step path from a current state to a target enchantment set, use anvil_migration_path instead.' Both the when and the when-not are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| edition | No | Minecraft edition; defaults to 'java' | |
| version | No | Game version, e.g. '1.21.4'; defaults to the latest supported version for the chosen edition | |
| objective | No | What 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. | |
| sourceItem | Yes | ||
| targetItem | Yes | ||
| inventoryOnly | No | "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). | |
| availableSources | No | The 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
anvil_combine_costanvil_migration_pathMCP server for Pinchwork - an agent-to-agent task marketplace with credits-based economy
Minecraft The Sift portal tools: coordinate converter, materials budget, and ignition diagnostic.
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Add one secure layer between your agents and this server.