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

With no annotations, the description carries the burden. It discloses key behaviors: zero network calls, pure local query using filter.json and dead-image cache, implying a read-only, offline operation. This gives a strong sense of side effects, though edge-case behavior like cache updates isn't specified.

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 description is two succinct phrases, front-loading the core purpose and then adding a one-line scenario note. Every sentence earns its place with no redundancy.

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 two-parameter tool with 100% schema coverage and an output schema, the description adequately covers purpose, behavior, and usage context. It doesn't detail return format, but that is likely handled by the output schema. It omits failure modes, but overall the tool is simple enough.

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%, with both title and workshop_id already documented, including precedence and the requirement for at least one. The description adds no additional parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate.

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 clearly states the tool checks whether an image can be downloaded, with a specific verb ('检查') and resource ('一张图'). It also mentions the underlying mechanism (local query), which distinguishes it from sibling tools like get_download_job that handle actual download jobs.

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?

The description provides explicit use cases: pre-download checks and batch filtering. It also highlights zero network calls, which informs when it's appropriate (e.g., for lightweight filtering). It doesn't mention exclusions or alternatives, but the context is strong enough for selection.

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 of behavioral disclosure. It does reveal that the tool fuses three signals including forward dependencies, reverse author queries, and naming pattern recognition, which gives some insight into its operation. However, it does not explicitly state whether the tool is read-only, what side effects it may have (e.g., API calls), or error behavior. This is moderate transparency.

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 description is exceptionally concise, with a clear main purpose followed by a bulleted list of three signal paths. Every sentence earns its place, and the structure makes the method easy to scan. No wasted words.

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?

The description outlines the core function and the three signals used, but lacks details on how these signals are combined, edge cases, or interpretation of results. While an output schema exists and can clarify return values, the description alone leaves some gaps for a tool with this complexity.

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 schema descriptions cover 100% of parameters, each with clear explanations. The tool description's mention of '命名模式识别' aligns with the aggressive parameter's schema description but adds no new information beyond what the schema already provides. Baseline of 3 is appropriate.

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 clearly states the tool's purpose: identifying the complete series (all Parts) that a given image belongs to. The verb '识别' (identify) and the resource '一张图' (an image/workshop item) are specific, and the description differentiates this tool from the campaign-related siblings by focusing on series parts discovery.

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?

The description implies usage: to find all parts of a series for a workshop item. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. The three fusion signals hint at the approach but not the decision criteria for when this tool is appropriate.

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 discloses the polling nature of the tool and provides the full return shape including statuses (queued/running/done/error), elapsed time, and result/error fields. While it does not explicitly state it is read-only or discuss rate limits, the query semantics and return contract are transparent enough for a simple async job monitoring 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?

The description is concise and front-loaded with the purpose, followed by a clearly formatted Returns section. Every sentence earns its place, and the structured return format is easy to parse. No wasted words.

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?

Given the tool's simplicity (one parameter, async job polling) and the presence of an output schema, the description is sufficiently complete. It explains the job_id source, the progress statuses, and the return structure. It could mention error scenarios or repeated polling behavior, but these are minor gaps for a minimal tool.

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 schema only defines job_id as a string with no description (coverage 0%). The description compensates by explaining that job_id comes from install_campaign's async_mode=True response, which adds essential meaning. It does not specify format or validation rules, but the provenance detail is valuable.

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 clearly states the tool queries the progress of an asynchronous download task, specifically the job_id returned by install_campaign when async_mode=True. This is a specific verb (query) and resource (download job progress), and it distinguishes itself from siblings like install_campaign by being the status-check counterpart.

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?

The description explicitly indicates when to use this tool: after calling install_campaign with async_mode=True and receiving a job_id. It does not explicitly state when not to use it or mention alternatives, but the usage context is clear and likely sufficient for an agent to select it correctly.

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 provided, the description carries the full burden of behavioral disclosure. It transparently states the default behavior (description not returned to save tokens) and the truncation limit (500 characters), plus the inclusion of phase2 results. It does not mention permissions or error handling, but the 'query' verb implies a read-only operation.

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 description is concise and well-structured: two short sentences that front-load the primary purpose and then clarify the key parameter behavior. There is no redundant information or unnecessary elaboration.

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 two-parameter tool with an output schema, the description adequately covers the essential context: what the tool does, the specific phase2 result it includes, and the critical default/optional behavior. It lacks edge-case context like not-found behavior or prerequisites, but the overall completeness is sufficient for this query tool.

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 input schema already provides complete descriptions for both parameters (workshop_id and include_description) with 100% coverage. The description adds the rationale for the default ('省 token' - save tokens) and reiterates the truncation behavior, but this is largely redundant with the schema. No significant additional parameter semantics are provided.

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 clearly states the tool's purpose: '查询单张地图的完整详情' (query complete details of a single map), and adds a specific distinguishing feature: '包含 phase2 战役判定结果' (including phase2 campaign determination result). This differentiates it from sibling list/search tools by focusing on singular detail retrieval with a unique data point.

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?

