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

There are no annotations, so the description must carry the behavioral burden. It discloses the high-level behavior ('Build one visual board... reject candidates') and some evaluation criteria, but it does not explain whether the board is persisted, what output is returned, whether it modifies any inputs, or what happens when output_path is omitted. This leaves key behavioral aspects under-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?

Two sentences, front-loaded with the main action and followed by a concise workflow note. Every phrase contributes to understanding when and why the tool should be used, with no filler or repetition of schema details.

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 nested schema, four parameters, no parameter descriptions, and no output schema, this description is too sparse for a fully informed invocation. It gives a useful workflow position but omits important context about the rejected baseline, output_path behavior, and return value, leaving an agent to guess at semantics not recoverable from 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 0%, so the description must compensate. It adds meaning by mapping 'two to four' to the candidates array, and 'image-making method, composition, and enough core visual axes' to the axis fields and minimum_changed_axes concept. However, it does not explain the required 'rejected' object or the optional 'output_path' parameter, so compensation is partial.

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 a specific action: build a visual board for two to four opening-frame previews and reject candidates that fail material-change criteria. It is not a tautology and identifies the resource ('replacement direction previews') and the workflow position, though it does not explicitly name sibling tools to distinguish itself.

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 provides clear usage context with 'Use before expanding any replacement into a full set,' which tells an agent when in the workflow to invoke this tool. It does not, however, state when not to use it or mention alternative sibling tools explicitly.

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 of behavioral disclosure. It states the action and result but does not mention side effects, error handling, rate limits, or that it is a read-only operation. For a getter, this is minimal 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 a single, efficient sentence with no filler. The action and key input are front-loaded, making it easy to parse quickly. It is appropriately concise for a tool with one parameter.

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 fetch-by-slug tool with one parameter and no output schema, the description explains what is returned ('one catalog app and its screenshot URLs') which is the essential context. It lacks details on error conditions or return structure, but these are minor for this straightforward use case.

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 0%, so the description must compensate. It does add the crucial meaning that 'slug' is the identifier used to fetch the app, which goes beyond the schema's generic string type. However, it does not elaborate on slug format or additional constraints beyond what the schema already provides.

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 ('Get'), a clear resource ('one catalog app and its screenshot URLs'), and the key method ('by slug'). It distinguishes from siblings like search_apps (search) and get_screenshot_set (screenshots only) by stating exactly what it returns.

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 the tool is used when you have a specific slug to fetch a single app, but it does not explicitly contrast with alternatives or state when not to use it. No direct comparison to sibling tools is provided, so usage is only implied.

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 of behavioral disclosure. 'Fetch... and return' implies a read-only operation, and the 'approved' qualifier plus 'one visual comparison board' constrains what the tool accepts and produces. However, it never explicitly confirms the absence of side effects, states what happens with invalid IDs, or describes permission/authorization requirements, leaving part of the disclosure burden unmet.

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 with zero filler: the first delivers the core fetch-and-return behavior, and the second delivers the when-and-why usage guidance. The most decision-relevant information is front-loaded in the opening clause. Every sentence 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?

For a one-parameter tool whose schema fully documents the input, the description covers the essentials: what it does, when in the workflow to call it, and that it produces a single visual comparison board. With no output schema, 'return one visual comparison board' is the only return-format information, and it does not specify whether the board is an image URL, rendered HTML, or file path. Error/failure behavior is also unstated, so a 4 rather than a 5 is appropriate.

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%; the schema already documents that screenshot_ids are 'Approved screenshot IDs returned by search_screenshots or get_screenshot_set,' including provenance and constraints (min 1, max 6, minLength 3). The description's 'approved niceapps.club screenshots' reinforces the schema's qualifier and adds the domain context, but adds little beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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 precise action and outcome: 'Fetch selected approved niceapps.club screenshots and return one visual comparison board,' naming the verb, resource, and output format in a single clause. The phrase 'one visual comparison board' hints at differentiation from siblings like get_screenshot_set, which presumably returns raw screenshot data. It does not explicitly name the sibling it is not, so it falls one step short of the strongest definitions.

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?

