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.