构建配方树

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does well: it discloses that cyclic recipes, tag selection, and probabilistic outputs are already handled, that uncertainties are flagged, and that only the top 3 levels are rendered by default while raw-material totals remain complete across unexpanded branches. It does not state permissions or cost/latency characteristics, but for a read-only analysis tool those are minor.

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?

Two tight paragraphs: purpose and routing first, behavioral caveats and drill-down second. Nearly every sentence earns its place, though the note about deeper branches being marked with 「⋯」 plus node counts is slightly verbose relative to its value.

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 9-parameter tool with nested objects and no output schema, the description does cover the essentials: what the output contains, how depth affects it, and that uncertainty is surfaced. Gaps remain around the maxDepth/detailDepth split and how the four format choices change the response, but the format trade-offs are already spelled out in 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 description coverage is 89%, so the schema already documents item, count, format, detailDepth, tagChoice, recipeChoice, and rawMaterials thoroughly. The description only adds drill-down guidance for detailDepth, and notably never clarifies the relationship between maxDepth (default 8) and detailDepth (default 2) — the one ambiguity in this schema that a description should resolve.

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: recursively expand an item's full crafting chain, list each layer's requirements and craft counts, and aggregate base materials. The user-question framing (「X 怎么做出来的」「做 X 需要哪些原料」) pins down exactly which request maps to this tool, distinguishing it from siblings like get_recipe_details or calculate_production_plan.

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?

Explicitly says it is the first choice when a user asks how an item is made or what raw materials it needs, and gives a concrete drill-down workflow (raise detailDepth, or re-invoke on the child item). It never names an alternative tool or states when NOT to use it — e.g. versus calculate_production_plan — so routing against siblings is only partly covered.

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