jhnrd

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

With no annotations, the description carries the behavioral burden. It adds useful context: resolved conflicts are intentionally kept, and the record serves as evidence of not silently picking one side. This goes beyond a bare label. Still, it does not disclose output shape, pagination, safety, or authentication requirements.

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: conflict records. Each sentence contributes meaning, including the retention of resolved conflicts and the evidentiary purpose. It is slightly discursive but remains efficient.

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 no output schema, the description states the conceptual scope adequately. However, it does not clarify what the tool returns or how it behaves when invoked, and it offers no usage context. Given low complexity, it is acceptable but not fully 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?

The tool has zero parameters and the schema is empty, so there are no parameter semantics to document. The description reasonably focuses on meaning rather than inputs. The baseline of 4 applies because no parameter documentation is needed.

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: records where sources disagree and resolved conflicts retained. It distinguishes the tool's content from siblings like gaps or unconfirmed. However, it lacks an explicit action verb like 'list' or 'show', so the operative behavior is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies the tool exposes conflict records, but it does not state when a user should choose jhnrd_conflicts over jhnrd_unconfirmed, jhnrd_gaps, or jhnrd_search. No exclusions or use-case conditions are provided.

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 explains what content the tool reveals, but not whether it is a safe read-only operation, what the output looks like, or whether any side effects exist. This is a meaningful gap for an unannotated 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 compact and front-loads the most important question: who made this and who supports it. The philosophical framing adds context but slightly reduces directness. Overall, it is appropriately sized for the tool.

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 informational tool, the description conveys the core purpose and content. However, with no output schema, it does not explicitly state what the agent should expect in the response, such as a formatted disclosure statement or structured fields. This leaves some uncertainty but is not fatally 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?

The tool has zero parameters and an empty input schema, so parameter documentation is not needed. The description does not need to explain parameters, and the baseline for a zero-parameter tool 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: to reveal who created and funds it, and to disclose conflicts of interest and provenance. It uses a metaphorical but understandable framing. However, it does not explicitly distinguish itself from the sibling tool jhnrd_conflicts, which may also relate to conflicts.

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 this tool is for learning about the tool's own origins and conflicts, but it provides no explicit guidance on when to choose it over siblings like jhnrd_conflicts or jhnrd_status. No alternatives, exclusions, or conditions are given.

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, but it only lists content categories and gives no operational traits: no read-only/write indication, no mention of side effects, and no return shape. The '口' metaphor makes it ambiguous whether invocation observes gaps or declares them.

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 brief and front-loads the three gap types before the purpose statement. The poetic ending is not strictly necessary but does no real harm; no word is inflated.

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 tool is simple (one optional boolean, no output schema), so the description is minimally usable, but it does not state what a call returns, how include_resolved affects results, or how this tool relates to unconfirmed/status siblings. It is adequate as a hint, not complete enough for confident 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 schema alone documents include_resolved with a clear Japanese description, and schema coverage is 100%, so baseline 3 applies. The tool description adds nothing about this parameter or how including resolved gaps changes behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names concrete categories (known_gaps, attempts, findings) and states the goal of making absence expressible, so it is not a tautology. However, it never uses a concrete verb such as list/get/retrieve; the metaphorical '口' leaves it unclear whether this tool returns gaps, records gaps, or reports a status.

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 implies a use case: use this when you need to know or assert what is missing ('何が無いかを、無いと言えるようにするため'). It gives no explicit when-not or alternative guidance, and does not contrast with siblings such as jhnrd_unconfirmed or jhnrd_status.

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. It discloses meaningful behavior beyond a simple fetch: it resolves referenced sources and returns them with tier and currency status. It does not mention auth, error cases, or side effects, but as a read-style 'return' tool, the disclosed output behavior is the most important part.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, each earning its place: the first states the overall scope (one item, all data), and the second adds the distinguishing detail about source resolution and tier/currency. No filler or 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?

Given the low complexity (one required parameter, no output schema), the description adequately explains what the agent will get back: item fields and resolved sources with tier/current status. It could mention error/not-found behavior, but for a simple single-item fetch, the essential calling information is present.

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?

