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

With no annotations, the description carries the full burden. It discloses a non-obvious external behavior (version-dependent names and fatal consequences of guessing), which is valuable. However, it does not describe the tool's own return format, whether it reads from the installed build dynamically, or any other side effects; the description focuses more on domain risk than tool behavior.

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 tightly packed: a one-line purpose, a single-sentence warning, and a compact parameter reference. Every sentence earns its place, the most important information is front-loaded, and there is no filler or repetition.

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 listing tool with no output schema, the description covers the core callable surface and rationale. However, it does not specify the exact return values (e.g., whether it returns an array of plain names or a structured object), nor does it clarify 'contains' matching behavior. This is adequate but leaves moderate gaps for an agent.

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 for the bare input schema. It does so meaningfully by enumerating allowed values for 'kind' ('export-tabs' or 'save-report') and giving a concrete search example for 'contains' ('Title' or 'Accessibility'). This adds practical guidance beyond the schema, though exact matching semantics are not specified.

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 leads with a specific verb and resource: 'List the export names the INSTALLED Screaming Frog build accepts.' This clearly distinguishes it from siblings like list_exports or get_issues, and the version-aware phrasing prevents confusion with generic filter lists.

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 strong context: filter names vary by Screaming Frog version and an unknown name aborts an entire crawl. 'Never guess them' is an explicit directive that implies this tool should be used before any crawl/filter operation. It does not name alternative tools or when-not-to-use, 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?

The description discloses side effects (writing three files into the crawl folder), the HTML styling and print behavior, and explicitly explains that there is no bundled PDF step. With no annotations provided, this is substantial unassisted disclosure, though overwrite behavior and permissions are not addressed.

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 front-loaded: it states the purpose, lists outputs, explains a notable design decision (no PDF step), and documents the label parameter. Every sentence 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 write tool with no output schema and no annotations, the description provides the essential outputs, the HTML printing behavior, and the label default. It lacks explicit overwrite semantics and a fuller definition of the crawl input, but an agent can still act on it confidently.

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 description adds useful meaning for the label parameter, including its role as a display name and its default of the crawled site. However, with schema description coverage at 0%, the crawl parameter is left only as its name with no format, source, or example, so the description only partially compensates.

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 action ('Write') and resource ('a finished crawl... into its folder'), and names the concrete artifacts produced: report.md, a printable report.html, and analysis.json. This makes it clearly distinct from sibling read/export/crawl-management tools.

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 'finished crawl' gives a clear precondition: this tool is for generating a report from a completed crawl, not for monitoring, listing, or exporting raw data. It does not explicitly name when-not-to-use or alternative tools, but the context is clear 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal a key behavioral trait: exports already written are kept, which reassures that cancellation is non-destructive to completed outputs. However, it does not mention irreversibility, error handling for invalid job IDs, or what happens to partially written exports. Some useful context is present, but significant gaps remain.

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 short sentences with no filler. The primary action is front-loaded, and the additional side-effect note is concise and relevant. Every word 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 simple one-parameter tool, the description is minimally viable: it states the action and a key consequence. However, it lacks parameter guidance and does not describe what response the agent should expect (success or error), especially since there is no output schema. The gaps prevent it from being fully self-contained but it is not completely inadequate.

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 has one required parameter, job_id, with 0% schema description coverage. The description does not mention job_id at all, does not explain how to identify the crawl, and provides no guidance on formats or sources for the value. With low schema coverage, the description must compensate, and it fails to do so entirely.

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 and resource ('Stop a running crawl') and adds a meaningful nuance ('Exports already written are kept') that distinguishes it from sibling tools like start_crawl or crawl_status. An agent can immediately tell what operation this tool performs.

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 phrasing 'Stop a running crawl' implies the use case: when a crawl is in progress and must be halted. However, there is no explicit guidance about when NOT to use it (e.g., completed or failed crawls) and no comparison with alternatives such as crawl_status or list_crawls. The usage context is clear but fully 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 behavioral burden. It clearly states that the tool only reports status, and the word 'Report' implies a non-mutating diagnostic operation. The 'call this first' guidance adds useful operational context, though it does not explicitly state there are no side effects.

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: the first states what the tool reports and the second gives the usage rule. Every sentence earns its place and the key 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 zero-parameter diagnostic tool with no output schema, the description tells the agent exactly what it will learn and when to call it. Nothing essential 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 has zero parameters, so the schema already covers everything and a baseline of 4 applies. The description correctly adds no redundant 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 uses a specific verb, 'Report', and specifies the exact resource state: installation status, license status, and current limits. This clearly differentiates check_install from the crawl, export, and report sibling tools.

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 instructs the agent when to use the tool: 'Call this first if anything else fails.' This is direct sequencing guidance for a diagnostic tool and clearly positions it relative to the sibling tools.

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 behavioral burden. It discloses state-dependent behavior: while running it shows elapsed time and runner lines; once finished it shows headline counts. This goes beyond the schema and helps set expectations, though it doesn't cover error or authorization scenarios.

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, scannable, and front-loaded with the core purpose before detailing the two output states. Every sentence earns its place, and the follow-up instruction is clearly separated.

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 covers what the tool returns in both relevant states and directs the agent to the appropriate next tool. This is sufficient for correct selection and 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 input schema only provides the job_id property with a default of '', so the description's statement 'Omit job_id for the most recent' adds meaningful semantics. It clarifies that the parameter is optional and controls which crawl is inspected, compensating for the lack of schema description coverage.

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 identifies a specific verb ('Check') and resource ('a crawl started by start_crawl'), and distinguishes this from the sibling start_crawl, cancel_crawl, and list_crawls tools. It also states the omission behavior for job_id, making the tool's scope 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?

