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

Annotations already declare readOnlyHint=true, and the description's verb '確認します' matches a read-only operation. The description adds the output groups (A/B/C/D) and notes the relationship to comprehensive licenses, which is useful context, but it does not disclose additional behavioral aspects like auth requirements or rate 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 a single, concise sentence that front-loads the primary purpose and includes a relevant consequence (license type differences). Every word earns its place, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter and no output schema, the description adequately explains what the tool returns and why it matters. It lacks explicit error-handling or edge-case information, but for this complexity level, it is complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter 'country_name', which already explains that it accepts Japanese or English names. The main description does not add further parameter-specific meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description clearly states the specific action ('確認します') and resource ('指定された国の輸出管理上のステータス'), and specifies the output format (グループA/B/C/D). It also provides additional context about comprehensive license types, which helps differentiate it from sibling tools like export_reg_get_white_countries.

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 when to use the tool (when you need a country's export control status), but it does not explicitly state alternatives or exclusions. The mention of comprehensive license types provides some context, but there is no direct guidance compared to 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?

The readOnlyHint annotation is present, and the description adds value by disclosing that the tool fetches and parses Excel data from METI, implying external data access and network dependency. This goes beyond the annotation by explaining the underlying process and data source, though it does not describe every behavioral nuance.

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 concise sentences, each contributing essential information: the matching action, the nature of the list, and the data retrieval/parsing mechanism. No unnecessary wording, and the structure is front-loaded with the primary purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, read-only tool with good annotations, the description adequately explains the domain, data source, and lookup mechanism. However, since there is no output schema, it does not describe the output format (e.g., matched results vs. boolean), leaving 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 descriptions cover 100% of parameters, explaining that 'organization' supports partial matching and 'country' filters in Japanese. The tool description itself does not need to add parameter details, and the baseline of 3 applies because the schema carries the semantic weight.

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: '組織名を照合' (matches organization names) against the specific METI Foreign User List (懸念企業リスト). This is a specific verb+resource pairing that distinguishes it from sibling tools dealing with laws, annexes, or country checks.

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 context for when to use the tool: to check an organization name against METI's list of entities of concern. It does not explicitly mention alternatives or exclusions, but the context is strong enough to infer appropriate use.

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

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

While the readOnlyHint annotation already communicates the safe read nature, the description adds only that item_number can retrieve details of a specific category. It does not disclose that table_number can be set to 2 or 3 for different annex types, nor what happens when item_number is omitted, making the described scope misleading.

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

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

The description is two concise sentences with the main verb and object front-loaded. Every sentence is purposeful, though the second sentence mostly duplicates information already present in the schema.

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 has no output schema and the description omits critical functional details such as the table_number options, default behavior when item_number is absent, and the structure of returned data. The mismatch between the description's exclusive focus on Annex 1 and the schema's broader capabilities further reduces completeness.

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 provides 100% description coverage with detailed parameter semantics, so the baseline applies. The tool description contributes no additional semantic value beyond restating item_number's role and does not mention table_number at all.

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 (取得します) and the resource (別表第1 of the Export Trade Control Order), and notes that item numbers can be specified for category details. However, it does not explicitly distinguish this tool from siblings like export_reg_get_annex3_2, and the schema's table_number parameter suggests a broader scope than the description implies.

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 is provided about when to use this tool versus alternatives such as export_reg_search_law or export_reg_get_annex3_2. The description also fails to mention the table_number parameter's ability to fetch other annexes (catch-all, white countries), which could mislead an agent about when this tool is appropriate.

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

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

The readOnlyHint annotation already declares this is a read-only operation, and the description '取得します' is consistent. The description adds the purpose and the specific list, but no additional behavioral traits like return format or special handling. With annotations covering safety, this is adequate.

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, front-loaded with the action and resource, followed by the use case. Every sentence adds value with no redundancy, making it efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with no parameters and no output schema, the description adequately states what it retrieves and why it is used. However, it does not explicitly describe the return format or any edge cases, which would be helpful if the list behavior is non-obvious. The use case adds context, making it mostly 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 has no properties. The description does not need to explain any parameters. A baseline of 4 for a no-parameter tool is appropriate, and the description provides no conflicting information.

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 retrieves the list from Appendix 3-2 (UN arms embargo countries/regions) of the Export Trade Control Order, with a specific verb '取得します' (get). It is immediately distinguishable from sibling tools like export_reg_get_annex (generic) and export_reg_get_white_countries (different list).

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 includes a clear context for when to use the tool: for objective requirements determination under catch-all regulations (キャッチオール規制の客観要件判定). This provides clear context but does not explicitly state when not to use it or name alternative tools, so it misses the top score.

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 readOnlyHint annotation already indicates a read-only operation, and the description's '取得します' (retrieves) is consistent. The description adds context that the content includes criteria for catch-all usage requirements, but does not disclose any additional behavioral traits such as pagination, error handling, or response format.

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, front-loaded with the main action and resource. The second sentence provides useful contextual information without unnecessary detail. 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 tool with one optional parameter and no output schema, the description sufficiently explains the tool's purpose and content. It does not describe return format or edge cases, but given the simplicity and annotations, it is largely complete. A more detailed output description would be nice but is not critical.

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 fully describes the optional 'article' parameter, including an example and effect (retrieve only that article). The description adds no additional parameter meaning, so it aligns with the baseline of 3 since schema coverage is 100%.

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 retrieves the content of the Fear Ordinance (おそれ省令), specifying it as the Operation Notice of the Export Trade Control Order. It also notes its relevance to catch-all regulation usage requirements, distinguishing it from sibling tools that retrieve other legal documents like laws or annexes.

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 a use case (when needing Fear Ordinance content or catch-all usage criteria) but does not explicitly state when to use this tool versus alternatives, nor mention any exclusion conditions. Usage is inferred from the resource type rather than explicit 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?

The readOnlyHint annotation already declares this is a safe read operation, and the description adds context about the specific law types it can access. But it does not disclose other behavioral traits such as error handling, pagination, or output format beyond stating it retrieves law text.

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 concise sentences that front-load the purpose and immediately mention the relevant law scope. No redundant or filler 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 simple read-only tool with a rich schema and no output schema, the description adequately conveys purpose and scope. It is missing explicit output format details, but the statement 'get the text of the law' hints at the return value sufficiently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both law_id and elm already well-described including examples. The tool description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the tool retrieves the law text for a specified law ID ('指定された法令IDの法令本文を取得します'). It also names the specific export-control laws it covers, distinguishing it from sibling tools like search_law or get_annex.

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?

Provides clear context that this tool is for referencing export-control related laws such as the Export Trade Control Order, Foreign Exchange Order, and relevant ministerial ordinances. However, it does not explicitly mention when not to use it or suggest alternative tools like search_law for finding law IDs.

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 readOnlyHint already signaling a read-only operation, the description adds minimal behavioral context by noting the ordinance contains technical specifications and thresholds. It does not disclose output format, response size, pagination, or any access requirements. It is consistent with the annotation but adds little beyond what the annotation already implies.

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 core function and resource, the second adds relevant context about the ordinance's content. There is no redundancy, and the most important information is front-loaded. 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 read-only tool with one optional parameter and no output schema, the description gives sufficient context: the exact regulation name and what type of content it contains. It deliberately leaves parameter details to the schema. A minor gap is the lack of any note about return format, but given the tool's simplicity, this is not a major shortcoming.

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 fully describes the single 'article' parameter, including optionality and behavior (省略時は全文を取得). The tool description adds no parameter-level information beyond this, so it neither enhances nor contradicts the schema. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 輸出貿易管理令の貨物等省令...の条文を取得します (acquires provisions of the Goods etc. Ministerial Ordinance). It also specifies the ordinance's content (technical specifications and parameter thresholds), which distinguishes it from sibling tools like export_reg_get_law or export_reg_get_annex. This provides a specific verb+resource+scope.

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

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

The description does not explicitly mention when to use this tool over alternatives, nor does it provide exclusions or comparisons with sibling tools. The phrase about list-controlled items implicitly suggests a use case, but no direct guidance is given. This is implied usage only, so it falls short of the clear context needed for a higher score.

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 readOnlyHint annotation already signals that this is a safe read operation, so the description does not need to restate that. It adds some context about the underlying data source (ministerial ordinance and item numbers) but does not disclose output format, potential limitations, or whether all thresholds are returned at once. Given the annotation coverage, a score of 3 is appropriate—the description adds moderate value beyond the annotation.

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 that is front-loaded with the core action and resource. It is concise and does not waste words, though the second clause rephrases the purpose rather than adding new factual detail. This is efficient but not maximally tight, hence a 4 rather than 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter and no output schema, the description provides sufficient context: it explains what the thresholds are for, how they are derived (item number + ministerial ordinance), and the regulatory purpose. However, the phrase 'combining item numbers and ministerial ordinance' could imply the user must provide both inputs, when only item_number is required. This slight ambiguity prevents a perfect score.

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 fully documents the only parameter 'item_number' with a detailed description of values 1-15 and their meanings, providing 100% coverage. The description adds no additional parameter-level information beyond referring to 'item numbers', so it does not need to compensate. Baseline 3 is correct when the schema carries the semantic weight.

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 retrieves technical parameter thresholds for each item number of the Export Control List regulations. It specifies the exact resource (thresholds) and the scope (per item number), which distinguishes it from sibling tools that handle laws, annexes, or ordinance searches. The action verb '取得します' is specific 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 implies the intended use case: checking regulated technical specifications by combining item numbers and ministerial ordinance. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it when threshold data is needed. Sibling names like export_reg_get_annex and export_reg_get_ministerial_ordinance are distinct in purpose, though no direct comparison is 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?

The annotation already declares readOnlyHint=true, and the description's '取得します' is consistent. The description adds the use-case context but does not disclose additional behavioral aspects such as return format, pagination, or error handling. For a read-only getter with annotation coverage, this is adequate but not rich.

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

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

Two concise sentences, first states the action and resource, second provides contextual use. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read-only tool, the description provides the core function and a use case. It does not explain return values, but the absence of an output schema and the tool's simplicity make it reasonably 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 schema already provides 100% coverage of the 'category' parameter with examples and explanation. The description does not add further parameter-level details beyond referring to item classification.

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 retrieves item classifications from the Customs Tariff Law Annex (関税定率法別表の品目分類を取得します). It also specifies a particular use case related to catch-all regulations, distinguishing it from sibling tools that fetch other legal texts or parameters.

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 a specific context: used for checking items related to Article 16 of the catch-all regulation (キャッチオール規制の16項中欄). However, it does not explicitly mention alternatives or when not to use this tool, though the context implies its domain.

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?

Annotations declare readOnlyHint=true, and the description's 'retrieves' aligns with that. It adds legal context and eligibility info but no additional behavioral traits such as pagination or output format. With annotations covering safety, a 3 is appropriate.

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 that states the action, resource, and relevant context without any filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only list tool, the description sufficiently conveys what is returned (the list) and its legal basis. No output schema exists, but the description's 'list of Group A countries' covers the return type. Minor omissions like ordering or codes are acceptable given the low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and schema coverage is trivially 100%. Baseline for 0 params is 4; description adds no parameter details 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 retrieves the list of Group A countries specified in Annex 3, using a specific verb (取得します) and resource. It distinguishes from sibling tools like export_reg_check_country by focusing on the full list.

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 context that Group A countries are eligible for comprehensive licenses, implying a use case. However, it does not explicitly exclude alternatives or state when to prefer this over sibling tools like export_reg_check_country.

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 readOnlyHint annotation already signals a safe read operation. The description adds that searches can target law names or provision content but offers no additional behavioral traits such as return format, pagination, or behavior with no results. With annotations covering the safety profile, a 3 is appropriate.

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 concise sentences effectively communicate the tool's purpose and search capabilities. The information is front-loaded with the primary action and resource, containing 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?

The tool has no output schema, so the description could be expected to hint at return values or search behavior. It does not mention what the search returns (e.g., list of laws, metadata), nor does it address edge cases. Given the moderate complexity and lack of output schema, the description is adequate but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both keyword and law_type well-described. The description adds minor context by clarifying that keyword can match law names or provision content, but does not significantly enhance understanding beyond what the schema already provides. 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 clearly states the tool searches export control-related laws by keyword, with a specific verb ('検索します') and resource ('輸出管理関連の法令'). It distinguishes itself from sibling getters by emphasizing search over direct retrieval, and mentions searchable fields (law name and provision content).

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 use when needing to find laws by keyword, contrasting with sibling tools that fetch specific laws or annexes. While it provides clear context, it does not explicitly state when not to use it or name alternatives, so it falls short of a full 5.

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