There is only one parameter, id, and the schema already describes it fully with an example ('genzan-bcp'). The description adds no additional parameter-specific meaning, but with 100% schema coverage, no compensation is needed.

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 returns a single item's full set of data (要件・効果・期限) plus resolved referenced sources with tier and currency. It distinguishes itself from siblings like jhnrd_list_items (plural listing) and jhnrd_get_source (source-focused) by specifying singular item scope and source resolution 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 usage context is implied: use this when you need everything about one item, including resolved sources. However, no explicit when/when-not guidance or alternative tool names are mentioned, so the agent must infer the distinction from the description alone.

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 transparency burden. It usefully discloses that the tool always returns the tier and current-version flag, which is meaningful behavioral information. However, it does not mention whether there are side effects, permission requirements, error cases, or how invalid ids are handled.

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 compact sentence with no filler. It front-loads the core purpose and then states the guaranteed return fields, earning its place efficiently.

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 tool is simple and the parameter is fully documented, but there is no output schema and the description only partially explains the return. It names tier and current as guaranteed fields, but '素性' is vague about what other source attributes are returned, leaving some uncertainty for an agent deciding if this tool satisfies its needs.

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%: the single 'id' parameter is described with an example. The description adds no additional parameter semantics, which is acceptable because the schema already fully documents the only 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 identifies a single source ('出典1件') and states it returns source attributes, with tier and current status explicitly called out. The singular scope distinguishes it from list-oriented siblings like jhnrd_list_sources and jhnrd_search, though it does not name those alternatives.

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 explicit guidance about when to use this tool versus siblings such as jhnrd_search, jhnrd_list_sources, or jhnrd_get_item. Usage is only implied by 'one source' and the id parameter; no conditions, exclusions, or alternative routing are provided.

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 does disclose a meaningful policy: corrections do not delete original text, so the version/seed number is essential for later cross-checking. Yet it never explicitly states what the tool itself does or returns—such as that invoking it provides citation instructions—or whether it is a read-only informational call.

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 states the topic, the second gives the actionable rule and its rationale. The parenthetical 'seed 番号' adds useful clarification, and there is no filler or redundant content.

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 informational tool with no output schema, the description supplies the core content needed: the citation rule and the reason behind it. It leaves a small gap by not describing what a returned response looks like, but the tool is simple enough that this is not dangerously 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?

The input schema has zero parameters and 100% schema description coverage, so there is no parameter information for the description to add. This matches the baseline for zero-parameter 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 identifies the topic and resource: how to cite, with the specific rule of including the version/seed number. It is distinguishable from sibling tools about items, sources, search, and status, though it uses a noun phrase rather than an explicit action verb like 'returns' or 'provides instructions.'

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 makes it clear that the citation rule matters whenever citing, especially because original descriptions are preserved after corrections and the version is needed for later reconciliation. However, it never explicitly says when to use this tool versus alternatives and names no alternative tools or exclusion conditions, so the usage guidance 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?

With no annotations, the description itself must communicate behavior. It states that the result is a summary list, not the full item, and that results can be narrowed by insurance and kind. This is reasonably transparent for a read-only list operation, though it does not specify output fields or limits.

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 clauses: what it lists, how to filter, and where to get details. No filler; the most important 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 list tool with no output schema, it states that output is a summary list but not what fields it contains. In particular, it does not say whether the summary includes an identifier needed to call jhnrd_get_item, so an agent may not know how to chain the 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 coverage is 100%, so the schema already documents all three parameters. The description adds only the fact that insurance and kind act as filters, which is marginal beyond the schema; it does not explain parameter formats or interactions.

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 concrete action: '収録している項目の一覧(要約)' (a summary list of contained items), then names the two filtering dimensions, insurance and kind. It also points to jhnrd_get_item for details, which separates this list tool from the detail-retrieval sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: use this tool for a filterable summary list, and use jhnrd_get_item when full detail is needed. It does not explicitly exclude jhnrd_search or jhnrd_list_sources, but the summary-versus-detail routing is enough to guide 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 full burden. It discloses that the tool returns counts broken down by current status, which is a behavioral detail beyond the schema. However, it doesn't mention whether the listing is paginated, ordered, or requires any authentication/scoping, so it only partially covers behavioral expectations.

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, no waste, with the key behavioral note (why current counts are split) front-loaded after the main purpose. The description earns every word and is 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?