It explicitly tells the agent to use this after starting a crawl, explains how to target the most recent crawl by omitting job_id, and routes the agent to get_issues once finished. This provides clear when-to-use and follow-up 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 of behavioral disclosure. It does convey the main behavioral traits: this is an aggregated analysis, each section has interpretation guidance, and requesting all sections is large. It does not explicitly state read-only behavior, error conditions, or whether analysis is computed on demand, but for a named get operation the core behavior is reasonably 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 compact and front-loaded with the core concept, then lists sections, then gives usage guidance. The final line about omitting 'section' is useful but slightly awkward with a double space and no punctuation. Overall, every sentence contributes meaning.

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 and no annotations, the description does a reasonable job of describing the return shape by naming sections and the 'reading' line. However, it leaves the required 'crawl' parameter unexplained and gives no hint about when a crawl is ready to analyze. It is adequate for a simple read operation but has clear 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?

The schema provides zero descriptions, so the description must explain both parameters. It explains 'section' by enumerating valid sections and the omit-for-all behavior, but it does not explain the required 'crawl' parameter at all. This leaves the most important input undocumented.

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 identifies the resource as the derived analysis of a set of URLs and distinguishes it from per-URL data by saying 'what the SET of URLs means, not what each URL is.' It also lists the specific sections, making the purpose concrete. It lacks an explicit action verb like 'retrieves,' but the tool name and scope make the purpose evident.

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 no guidance on when to choose this tool over siblings such as get_issues or read_export, and it does not mention prerequisites like having a completed crawl. The only usage-related information is about the 'section' parameter, which is parameter-level guidance rather than tool-selection 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?

With no annotations, the description carries the full burden. It discloses sorting order, the finished-crawl requirement, and the include_fixes verbosity behavior. It does not describe the output record shape, pagination/limit effects, or side effects, though 'get' implies read-only.

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 tight and well-structured: a one-line summary, a short 'start here' note, and a compact parameter reference. Every sentence adds information without repetition 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 4-parameter tool with no output schema and no annotations, this is adequate but incomplete. It covers the key invocation details and ordering behavior, but does not clearly describe the shape of the returned issue records or how the 'limit' parameter interacts with the result set.

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 meaningful semantics for crawl (folder name from list_crawls or absolute path), priority (allowed values), and include_fixes (verbose text). It omits 'limit', but that parameter is self-explanatory and has a sensible schema default.

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 identifies the tool as returning a 'priority-ranked issue register from a finished crawl' and explains the sorting. It also contrasts itself with raw CSV rows, which distinguishes it from sibling tools like read_export or list_exports.

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?

'START HERE, not with raw CSV rows' gives explicit practical guidance on when to use this tool. It does not name alternatives explicitly or state when not to use it beyond the raw CSV contrast, but the intended context is unmistakable.

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. It discloses the ordering behavior ('newest first') and scope, but does not mention any other traits such as pagination, permissions, or output format. Adequate but minimal.

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?

