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

With no annotations, the description carries the full burden and does well: it states that no API key is needed, that results are ranked matches, and it explains the area levels and hierarchy. It does not explicitly describe error behavior or rate limits, but for a read-only lookup this is strong disclosure.

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 front-loaded with the core action and accepted formats, then moves into return details and usage guidance. Every sentence contributes: examples, level definitions, ambiguity handling, and the no-API-key note.

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, but the description explains what is returned: ranked matches with level, hierarchy path, and office_code. Combined with the sibling routing guidance and input format details, an agent has enough to invoke the tool correctly.

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 schema already documents the query and limit parameters, including examples. The description reinforces accepted input formats and JMA codes, but adds little beyond the schema's own parameter documentation; 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 a specific verb and resource: looks up JMA area codes for a place in Japan. It distinguishes this tool from siblings by explaining that jma_get_forecast and jma_get_warnings usually accept place names directly, while this tool is for resolving ambiguity.

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 says you can usually pass a place name straight to the forecast and warning tools, and to call this first when a name is ambiguous, citing the 府中 example. This gives clear when-to-use and when-not-to-use guidance with named alternatives.

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 burden and does disclose the response shape, bilingual tsunami text, sort ordering (strongest first), and the cost of include_stations. It does not state what happens if both identifiers are given or if neither is supplied — notable since required parameters = 0.

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?

One dense paragraph, front-loaded with what is returned, then how to identify the quake. The field enumeration is long but each item maps to something an agent needs; nothing is redundant.

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?

No output schema exists, so the description must describe returns — and it does so in detail, including ordering and the optional station payload. The remaining gap is the precedence/fallback behavior when zero or two identifiers are provided.

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 both identifiers and the boolean are already documented in the schema. The description adds only marginal meaning: provenance of detail_id and the volume implication of include_stations. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Specific verb+resource ('Full JMA report for one earthquake') followed by an enumeration of the returned fields: hypocenter, magnitude, tsunami assessment, intensity by prefecture/region/municipality. It is clearly distinguishable from jma_list_earthquakes, which is named as the source of the detail_id.

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 tells the agent how to obtain the identifier (detail_id from jma_list_earthquakes, or the 14-digit event_id) and when to set include_stations ('large quakes have hundreds' of stations). It stops short of an explicit 'use jma_list_earthquakes instead when you have no ID' exclusion, but the routing is clear enough in practice.

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 and does so well: it discloses issuance cadence (≈05:00, 11:00, 17:00 JST), timezone handling (+09:00), the Japanese-verbatim vs. weather_en label distinction, and what the response contains. It omits error behavior for invalid areas and any rate/availability limits, keeping it from a 5.

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?

Front-loaded with purpose, then a structured 'Returns:' enumeration and operational notes. The returns sentence is long, but every clause (wave height, reliability grades, normals, forecaster overview) is load-bearing because no output schema exists.

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?

No output schema exists, so the description must explain the return payload — and it does exhaustively: per-block precipitation, temperatures, 7-day outlook with reliability grades and climate normals, plus the written overview. Combined with timezone and issuance notes, an agent has everything needed to call and interpret results.

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% and documents accepted scripts and area codes, so the baseline is 3. The description adds genuine semantics beyond the schema by explaining that naming a municipality narrows results to its sub-region, clarifying how granularity is chosen through the single `area` 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?

