日本の住所の災害リスク（洪水・地震・土砂・津波・高潮・液状化）を、国の公式データ（重ねるハザードマップ・J-SHIS）に基づいて判定して返します。日本国内の住所または緯度経度に対応。出典つき。
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | 緯度（address の代わりに座標で指定する場合） | |
| lon | No | 経度（address の代わりに座標で指定する場合） | |
| lang | No | 応答の言語。'en' で英語サマリー（国外投資家向け）。既定は 'ja'。 | |
| address | Yes | 日本の住所（例: 東京都墨田区押上1-1-2）。緯度経度で指定する場合は lat/lon を使う。 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool returns results with sources, implying a read-only, non-destructive operation. However, it does not mention rate limits, network dependencies, or response format, which are important for an agent to anticipate behavior during invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that front-load the main function and then add scope and source details. No superfluous words or repetition. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no output schema. The description covers the core function and data sources, but lacks information about the return structure (e.g., risk levels per disaster type, format). For a moderately complex tool, the description is minimally complete but could better prepare the agent for the response.
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 description adds little beyond the schema's parameter descriptions. It summarizes the tool's purpose and supported inputs but does not provide deeper semantic detail for each parameter. The description is adequate but does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assesses disaster risk (flood, earthquake, landslide, etc.) for Japanese addresses using official government data (重ねるハザードマップ・J-SHIS). It specifies the exact risk types and data sources, making the purpose highly specific and actionable.
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 implicitly defines when to use the tool: for disaster risk assessment of Japanese addresses or lat/lon coordinates. It mentions the data sources and scope (Japan), which helps the agent judge applicability. Without sibling tools, this is clear enough, though explicit when-not-to-use guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
