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.

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

No annotations exist, so the description carries the full load, and it discloses a critical behavioral trait: a greedy approximation where each item fixes one recipe and byproducts are counted but not recycled. This is exactly the kind of caveat an agent needs to set expectations. It lacks disclosure of cost/performance or failure modes, keeping it from a 5.

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?

Front-loads the core capability and the trigger condition, then the important greedy-approximation caveat, then the output-focus note. Dense but each clause earns its place; the closing sentence about summary tables being 'the point' is well-placed.

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 complex 9-parameter tool with no annotations and no output schema, the description supplies the essential context: what's computed, the approximation caveat, and what the output emphasizes. Missing explicit return-shape detail, but the summary-table orientation largely compensates.

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 nearly all parameters (ratePerMinute, recipeChoice, tagChoice, rawMaterials, detailDepth, etc.). The description adds framing about summary tables being the focus but little parameter syntax beyond the schema. Baseline 3 is appropriate; note the description says details show 'first 3 layers' while detailDepth defaults to 2, a minor mismatch.

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 (calculate) and resource (production plan: machines, materials, byproducts, energy) with the exact question it answers. An agent can distinguish it from build_recipe_tree or get_recipes_for_output because the output is a full aggregated line plan, not a recipe tree.

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 concrete trigger ('我要每分钟 X 个 Y，怎么建产线') that clearly maps a user request to this tool. It doesn't explicitly name which sibling to use instead for other cases, so it stops short of explicit alternatives/exclusions.

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

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

No annotations are provided, so the description carries the burden. "列出" implies a safe read, and the usage framing makes the intent clear, but it says nothing about permissions, result size, or pagination for tags that expand to hundreds of entries. Adequate but not rich for an annotation-free tool.

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, trigger, and disambiguation, in that order. No filler, and the most important routing information is front-loaded.

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 one-parameter read tool with no output schema and no annotations, the description covers what it does and when to reach for it. The only gap is that it never hints at the return shape (a list of item ids), which an agent calling without an output schema would have to discover at runtime.

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 100% and the schema already spells out the id format and the no-`#`-prefix rule ("forge:ingots/iron"). The description adds nothing about the single `tag` parameter, so the baseline 3 applies.

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 ("列出某个标签包含的所有物品") and immediately grounds it in the concrete scenario where a recipe input shows `#xxx`. It also distinguishes itself from the reverse lookup, naming the siblings that handle that direction (search_items, get_recipes_for_output).

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 an explicit trigger condition ("配方的输入里出现 #xxx 时") plus an explicit when-not with the correct alternatives for the inverse question ("想知道某物品属于哪些标签，用 search_items 或 get_recipes_for_output 的结果"). The agent has no inference left to do.

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

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

With no annotations, the description carries the full burden; it does disclose that results are compared (ingredients + time) and that the tool helps pick a recipe, implying a read-only analytical operation. However, it does not clarify whether the user's current/primary recipe is excluded from '其他做法', nor anything about result ordering, pagination, or volume.

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 short sentences, no filler, with the comparison purpose front-loaded ahead of the trigger conditions. Efficient, though the trigger quotes could be folded in more tightly.

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?

No output schema exists, so the description should convey the result shape; it conveys the comparison dimensions but not the per-recipe fields. The unexplained `kind` parameter and the ambiguity about excluding the current recipe leave an agent with real gaps.

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 only 50%: `item` is labeled '物品 id' but `kind` (item vs fluid) has no description and is never mentioned in the description. The item/fluid distinction materially changes results, so the description should have compensated and did not.

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 description uses a specific verb+resource (找出同一物品的所有其他做法) and adds that results are compared on ingredients and time cost. It partially differentiates itself by emphasizing the alternative-finding and comparison angle, though it never names the closest sibling (get_recipes_for_output) that also returns recipes producing an item.

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 concrete trigger phrases (「还有别的做法吗」「哪条更省」) that map cleanly to when to call this tool. It does not state when NOT to use it or explicitly route to get_recipes_for_output / get_recipe_details, so exclusions are missing.

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

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