The description does not explicitly state when to use this tool versus alternatives. It implies usage by describing a single-map detail query, but there is no mention of when not to use it or alternative tools. The only usage-related guidance is about the include_description parameter, which is more about parameter semantics than tool selection.

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. It discloses the full pipeline side effects (dependency parsing, disk write, dedup list update) and the matching behavior (unique high-confidence match auto-downloads, multiple candidates returned for confirmation). It does not discuss all edge behaviors like force/blacklist or async handling, but those are covered in schema parameter descriptions.

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 description is compact and well-structured, with a pipeline summary followed by bullet-point clarifications for the two key parameters. Every sentence adds value, and the formatting makes the workflow and input rules easy to scan.

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?

Given the tool's complexity (6 parameters, output schema present), the description provides a strong high-level overview of the workflow and input requirements. It does not explain the return structure, but the output schema covers that. It also relies on schema parameter descriptions for strict/async/force behavior, which is acceptable given full schema coverage.

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 baseline is 3. The description adds meaningful semantics beyond the schema: workshop_id may be a numeric ID or a Steamcommunity link (auto-extracted), and title triggers a multi-stage internal resolution chain with candidate confirmation. This goes beyond the raw schema fields.

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 clearly states the tool performs a one-stop download pipeline: identify, resolve dependencies, download, save, and update the dedup list. It explicitly names the supported input forms (workshop_id, Steam link, map title) and distinguishes it from sibling tools like get_download_job and resolve_map by focusing on the full download workflow.

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 when to use the tool: when the user provides a workshop_id, Steam link, or map name for download. It also gives the key prerequisite that at least one of workshop_id or title must be provided, and explains the resolution behavior for titles. It does not mention alternatives or exclusions, but the context is clear and actionable.

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 provided, the description carries the full burden of behavioral disclosure. It explicitly mentions that blacklists are skipped, active maps are deduplicated, and the results incorporate the echocn curated list. This adds useful behavioral context beyond the schema, though it does not discuss side effects or error handling, which are less relevant for a read-only list operation.

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 description is two concise sentences. The first sentence front-loads the primary purpose, and the second adds key filtering behavior. Every word earns its place without redundancy.

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?

This is a simple list tool with only two optional parameters and an existing output schema. The description, combined with the schema, fully covers what the tool does, how results are filtered, and what parameters are available. There are no critical gaps given the tool's low complexity.

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 input schema already provides full documentation for both parameters ('days' and 'limit') with defaults, achieving 100% schema coverage. The description adds no additional parameter semantics beyond reinforcing that 'days' corresponds to the 'N' in the description. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.

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 clearly specifies the action ('列出' / list), the resource ('最近 N 天新增的战役地图' / campaign maps newly added in the last N days), and the scope ('增量发现' / incremental discovery). It distinguishes itself from siblings like search_campaigns by highlighting its incremental, blacklist-skipping, and deduplicating behavior.

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?

The description provides clear context for when to use the tool: to discover campaign maps added within a recent time window. It implies this is for incremental discovery rather than general search, but it does not explicitly name alternatives or state when not to use the tool, so it stops short of a 5.

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 provided, the description carries the transparency burden. It conveys that this is a read-only query over a fixed curated list of 461 entries and lists content dimensions, but it does not mention data freshness, pagination behavior, or whether refresh_curated_list should be called first. The query verb implies no side effects, making it adequate but not rich.

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 description is three short sentences, front-loaded with the core query target. Each sentence adds distinct information: what is queried, what it contains, and when to prefer it. There is no redundancy or 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?

An output schema is present, so return value details are already covered. The description sufficiently explains scope (461 curated maps), content (tags, chapters, annotations), and usage priority (highest quality for judging/recommending). It omits minor operational details such as ordering or refresh behavior, but the definition is still well-rounded.

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. The description adds meaningful context by revealing that the `tag` parameter operates over 16 possible Chinese labels and that results include chapter info and human annotations, which clarifies what the keyword and tag filters act upon. This lifts it above baseline.

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 opens with a specific verb ('查询') and a concrete resource ('echocn 人工策展的 461 条高质量战役地图名单'), clearly distinguishing it from generic search/list tools. It further specifies content ('16 种中文标签、章节信息、人工标注') and adds a prioritization signal ('质量最高的数据源，应优先用于判定和推荐'), which reinforces its distinct role among siblings.

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?

