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

Annotations already declare readOnlyHint=true and destructiveHint=false, which cover the safety profile. The description adds meaningful behavioral context: it integrates scoring across risk types, supports exactly 10 prefectures, and provides a bilingual clarification. This goes beyond what annotations state, informing the agent about the scope and the nature of the output (integrated score). No contradiction with annotations; the description aligns with the read-only nature.

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

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

The description is exceptionally concise: two clear sentences (one English, one Japanese) that convey the purpose and a key limitation. It front-loads the core function before revealing the geographic scope. Every word adds value, with no redundant or filler content. The bilingual pair is a compact way to ensure international usability without sacrificing clarity.

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

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

For a tool with 5 parameters, a nested object, and no output schema, the description covers the main purpose and geographic scope but leaves several operational gaps. It does not explain how to choose between address and latlng, whether both can be used, or what the output format looks like (e.g., a score per risk type or a single integrated score). It also does not mention that riskTypes defaults to 'all'. While the description is adequate for a basic understanding, it lacks details that would help an agent correctly construct the input, especially for the optional parameters. A 3 reflects that it is functional but 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?

With schema description coverage at 60%, some parameters (address, prefecture, neighborhood) have schema descriptions, while latlng and riskTypes lack explicit descriptions in the schema. The description helps by listing the three risk types (flood, landslide, earthquake), which maps to the riskTypes parameter, and mentions 'integrated scoring' which implies how riskTypes are combined. However, it does not clarify the relationship between address and latlng (e.g., are they mutually exclusive? which takes precedence?), nor does it explain the default behavior of riskTypes (default is ['all']). The description adds some value but does not fully compensate for the uncovered parameters, so a baseline 3 is justified.

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

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

The description states a specific verb ('assess'), a resource ('property disaster risk'), and enumerates the risk types (flood, landslide, earthquake). It also specifies the integrated scoring across 10 prefectures, which differentiates it from siblings that focus on other aspects (e.g., compare_prefectures for comparison, assess_contract_risk for contracts). The purpose is unambiguous and distinguishes the tool from its siblings without needing to inspect the schema.

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

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

The description implies the tool is for evaluating disaster risk on a property, but it does not explicitly state when to use this tool versus alternatives. It mentions the geographic scope ('10 prefectures') which hints at a limitation, but does not provide explicit conditions or exclusions (e.g., 'use only for these prefectures, otherwise see X'). Usage guidance is implied rather than clearly articulated, so a 3 is appropriate.

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