No annotations are provided, so the description must carry the behavioral burden; it does disclose the three pieces of state returned (connection, cache size, data version) and frames it as a check, implying a safe read. It does not describe the failure/return shape explicitly or any side effects, but for a zero-param status probe the disclosure is strong.

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 compact sentences: the first states what is reported, the second front-loads the diagnostic use case. No filler, and the actionable guidance follows immediately.

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 no parameters and no output schema, the description supplies enough: it enumerates the status fields and states the diagnostic role. An agent knows both what it gets and why to call it.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is empty and the description correctly does not invent parameter detail.

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 description names a specific verb and set of resources it reports on: whether CraftGraph is connected to Minecraft, how many recipes are cached, and the data version. No sibling tool does status/diagnostics, so an agent can distinguish it immediately from refresh_recipes or search_items.

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?

It gives explicit triggering conditions: call it first when any other tool reports it cannot connect to the game, and call it when the user asks why recipes cannot be found. This routes the agent to it as a diagnostic prerequisite rather than leaving usage to inference.

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

Does 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.

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses one non-obvious behavior — tag inputs like #forge:ingots/iron are matched — but says nothing about result ordering, whether the default limit of 30 silently truncates, or what the response looks like.

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, usage trigger second, behavioral caveat third. No filler; every clause adds information an agent would otherwise have to guess.

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 no annotations, no output schema, and only one of three parameters documented, the description should say more. It covers the core purpose and the tag behavior but leaves `kind` and `limit` — both of which change results materially — completely unexplained.

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 only 33%: the `item` parameter is documented in the schema, but `kind` (item/fluid enum) and `limit` (1-200, default 30) are undocumented anywhere. The description mentions only the item and never addresses fluid queries or the truncation limit, so it does not compensate for the coverage gap.

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: '查询所有把指定物品当作输入的配方'. The 'as input' framing implicitly distinguishes it from the sibling get_recipes_for_output, but the description never names that sibling to make the routing explicit.

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 concrete user-phrasing trigger ('X 有什么用' / 'X 能做什么'), which is directly actionable. It offers no exclusion or alternative, so an agent facing the reverse question ('how do I make X') gets no pointer to get_recipes_for_output.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely non-obvious behavior: unreadable recipes are still returned and flagged opaque, because 'has a recipe but can't parse it' differs from 'no recipe'. It says nothing about result ordering, the default 30/200 cap, or what an empty result means.

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, zero waste: what it does, when to call it, then the opaque caveat. The most decision-relevant information is front-loaded.

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?

No output schema exists, so the description should explain the return shape; it only hints at an 'opaque' marker. It also leaves 'kind' and 'limit' unaddressed, which is a real gap for a 3-parameter tool, though the core intent is clear.

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 only 33%: only 'item' is documented in the schema, while 'kind' (item vs fluid enum) and 'limit' (1-200, default 30) are undocumented in both places. The description says nothing about these two parameters, so it fails to compensate for the coverage gap.

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 description states a specific verb+resource: return all recipes that produce a given item. The direction (output-side lookup) implicitly distinguishes it from the sibling get_recipes_for_input, but no sibling is named explicitly.

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?

It gives concrete user-question triggers ('X 怎么做', 'X 怎么来的') that select this tool, which is stronger than implied usage. It stops short of naming the reverse-lookup sibling as the alternative or stating when not to use it.

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

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

With no annotations, the description carries the behavioral burden, and it discloses the key operational trait: this call requires a live game session, unlike the offline cached search_items. It does not state what happens when the game is not running (error vs. empty result) or that results may be truncated by the limit, which keeps it below a 5.

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 sentences: the first states what it lists, the second front-loads the runtime precondition and then the routing advice. There is no filler, and the most important constraint is not buried.

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?

