get_recipe_detailsFetch full inputs, outputs, duration, and energy for one or more Minecraft recipe IDs; pass up to 20 IDs at once to avoid repeated lookups.
按 id 获取配方的完整输入输出、耗时、耗能。需要先通过其他查询拿到具体配方 id。要看多条时用 recipeIds 一次传（最多 20 条）—— 逐条调用会让往返次数随配方数线性增长。
| Name | Required | Description | Default |
|---|---|---|---|
| recipeId | No | 单条配方 id，形如 "minecraft:iron_ingot_from_smelting_iron_ore" | |
| recipeIds | No | 多条配方 id（最多 20）。给了它就忽略 recipeId |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does state what the response contains (inputs/outputs, time, energy). The cost warning about linear round-trip growth is genuinely useful behavioral context. It never says whether the call is read-only or what happens for an unknown id, which are minor but real gaps.
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?
Three short sentences: purpose first, prerequisite second, batching advice last. Nothing is redundant and the efficiency warning earns its place.
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?
Only 2 optional parameters and no output schema, yet the description still names the returned fields and the batching strategy. Nothing an agent needs to call this correctly is missing.
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 100%, so the baseline is 3, but the description adds decision-level meaning: prefer recipeIds for multiple recipes and note that per-item calls scale round trips. The 20-item cap and the recipeIds-overrides-recipeId precedence are restatements of the schema, so no extra credit there.
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?
States a specific verb and resource (按 id 获取配方) and enumerates the returned content (完整输入输出、耗时、耗能), which distinguishes it from discovery siblings like get_recipes_for_output or list_recipe_types. It stops short of explicitly naming which sibling performs the lookup, so it isn't fully differentiated.
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?
Gives a clear prerequisite (需要先通过其他查询拿到具体配方 id) and a clear preference for batch use over per-item calls when fetching multiple recipes. It leaves the discovery step generic ('其他查询') instead of naming search_items or get_recipes_for_output, so the agent still has to infer the entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.