'Use after retrieval and visually inspect the actual compositions before proposing art direction' places the tool explicitly in the workflow, telling the agent exactly when in the pipeline it belongs. 'Annotations alone are insufficient' supplies the selection rationale, explaining why this tool is necessary rather than skipping it. It provides clear context but does not name excluded alternatives or say when NOT to use it, so it earns a 4 rather than 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 present, the description carries the full behavioral disclosure burden. It usefully discloses that results are ordered and human-reviewed, which adds context beyond 'get screenshot set'. However, it does not mention output format, error behavior for unknown slugs, or any access considerations.

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 a single, front-loaded sentence with no filler. It puts the verb and object first, then the scoping detail, and every word contributes useful information.

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, the description covers the essential context: what is returned (annotations), their nature (ordered, human-reviewed), and scope (one app slug). Lacking only detailed return-value structure and edge-case behavior, which are minor for this simple operation.

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 provides only a bare 'slug' string with no description, so schema coverage is 0%. The description adds minimal meaning by identifying the slug as a 'niceapps.club app slug', but it does not explain slug format, valid values, or how to obtain one; the single parameter is simple enough that this is adequate but not strong.

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 a specific verb ('Return') and resource ('ordered, human-reviewed screenshot annotations') scoped to one app slug. It does not explicitly contrast with sibling tools like search_screenshots, but the noun phrase 'screenshot annotations' distinguishes this from raw screenshot 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?