There is no output schema, so the description should say what 'registry contents' actually returns (ids only, or full entries with namespaces/tags), and it doesn't. Combined with the unexplained `limit` truncation behavior, an agent knows when to call it but not what to expect back.

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 only 33%; `query` is described but `kind` and `limit` are not. The description restates the `kind` enum values in prose, which is redundant with the self-documenting enum, and it says nothing about `limit` (default 100, cap 1000), so an agent gets no signal that results may be silently cut off.

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 description names a specific verb (列出) and resource (注册表), and enumerates the five registry kinds that the `kind` enum accepts, so the scope is unambiguous. It also distinguishes itself from search_items, making it identifiable among its siblings without opening the 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?

It explicitly states the precondition (game must be running) and names the preferred alternative with the condition that selects it: if you only need an item id, use search_items because it reads a local cache and works offline. That is a complete when-to-use / when-not-to-use / alternative triple.

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

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

With no annotations the description carries the full burden; it does disclose the return content (types + counts) and a diagnostic use, but says nothing about side effects, cost, or whether refresh_recipes must be run first for results to be meaningful. Read-only behavior is implied by 'list' but never asserted.

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 sentences, output content front-loaded, then the usage triggers. No filler or restatement of the title.

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 no-param listing tool with no output schema, describing both the returned fields and the diagnostic use is close to sufficient. The one missing piece is its relationship to refresh_recipes and get_registry in the recipe-loading workflow.

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?

Zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies a whole-pack scope with no filtering knobs.

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 (list all recipe types in this pack) plus the extra payload (per-type recipe counts), which distinguishes it from search_items and get_recipe_details. It never names a sibling outright, so differentiation is inferred from scope rather than stated.

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 two concrete triggers: when the user asks what machines/recipe types exist, and when checking whether a mod's recipes were actually loaded. No when-not guidance or named alternative (e.g. get_registry) is given, so it stops short of full routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a forced external pull plus cache rebuild, and that it is redundant in the normal flow. It does not say what happens if the game or bridge is unreachable (a likely precondition given the get_bridge_status sibling), or whether it returns a count or status.

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?

It has two sentences: the action is front-loaded, then the cost/precondition and the trigger condition. Every clause earns its place, and there is no filler.

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 zero-parameter cache-invalidation tool with no output schema, the description covers purpose, cost, and trigger well. A small gap remains around failure modes (no game bridge or unreachable game client) and what a successful call returns, but nothing critical is missing for correct invocation.

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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies no scoping arguments are needed, since the refresh is global, but there is nothing more to document.

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: force re-fetch recipes from the game and rebuild the cache. It is clearly distinguished from the read-only siblings (get_recipes_for_output, get_recipe_details, etc.), since this operation performs cache invalidation rather than retrieval.

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?

It gives explicit when-not guidance: it is normally unnecessary because recipe reloads are auto-detected via dataVersion. It also gives explicit when guidance: use it only when the user says they just changed a recipe, or when data looks wrong. Nothing is left to inference.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It usefully discloses that the tool returns a list of matching ids and does not require the game to be running, but it omits limits, result ordering, empty-result behavior, and any safety or permission context.

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 sentences, front-loaded with the core purpose, followed by the usage workflow and an operational fact. Every sentence adds useful information without padding.

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 simple read-only lookup with no output schema, the description is nearly complete: it explains purpose, workflow, return shape, and that the game need not be running. The missing detail about the limit parameter and result-size behavior keeps it from a 5.

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 only 50%: the query parameter is documented in the schema, while limit is undocumented. The description repeats the schema's query semantics (name or id) but says nothing about the limit parameter or result-size behavior, leaving a real gap.

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 description states a specific verb and resource: search items by name or id and return matching id list. It clearly distinguishes this lookup tool from the recipe-query siblings by explaining it is used first to resolve fuzzy names into exact ids.

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?

It gives a concrete when-to-use scenario: when the user says something vague like 「铁锭」 or 「iron」, use this tool to resolve the exact item id before calling recipe tools. It does not explicitly name which alternative sibling to avoid or cover when-not-to-use cases, so it falls short of a full 5.

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