The description explicitly states when to use this tool: '应优先用于判定和推荐' (should be prioritized for judging and recommending), and labels it as the highest-quality data source. However, it does not explicitly name alternative tools or provide when-not-to-use criteria, so it misses the full 5.

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 full burden. It discloses the return format ({success, total, sha256, cached_at, error?}) and that it's a manual override of automatic processes. However, it does not mention potential side effects like overwriting existing cache, whether the operation is idempotent, or blocking behavior—gaps given the absence of annotations.

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 description is concise, well-structured with numbered use cases and a clear return format section. Every sentence contributes: purpose, automatic behavior context, use cases, and return shape. No redundancy or fluff.

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-parameter tool with an output schema (indicated by the Returns section), the description adequately covers purpose, usage scenarios, and return structure. It does not address relationship to sibling tools like query_curated_list beyond the refresh/query distinction, but the tool is simple and self-contained.

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 has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed. The return format description partially helps understand what the tool produces, which is useful context beyond the empty schema.

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 opens with '手动刷新 echocn 缓存' (manually refresh echocn cache), providing a specific verb and resource. It clearly distinguishes itself from the sibling tool 'query_curated_list' by focusing on refresh operation rather than query/read.

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?

The description explicitly states automatic refresh on MCP startup and daily background refresh, then lists three concrete use cases (initial deployment verification, suspected stale cache, troubleshooting). This provides clear when-to-use guidance and implicitly when not to use, as manual refresh is reserved for exceptional cases.

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 well: it discloses the tool does not download, fuses echocn curated list with mirror search, and sorts by phase2 criteria. This gives a solid safety and behavior profile, though 'phase2' is left undefined and empty-result handling isn't mentioned.

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 description is two sentences: the first states the purpose, the second packs usage scenarios and behavioral specifics. Every phrase earns its place with no redundancy or fluff.

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?

The description covers purpose, usage context, and behavioral constraints (no download, source fusion, sorting) well. With an output schema present, it doesn't need to detail return values. Minor gaps are the unexplained 'phase2' term and no mention of zero-result behavior, but overall it is sufficiently complete.

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% and both parameters are documented with descriptions. The tool description only restates that query is a map title and limit is candidate count, adding no meaningful semantic beyond the schema.

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 explicitly states the tool resolves map titles into workshop candidates and notes it does not download. This clearly distinguishes it from installation and search tools in the sibling set.

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?

The '适用' section provides concrete scenarios: when users ask about map existence/ID or before installing via install_campaign. This gives clear context for usage, though it doesn't explicitly enumerate alternatives or when-not-to-use.

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 provided, the description carries the full burden of disclosure. It reveals the internal scoring system (score≥3 threshold), the blacklist and active deduplication filtering, and the behavior of the include_ambiguous flag (adding likely_mod hints). This goes well beyond a simple 'search' and gives the agent confidence about what to expect.

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 description is two concise sentences with no redundant words. It front-loads the core purpose ('search campaign maps'), then explains the filtering behavior and the key parameter option, all in a compact, well-structured manner.

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?

An output schema is present, so return value details are not required in the description. The description covers the primary purpose, the default filtering behavior, and the include_ambiguous flag, which is enough context for a search tool. It does not mention the generic parameters (keyword, sort, limit, days) but those are self-explanatory from the schema, leaving the description complete for the unique behavior.

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 schema already provides descriptions for all 5 parameters, so the baseline is 3. The description text adds context about the scoring threshold and the include_ambiguous behavior, but it does not introduce new per-parameter semantics beyond what the schema already captures. Each parameter's meaning is fully documented in the schema.

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 clearly states the tool searches for campaign maps in the workshop, with a specific verb ('search') and resource ('campaign maps'). It also introduces unique filtering behavior (phase2 multi-factor rules, blacklist, active dedup) that distinguishes it from sibling list tools like list_new_campaigns.

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?

The description explains the default behavior (only returns high-confidence score≥3 results) and explicitly tells the user when to set include_ambiguous=True to see ambiguous, mod-like results. However, it does not explicitly compare with alternative tools or state when not to use this tool, leaving some room for interpretation.

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 behavioral disclosure burden. It explains the scanning, filtering, adding, and return summary, but lacks details on error handling, side effects beyond the list addition, or prerequisites such as directory existence.

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 description is compact and well-structured, with the core action first, followed by usage scenarios and duplicate handling, and a clear return format. Every sentence adds value without redundancy.

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 tool with a described output schema, the description covers the essential behavior, usage contexts, and return values. It could mention edge cases like missing directories or failure states, but overall it is sufficiently complete.

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?

With zero parameters, the schema needs no elaboration. The description adds meaningful context about the dedup logic and the output fields, which aligns with the baseline for parameterless tools.

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 clearly states the tool's function: scanning an idle map directory and adding .vpk files not in a dedup list to that list. It uses specific verbs (scan, add) and identifies the resource (.vpk files, dedup list), making it distinct from siblings like install_campaign.

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?

The description gives explicit usage contexts: manual cleanup of the idle directory and automatic invocation after install_campaign. It also clarifies that duplicates are skipped, providing clear when-to-use guidance, though it does not explicitly name alternative tools.

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