States a specific verb and resource — a JMA weather forecast for a place in Japan — and its scope (per prefecture-level office, today + 2 days + 7-day outlook) is unmistakable. It is clearly distinct from siblings like jma_get_warnings or jma_list_earthquakes, so an agent can select it without opening another 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 gives clear usage context: name a municipality to narrow to its sub-region, or supply a JMA area code 'from jma_find_area', which implicitly routes the agent to that sibling for lookup. It does not state explicit exclusions (e.g., forecasts vs. warnings), so it stops short of a 5.

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 behavioral burden well. It discloses ordering (newest first), event grouping, active-status semantics, severity hierarchy, coastal forecast structure, observed heights, and source earthquake linkage. It stops short of describing error or no-event behavior, but covers the important output semantics thoroughly.

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 dense but front-loaded: the resource and source appear immediately, followed by return structure and severity interpretation. Some parenthetical detail makes it long, but most of it earns its place by explaining non-obvious return semantics.

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, so the description must explain return values, and it does: active status, highest level hierarchy, grouped coastal areas, expected heights, arrival times, observations, and source earthquake. For a one-parameter read tool, this is complete enough to call and interpret correctly.

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 the single limit parameter, including default and min/max. The description does not add parameter-specific meaning beyond saying results are recent events, so 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?

States a specific verb and resource: returns JMA tsunami warnings, advisories and forecasts. It clearly distinguishes this from sibling tools like jma_get_warnings and jma_get_forecast by naming the exact hazard type and bulletin contents.

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 this tool is appropriate: retrieving latest tsunami bulletins and interpreting whether any warning is active. It does not explicitly name alternatives or exclusions, but the hazard-specific scope makes usage unambiguous.

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 and does well: it enumerates returned fields, decodes JMA status wording (火口周辺規制, 周辺海域警戒), and defines negative-result semantics. It does not explicitly state read-only/idempotent behavior or any auth/rate constraints, which is a minor 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?

Front-loaded with the core purpose and scoped in a handful of dense sentences; the parenthetical JMA wording glossary is informative but bulky. Nearly every clause earns its place, with only mild redundancy against the schema's own examples.

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?

With one optional parameter and no output schema, the description must describe the return payload itself, and it does: fields, level meanings, raise/lower indicators, and empty-feed interpretation. Nothing an agent needs to call or interpret this tool is missing.

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% and the schema already documents the volcano parameter with examples, so the description's restatement of Japanese/romaji names and JMA codes adds little beyond it. The additional value is interpretive context about alert levels, not parameter semantics, so 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?

States a specific verb and resource ('Lists volcanoes in JMA's current eruption-warning feed') and names the concrete payload: alert level 1–5, status wording, raise/lower flags, municipalities, coordinates. This clearly separates it from generic warning feeds, but it never names the sibling jma_get_warnings or explains how the two differ, so sibling differentiation is left to inference.

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?

Explains the optional-filter workflow and gives the key interpretive rule that a volcano absent from the feed has no warning in effect, which tells the agent how to read an empty result. It stops short of saying when to prefer this over jma_get_warnings or jma_find_area for related queries.

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 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.

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

With no annotations provided, the description carries the full burden and does a good job disclosing key behavior: the feed covers roughly the last few weeks, results are newest first, and each item includes origin time, epicenter, magnitude, intensity, per-prefecture intensity, and detail_id. It does not mention authentication, rate limits, or error behavior, which keeps it from a 5.

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 dense paragraph but is front-loaded with the core purpose and scope. The field list and intensity-scale parenthetical are useful, though the run-on structure could be split for easier scanning.

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?

Because there is no output schema and no annotations, the description appropriately explains what each returned item contains and how the feed behaves. Combined with the fully documented input schema, an agent has enough to call it correctly, with only minor omissions like explicit auth or rate-limit 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 description coverage is already 100%, so the schema documents all four parameters. The description still adds value by giving example filter values and clarifying the JMA seismic intensity scale, including that it is not the Mercalli scale, which helps interpret min_intensity beyond the enum labels.

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 and resource: list recent earthquakes in and around Japan from the JMA feed, newest first. It also distinguishes this list operation from the sibling detail tool by explaining that each item includes a detail_id for jma_get_earthquake.

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 by naming the feed scope and showing filter examples such as min_intensity '4' or min_magnitude 5 to find significant quakes. It also points to jma_get_earthquake for details via detail_id, though it does not explicitly state when not to use this tool.

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