Home / MCP Server
Use AnvilCalc from an AI agent (MCP)
AnvilCalc's anvil combine-cost engine is also available as a remote Model Context Protocol (MCP) server, so an AI agent can compute an exact combine plan instead of guessing at enchanting costs or scraping this page.
Endpoint
The server speaks MCP over Streamable HTTP at:
It's public and read-only — no API key or account needed. (The bare domain https://mcp.anvilcalc.com/ returns a small JSON pointer back to this page and the endpoint above; the actual protocol traffic goes to /mcp.)
Try it without any setup
Once AnvilCalc is connected to your AI assistant (see the setup steps below), you don't need to know any tool names or JSON. Just ask in plain language and mention AnvilCalc so the assistant knows which tool to use. Tap Copy and paste one of these:
Use AnvilCalc to plan the cheapest way to build a god sword on a diamond sword in Java Edition: Sharpness V, Looting III, Unbreaking III, Mending, Fire Aspect II and Sweeping Edge III. Show every anvil step and the total XP levels.
Using AnvilCalc, what is the cheapest order to put Efficiency V, Unbreaking III and Mending on a diamond pickaxe if I only have these books: two Efficiency IV, two Unbreaking II and one Mending? Only use the books I have.
Ask AnvilCalc for the cheapest plan to give a diamond chestplate Protection IV, Unbreaking III and Mending on both Java and Bedrock Edition, then tell me how the XP costs and steps differ.
My diamond sword has Sharpness III and Unbreaking I and has been through two anvil operations. Using AnvilCalc, what is the cheapest way to upgrade it to Sharpness V, Unbreaking III and Mending?
Use AnvilCalc to tell me how many XP levels it costs to combine a diamond sword with Sharpness III and an enchanted book with Sharpness IV in a single anvil step.
Connecting a client
The server is public and needs no sign-in, so in every client below choose "no authentication" if it asks. The endpoint is always https://mcp.anvilcalc.com/mcp (Streamable HTTP).
Claude (claude.ai and Claude Desktop)
Go to Customize, then Connectors, click "+ Add" and "Add custom connector". Enter the name AnvilCalc and the URL https://mcp.anvilcalc.com/mcp, and under Authentication choose "No sign in". Then, in a chat, click "+", then "Connectors", and switch AnvilCalc on. Custom connectors are available on all Claude plans (the free plan is limited to one).
Claude Code
claude mcp add --transport http anvilcalc https://mcp.anvilcalc.com/mcpRun /mcp inside Claude Code to check that it is connected.
ChatGPT
Custom MCP connectors in ChatGPT need Developer mode (a beta feature that depends on your plan, and on your workspace admin for Business and Enterprise). Turn it on in ChatGPT's settings, create a new connector (menu names have changed between releases), enter the name AnvilCalc and the URL https://mcp.anvilcalc.com/mcp, and choose "No authentication". Then enable it for a chat.
Cursor
Add this to ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project):
{
"mcpServers": {
"anvilcalc": {
"url": "https://mcp.anvilcalc.com/mcp"
}
}
}VS Code (GitHub Copilot)
Run "MCP: Add Server" from the Command Palette, choose HTTP, and enter the URL, or put this in your mcp.json. Note that VS Code uses servers, not mcpServers:
{
"servers": {
"anvilcalc": {
"type": "http",
"url": "https://mcp.anvilcalc.com/mcp"
}
}
}Other clients
Most other MCP clients that support remote servers accept a config entry like the one below (the key names vary a little between clients, so check yours):
{
"mcpServers": {
"anvilcalc": {
"url": "https://mcp.anvilcalc.com/mcp"
}
}
}To try it without any client setup, point the MCP Inspector at the endpoint above.
Tools
anvil_combine_cost
Simulates exactly one anvil operation — item (the base, left slot) combined with sacrifice (the right slot), optionally renaming the result — with no search or planning involved. It's a direct simulation of a single in-game anvil use, the same way you'd read the cost off the anvil UI with two items in it. Returns the XP-level cost, feasibility, and the resulting enchantments. A book is just "id": "enchanted_book" or "id": "book", not a separate flag — item and sacrifice use the same shape either way, each carrying its own enchantments and prior-work count.
{
"item": {
"id": "diamond_sword",
"enchantments": [{ "id": "sharpness", "level": 3 }]
},
"sacrifice": {
"id": "enchanted_book",
"enchantments": [{ "id": "sharpness", "level": 4 }]
}
}For finding the cheapest multi-step path to a target enchantment set — not just one operation's cost — use anvil_migration_path instead.
anvil_migration_path
Takes two item descriptions — sourceItem (the item's current state: its enchantments, prior-work count, and name, if any) and targetItem (the desired end state). Searches for and returns the cheapest multi-step path from one to the other. sourceItem.id and targetItem.id must be the same item (an anvil can't turn one item type into another) — a mismatch is a tool error, not a silent conversion. Fails clearly if the target would require downgrading an enchantment level — a vanilla anvil can't do that. Optionally takes an availableSources array so the plan reflects books or items you actually have — including their own prior-work count — instead of assuming everything comes from a fresh book. This matters: two Unbreaking II books (say, one from a villager and one fished up) combine into Unbreaking III at a real, calculable cost that a "just assume fresh books" calculator can't give you.
{
"sourceItem": {
"id": "diamond_sword",
"enchantments": [{ "id": "sharpness", "level": 3 }]
},
"targetItem": {
"id": "diamond_sword",
"enchantments": [
{ "id": "sharpness", "level": 5 },
{ "id": "unbreaking", "level": 3 }
]
},
"availableSources": [
{ "sourceId": "book-1", "isBook": true, "enchantments": [{ "id": "unbreaking", "level": 2 }], "priorWorkCount": 0, "origin": "villager_trade" },
{ "sourceId": "book-2", "isBook": true, "enchantments": [{ "id": "unbreaking", "level": 2 }], "priorWorkCount": 0, "origin": "fishing" }
]
}Realistic sourcing: quantity, unlimited supply, and inventoryOnly
Each entry in availableSources can also declare quantity (how many identical physical copies are owned — default 1) and unlimited (true if more can always be obtained on demand, e.g. a standing villager trade — quantity is ignored when this is true). The inventory usage mode follows from the two inputs, the same three modes as the calculator's Inventory usage control: with no availableSources (omitted or [], identical) the inventory is not used (Don't use): every needed book/item is assumed obtainable (a fresh book). With one or more availableSources the plan uses the ones that make it cheaper, ignores the ones that don't help, and still assumes anything they can't provide is obtainable (May use). Passing sources never implies Only use: pass "inventoryOnly": true, which is always explicit, to consider only the declared items. The plan may then start by combining lower levels into higher ones (two Sharpness IV books into a V, an item plus a lower-level book) but never assumes a book from outside, which gives a strictly honest "can this actually be done with only what's declared" answer. If even the cheapest possible sequence busts the level cap, the tool still returns it (marked [EXCEEDS CAP] per offending step) instead of just refusing outright.
With inventoryOnly, a request that needs a book none of your declared sources can provide no longer comes back as a bare refusal either. The result has "feasible": false and "error": "blocked_plan", and carries the cheapest plan that assumes each missing book could be obtained: hypotheticalSteps and hypotheticalTotalCost (the same fields as for exceeds_cap), the placeholder books as unavailableSources ({ id, level }) on the step that first uses them, and a flat blockers list with one entry per reason a step is blocked: { "kind": "unavailable_source", "stepIndex", "enchantment", "level" } or { "kind": "exceeds_cap", "stepIndex", "cost", "cap" } (a step can have both). The text summary marks those steps [UNAVAILABLE: no available source provides mending 1] and/or [EXCEEDS CAP]. exceeds_cap (now also with blockers) means the cap is the only problem. Requests that fail for a structural reason (conflicting enchantments, a level above the maximum, a downgrade, an unknown enchantment, or a target that already holds a conflicting enchantment) keep their existing error and carry no plan. The objective you pass is respected when the blocked plan is built.
Optimization mode: objective
anvil_migration_path takes an optional objective:
"min_xp"(the default) finds the plan with the fewest total XP levels. Leaveobjectiveout and you get exactly the response and plan the tool always returned."min_prior_work"finds the plan whose finished item has the lowest prior-work count — the fewest anvil operations on it — and, among plans with that count, the one that costs the fewest XP levels. Each extra operation doubles the prior-work penalty of any later combine, so this leaves the item cheapest to keep upgrading (netherite gear, long-term tools), at the price of some extra XP now. It is the same choice as the Min XP / Min prior work selector above the plan in the calculator.
When you pass objective (either value), the response also reports the objective used and both numbers: the plan's total XP (totalCost) and the finished item's prior-work count (resultPriorWorkCount), plus a sentence in the text summary — so an agent can call the tool once per mode and compare. Both modes respect the per-step level cap and any rename. The search for min_prior_work is exact for typical builds. It has a 2-second time budget: if that runs out (a pathologically large set of sources), it returns the best legal plan it has found so far, which is then not guaranteed to be the true minimum (the default mode has the same bounded-effort behaviour).
{
"sourceItem": { "id": "diamond_pickaxe", "enchantments": [] },
"targetItem": {
"id": "diamond_pickaxe",
"enchantments": [
{ "id": "efficiency", "level": 5 },
{ "id": "unbreaking", "level": 3 },
{ "id": "fortune", "level": 3 }
]
},
"objective": "min_prior_work"
}For that call, min_xp returns a 3-step plan for 18 XP levels whose finished pickaxe has 3 prior-work operations; min_prior_work returns a 3-step plan for 19 XP levels whose pickaxe has only 2 (it combines the Efficiency and Unbreaking books with each other first, then applies them). The relevant part of the JSON in the second content block is:
{
"feasible": true,
"totalCost": 19,
"renameCost": 0,
"objective": "min_prior_work",
"resultPriorWorkCount": 2,
"steps": [ ... ]
}Optional: rename the item
anvil_combine_cost takes an optional newName param, diffed against item.name. anvil_migration_path's item objects each accept an optional name field — a rename is included only if targetItem.name differs from sourceItem.name (pass "" on targetItem.name to clear an existing name). Either way, renaming costs a flat +1 XP level (plus whatever prior-work penalty already applies to that operation) — the text itself never affects cost.
Editions and versions
Both tools take optional edition ("java" or "bedrock", default "java") and version params. Omit them to get the latest supported version for the edition; an unsupported combination returns a clear error listing what's actually available.
Same engine as the calculator
The MCP server is free to use, with no account or API key. It runs the same calculation engine that powers the calculator on this site — one implementation, two consumers, so the numbers always match.
Privacy
The server stores nothing about your requests. For each tool call it sends one anonymous usage event to Google Analytics: the tool name, success or failure, edition, item type, and a coarse timing bucket, under a random identifier that is not linked to your IP or anything else. The contents of your request are never sent. See the privacy policy.