A single, concise sentence that front-loads the core action and ordering. No wasted words; it is appropriately sized for the tool's simplicity.

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 listing tool with no output schema, the description covers the essential aspects: what it lists, where, and sorting. It doesn't specify the return structure, but given the low complexity, this is a minor gap.

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. The only parameter, 'limit', is not explained at all; its purpose (likely maximum number of results) is only inferable from context and default value. The description fails to add any semantic value for this parameter.

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 it lists crawl folders with a specific ordering (newest first) and scope (audit root). It is distinct from siblings like list_exports, and while it doesn't explicitly differentiate, the resource and action are 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 but provides no explicit context on when to use this versus alternatives. It's a simple listing tool with no competing list-crawls sibling, so the need is implied rather than 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 provided, the description must carry the behavioral burden. 'List' conveys a read-only operation and 'with row counts' discloses a useful output trait. However, it doesn't explain behavioral details such as whether 'contains' filters results, whether the list is ordered, or what happens when no exports match.

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 with no filler. The core purpose is front-loaded, and the usage guidance earns its place by routing the agent to read_export. Nothing redundant is present.

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 list operation this is reasonably complete, but the lack of an output schema and annotations means the description should clarify the return format and the 'contains' parameter. It covers the main ask but leaves moderate gaps for a correctly informed call.

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 add meaning to parameters. It connects 'crawl' to a crawl folder, but 'contains' is left entirely undocumented; an agent must infer that it might filter by name or content. This is insufficient compensation for zero schema-level descriptions.

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 ('List the CSV exports'), the resource ('in a crawl folder'), and a notable output detail ('with row counts'). It also immediately contrasts with read_export by framing this as the discovery step before reading, so an agent can distinguish it from 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 gives explicit usage context: 'Use this to find the right export before calling read_export.' This tells the agent when to use the tool and sets up the expected sequence. It does not list when-not-to-use conditions or alternative tools beyond read_export, so it stops 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.

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the hard ceiling of 500 rows, the default of first 8 columns when columns is empty, whole-row substring matching for contains, and paging semantics for offset. These are non-obvious behaviors an agent needs to know before calling.

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 purpose sentence is front-loaded, and each subsequent line documents one parameter or behavioral constraint without fluff. The formatting is scannable and every line adds necessary operational detail.

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 six parameters, no output schema, and no annotations, the description is complete enough for correct invocation: all required arguments are explained, defaults are stated, limits are explicit, and paging/filtering behavior is clear. Nothing essential 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 description coverage is 0%, but the description fully compensates by documenting every parameter: crawl path meaning, export name source and optional .csv suffix, column behavior, contains filter scope, limit ceiling, and offset paging. This is far beyond the bare input 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?

Description opens with 'Read rows from one CSV export' — a specific verb, resource, and scope. It also names list_exports as the source of export file names, which distinguishes it from sibling tools that list exports or build reports.

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 the workflow: call list_exports to get a valid export name, then read rows from it with filters and paging. It does not explicitly state when not to use this tool or compare it with alternatives like get_issues or get_analysis, 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 behavioral disclosure burden. It reveals that the crawl runs in the background, returns immediately, can block when wait_seconds is set, and that config files are rejected on the free tier. This is substantial and useful context beyond the raw schema.

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 front-loaded with the core behavior, followed by a compact parameter block. Every line provides necessary operational detail, and no content is redundant with the schema. The formatting makes it easy for an agent 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 six parameters, no annotations, and no output schema, the description is remarkably complete. It covers invocation, return behavior, polling strategy, licensing constraints, and mode trade-offs. An agent has everything needed to call the tool correctly and set expectations.

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 fully document parameters. It does so admirably: url, label, full, everything, config, and wait_seconds each receive meaningful explanations, including defaults, trade-offs, and licensing caveats. This goes far beyond the bare schema titles.

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 action ('Start a headless Screaming Frog crawl in the background'), names the resource, and distinguishes itself from the sibling crawl_status tool by noting it returns a job_id immediately and should be polled. This is clear and 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 gives clear guidance on parameter usage and points to crawl_status for polling. It also explains when to use full mode for sites over ~500 pages and cautions about config licensing. It does not explicitly list when not to use the tool, but the context is sufficient for an agent to choose correctly.

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