Usage is implied rather than explicit: the description tells the agent this tool returns annotations for one specific niceapps.club app slug, suggesting it is appropriate when a slug is already known. It does not provide any when-to-use vs. when-not-to-use guidance or mention sibling alternatives.

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 disclosure burden. It does disclose that the data is 'public' and 'current', which suggests no authentication and a fresh read. However, it does not explicitly state whether the operation is read-only, whether it mutates any local/context state, or what happens on an invalid URL or ID.

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 a single sentence with no filler. It front-loads the resource and result ('public App Store metadata and current screenshots') before stating the input ('from an App Store URL or Apple ID'), making it easy for an agent to parse quickly.

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 one-parameter tool with no output schema, the description identifies the input and the expected result (metadata and screenshots). It is mostly complete, though it does not explain what 'context' means operationally or how the loaded data is returned or stored, which would be helpful.

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 fully describes the single parameter as 'App Store URL or numeric Apple ID' with 100% coverage. The description only restates this same source condition and does not add examples, format details, or constraints beyond what the schema provides.

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 ('Load') with a specific resource ('public App Store metadata and current screenshots') and an explicit source ('an App Store URL or Apple ID'). It clearly states the tool's function and distinguishes it from search/screenshot-only siblings by covering both metadata and screenshots from a direct identifier.

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 the tool should be used when the agent has an App Store URL or Apple ID, but it gives no guidance on when to choose this over alternatives such as get_app or search_screenshots. It provides no exclusions, prerequisites, or context for selecting the right sibling.

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 of behavioral disclosure. It only states 'Persist', indicating a write operation, but does not disclose whether it creates or updates records, what happens on repeated calls, whether it overwrites existing feedback, if authorization is required, or what the return value is. This is a significant gap for a state-changing 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 a single sentence with no filler or repetition. It front-loads the core action ('Persist a rejected direction and the user's reason') and then states the purpose, making it concise and well-structured.

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 output schema, no annotations, a nested fingerprint object, and 7 parameters, the description is too sparse to fully guide an agent. It does not explain how to construct feedback_file, what avoid/preserve mean in practice, or how direction_id relates to fingerprint. An agent would need to infer significant details to invoke the tool correctly.

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 14%, so most parameters lack descriptions. The description adds meaning to 'reason' as the user's reason and to 'fingerprint' as the fields for image-making method, composition, palette, and device treatment. However, it does not explain required fields like project_id, direction_id, feedback_file, or the optional avoid/preserve arrays, leaving major gaps in understanding.

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: 'Persist a rejected direction and the user's reason', and explains the purpose of preventing later iterations from repeating the same method, composition, palette, or device treatment. None of the sibling tools (search_apps, get_app, screenshot tools) overlap with this feedback-recording function, so it is clearly distinguishable.

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 clearly implies when to use the tool: when a direction is rejected and the user's reason must be recorded to avoid silent repetition in later iterations. It does not explicitly name alternatives or exclusions, but the sibling tools are unrelated, so this contextual guidance is sufficient.

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 behavioral disclosure burden. The 'candidates, not conversion evidence' caveat is a genuinely useful behavioral trait, but the description lacks other context such as result limits, matching behavior, or output shape.

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 extremely concise, with the core purpose front-loaded and the key caveat in the second sentence. Every word earns its place, and there is no redundant 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 three-parameter search tool, the description provides purpose and a crucial result interpretation, while the schema covers parameters. However, with no output schema and no sibling differentiation, an agent is left without explicit return structure or guidance on choosing between related search tools.

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 67%, with query and category already described in the schema. The description itself does not add parameter-level detail, but it does reinforce the overall intent behind the query terms. The 'limit' parameter remains generic, though its schema constraints are sufficient.

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 action ('Find') and resource ('screenshot references in the niceapps.club catalog'), so an agent understands the tool's basic purpose. However, it does not explicitly contrast itself with sibling tools like search_screenshots, leaving some differentiation to the tool name and context.

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 phrase 'Results are candidates, not conversion evidence' implies this tool is for discovery/reference gathering rather than validation, which is useful usage context. It does not explicitly say when to use this tool instead of search_screenshots or get_app, so the guidance remains somewhat implicit.

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 explicitly discloses that results are human-reviewed, include text-match reasons, and are references rather than conversion evidence. These are meaningful behavioral traits beyond what the schema shows. It does not cover ordering, pagination, or filter semantics, but the core behavior is transparent.

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 front-loads the purpose and facets, the second frames result interpretation. Every clause earns its place, with 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?

For a 9-parameter tool with no output schema and no annotations, the description covers the high-level purpose but leaves gaps: it does not explain multi-filter logic, what constitutes a valid query or array value, defaults (e.g., limit=8, per_app_limit=2), or the meaning of exclude_slugs. An agent could still invoke it correctly with a simple query, but the description is not fully complete for effective use of all parameters.

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 44%, so the description must compensate. It merely re-lists the same facet names as parameters (communication job, visual style, composition, device treatment, category) without adding value. It does not explain what values are valid, whether filters combine as AND/OR, or what 'human-reviewed' means for query behavior. The small benefit of indicating curated data does not offset the missing guidance.

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 human-reviewed screenshot-level annotations' and lists six distinct facets. It clearly differentiates from sibling tools like search_apps by scoping to screenshot-level annotations, and the second sentence clarifies the intended use case (references, not conversion evidence).

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?

Usage is implied by the purpose: an agent can infer this tool is for finding curated screenshot patterns by various facets. However, there is no explicit when-to-use versus alternatives, no mention of when not to use it (e.g., when needing app metadata), and no comparison to search_apps or get_reference_board. The guidance is present but not stated.

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 that the tool rasterizes using the same typography and dimensions as the renderer (simulation), reports measurements, and is non-destructive (before writing). It does not mention failure modes or output format, but the key behavioral traits are covered.

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 a single, dense sentence that front-loads the primary action and key outputs. It is concise and avoids redundancy, though the long sentence could be split for readability.

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 tool with 5 parameters, a complex nested schema, no output schema, and no annotations, the description is insufficient. It does not describe the report structure, collision criteria, or parameter semantics, leaving significant gaps for an agent to call it correctly.

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 0%, and the description provides no explanation of parameters like frames, slot, width, height, or locale. The complex nested schema remains entirely undocumented, leaving the agent without guidance on how to construct valid inputs.

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 action ('Rasterize localized screenshot copy'), the specific outputs ('report exact pixel widths and copy-to-source collisions'), and the timing ('before any files are written'). It distinguishes itself from sibling validate_screenshot_set by focusing on copy and collisions, making its purpose unambiguous.

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 as a preflight check ('before any files are written') but does not explicitly contrast it with validate_screenshot_set or other siblings. There is no when-to-use vs when-not-to-use guidance, leaving the agent to infer the appropriate context.

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 mentions the validation aspects and that it reports gates separately, but does not disclose whether the tool is read-only, what happens on validation failure, if it writes any state, or what the output format is. For a validation tool, it should explicitly state that it does not modify files or require special permissions. This is a significant gap.

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, consisting of two sentences with no wasted words. It front-loads the action ('Validate local screenshot files') and then lists the validation dimensions and the gate reporting. It is easy to parse and not verbose, though it could be slightly better structured with parameter hints, but it meets the conciseness bar.

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 tool has 8 parameters, a nested 'expected' object, no output schema, and no annotations. The description is far from complete: it does not explain what the gates are, how the booleans affect behavior, what the return value looks like, or how to handle multiple files. An agent cannot correctly call this tool based on the description alone; it would need to infer from parameter names, which is risky given the lack of documentation. This is severely incomplete.

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 13%, meaning most parameters are undocumented in the schema, and the description does not compensate. The description mentions validation aspects but does not map them to specific parameters like 'files', 'slot', 'expected', 'render_manifest', or the three boolean flags. There is no explanation of what 'full_resolution_reviewed' or 'source_fidelity_verified' mean. With such low coverage, the description must clarify parameter semantics, but it offers none.

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: validating local screenshot files for specific attributes (dimensions, format, opacity, readable image data, and deterministic sequence naming) and reporting two gates separately. It names the resource (screenshot files) and the verb (validate), making the core purpose evident. However, it does not explicitly differentiate from the sibling tool 'validate_screenshot_copy', which could be confused for a similar validation task, so it lacks sibling distinction.

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?

No guidance is provided on when to use this tool versus alternatives like validate_screenshot_copy. There is no mention of prerequisites, scenarios where this validation is appropriate, or exclusions. The description only states what it does, not when to invoke it, leaving the agent to infer usage context.

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