jma_get_warnings

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

With no annotations, the description carries the full burden and delivers: it explains the severity ordering (注意報 < 警報 < 危険警報 < 特別警報), the 2–5 alert level for rain/landslide/surge, the shape of the return (distinct warnings, per-area breakdown, headline text), and critically that an empty in_effect list means nothing is in effect. It stops short of stating read-only semantics or any rate/coverage 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?

Three dense sentences, front-loaded with what it returns and when, with the Japanese taxonomy embedded where it disambiguates output. Slightly long, but every clause (severity ladder, alert levels, empty-list semantics) 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?

There is no output schema and no annotations, so the description must explain the return value — and it does, covering severity, alert level, sub-region counts, per-area hazards, Japanese headline text, and the empty-result meaning. An agent can call this and interpret the response without further context.

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 already 100%, so baseline is 3, and the description adds real meaning beyond the schema by explaining that naming a municipality narrows the result to that area — a granularity behavior the parameter docs do not state. It does not document the 6–7 digit area-code path itself, but the schema already does.

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?

States a specific verb+resource: current weather warnings/advisories from JMA for a place in Japan, with the exact Japanese terminology. It is clearly distinct from jma_get_forecast by being present-tense 'in effect now', though it never explicitly names jma_get_volcano_warnings as the sibling that handles a different warning class.

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?

'in effect now' implies the current-conditions use case and the schema points at jma_find_area for area codes, but there is no explicit when-to-use/when-not statement or named alternative (e.g. forecast vs warnings, weather vs volcano warnings). Usage is inferred rather than directed.

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