For a simple list tool with two optional parameters and no output schema, the description covers the purpose and the rationale for the count breakdown. However, it omits any mention of the return format or whether the listing is sorted/filtered beyond the parameters; not critical for a list tool, but slightly incomplete given no annotations or output 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 coverage is 100% (both parameters have descriptions in the schema), so the description adds little beyond what the schema already provides. The description's mention of '素性ごと、現行かどうかごとに数えたもの' implies the 'only_current' parameter's relevance, but it doesn't add syntax or format details; baseline 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 states the tool lists sources ('出典の一覧') and mentions it returns counts by feature and currency, which distinguishes it from generic sibling tools like jhnrd_get_source. However, it doesn't explicitly name the operation 'list' as a verb or contrast it with a sibling; the resource is clear but the differentiation is implicit.

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 why the counts are split between current and total ('statute が何件あるかだけを言うと実態より良く見えるので、現行版の数を分けて出す'), giving context for how the output should be interpreted. It doesn't explicitly say when to use this tool versus alternatives like jhnrd_search or jhnrd_list_items, but the context is clear enough for a simple list operation.

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 adds a useful and specific behavioral guarantee—returning 'not found' instead of guessing. However, it does not explain matching semantics (exact/substring), read-only safety, or what a found result looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler. The scope is stated first, and the important no-guess behavior is included 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 simple two-parameter search tool, this is largely complete: it names the searched fields, states the not-found behavior, and the schema fully documents parameters. The main missing piece is explicit guidance on when to choose it over sibling tools, but the core call contract is adequately covered.

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%, so the baseline is 3. The description itself adds no detail about parameters, but the schema already documents q with examples and the limit with its default, so no critical parameter information is missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (cross-search) and concrete resources: item names, requirement bodies, and effect wording. This clearly separates it from sibling tools like list_items, get_item, or conflicts, which have different purposes.

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 its usage context: searching for a term across multiple fields. However, it does not explicitly say when to prefer this over alternatives such as list_items or get_item, nor does it mention any exclusions or fallback routing.

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. It discloses what data the status call exposes and adds a valuable semantic caveat: the item count is not a count of all home-visit nursing billing requirements. It does not explicitly state output format or absence of side effects, but the status-report nature makes these less critical.

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 resource and purpose. Each sentence earns its place: what the status contains, a critical caveat about the item count, and the intended first action.

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 status tool with no output schema, the description lists all the report fields and the key interpretation caveat. It could be slightly clearer about what 'version' refers to, but overall an agent has enough information to invoke the tool correctly and understand its result.

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 and an empty input schema, so the baseline of 4 applies. There are no parameter semantics for the description to add or clarify.

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 a database status report and enumerates its exact contents: version, item count, source provenance breakdown, unconfirmed requirements count, and unresolved discrepancies count. The closing instruction 'look here first' positions it as the overview entry point, distinguishing it from the more specific 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 to use this tool first ('まずここを見ること'), providing clear usage context. It does not name alternatives or state when not to use the tool, but the overview-versus-detail relationship to the sibling tools is 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. It describes content and intent but does not state whether the tool is read-only, what it returns, whether results can be empty, or any side effects. '一覧' is the only subtle hint that it returns a list.

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, each adding information: contents, the 'not left blank' property, and intended use. The brief metaphor '口' is slightly unusual, but the overall description is tightly scoped and not bloated.

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, it is mostly sufficient: an agent can infer a read-only list and invoke it without arguments. However, with no output schema and no explicit return format, the exact shape of list items is unclear, and the relationship to sibling tools like jhnrd_gaps is not addressed.

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 zero properties and additionalProperties is false, so there are no parameters to document. The 0-parameter baseline of 4 applies, and the description adds nothing needed for parameters.

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 '原文で確認できていない要件の一覧...' which identifies a concrete resource (unconfirmed requirements) and the content (list plus reasons). The phrase '弱いところを、先に見るための口' conveys its role as a quick-look tool. It is distinguishable from siblings by focusing on 'unconfirmed' requirements, though it lacks an explicit action verb such as '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 final clause '先に見るための口' gives an implied use case: start here to find the database's weak points. However, it gives no explicit guidance on when to choose this over overlapping siblings like jhnrd_gaps or jhnrd_conflicts, and no exclusions or alternative conditions are stated.

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