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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description only adds that these are AMeDAS *observation* readings (measured, not modeled) — useful but thin; it says nothing about freshness/latency, missing-station behavior, 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?

One front-loaded sentence with no waste. It is efficient but arguably too terse for the sibling set it lives in, leaving room for a routing clause at no structural cost.

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 an output schema present, rich annotations, and full parameter documentation, the description need not explain return values. The only meaningful omission is a pointer to the forecast/location/historical siblings an agent must choose between.

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% and the single parameter's meaning plus its default-to-all-stations behavior is fully documented in the schema. The description adds no parameter-level information, 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?

States a specific verb ('Get') and resource ('current weather observation data'), and the word 'current' implicitly separates it from get_forecast and get_historical_weather. It never names those siblings explicitly, so differentiation is left partly 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?

The adjective 'current' implies when this is appropriate versus forecast or historical lookups, but the description gives no explicit when-to-use/when-not statement and never routes to get_weather_by_location or get_forecast. Usage is only implied.

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 already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral detail beyond that, such as forecast horizon, freshness, or whether results are location- or time-based, but it does not contradict the annotations.

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 front-loaded sentence with no wasted text. It is appropriately concise, though its brevity leaves important usage distinctions unaddressed.

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?

An output schema exists and the single parameter is fully documented, so return value and input details need not be repeated. However, for a forecast tool in a crowded weather-tool family, the description is not complete enough to distinguish forecast scope or select this tool confidently.

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 prefecture parameter's English-name format and examples are fully documented in the schema. The description refers to the prefecture concept but adds no syntax, constraints, or meaning beyond what the schema already provides.

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 clear verb and resource: get a weather forecast for a prefecture. It does not differentiate the tool from close siblings such as get_current_weather, get_weather_time_series, or get_historical_weather, so an agent cannot tell from the description alone which weather query is intended.

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 no guidance on when to use this tool versus alternatives. With siblings covering current weather, location-based weather, time series, and historical weather, the absence of any when-to-use or when-not-to-use instruction is a meaningful gap.

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 already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — the ~1-2 week data retention window — but says nothing about behavior for out-of-range dates (error vs. empty result) or the JST assumption baked into the schema.

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 sentences, zero redundancy, and the core action is front-loaded before the availability caveat. Nothing could be cut without losing information.

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?

An output schema exists, so return values need no explanation, and both parameters are fully documented in the schema. What's missing is the edge-case behavior for dates outside the stated window — the one ambiguity an agent is likely to hit in practice.

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%: both station_code (with example) and target_datetime (ISO/`YYYY-MM-DD HH:MM`, JST) are already documented. The description adds no parameter-level meaning beyond the schema, 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?

States a specific verb+resource ("get historical weather data") with a scoping constraint (specific date and time). The word "historical" reasonably separates it from get_current_weather and get_forecast, but no sibling is named explicitly the way a top-tier definition would do.

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?

"Data is available for approximately the past 1-2 weeks" frames the viable window and implicitly rules out far-past queries, which is useful. However, it never tells the agent when to pick this over get_weather_time_series or get_current_weather, and gives no guidance on what to do when the requested date falls outside that window.

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 annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that, such as error behavior for unknown station codes, but with annotations doing the heavy lifting this remains 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 a single front-loaded sentence with no redundant wording. It states the action, domain, and lookup key immediately.

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 lookup with a fully documented schema, rich annotations, and an output schema, the description provides enough to invoke the tool correctly. The only meaningful omission is explicit routing guidance against sibling search/list tools.

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%, and the schema already provides a clear example ('44132' for Tokyo). The description reinforces that the input is an AMeDAS station code, but adds no syntax or format details beyond the schema.

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 ('Get') and resource ('AMeDAS station information') and names the lookup key ('by station code'). This makes the core action clear, though it does not explicitly distinguish itself from sibling tools like search_stations or list_stations.

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 phrase 'by station code' implies the tool should be used when a station code is already known, but the description never states when to choose this over search_stations, list_stations, or get_stations_of_type. Guidance is present only by implication.

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 already declare readOnly, idempotent, non-destructive, closed-world behavior, and an output schema exists, so the return shape is covered. The description adds nothing beyond the name besides the word 'all', giving no note on result size, ordering, or completeness guarantees.

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?

A single front-loaded sentence with zero waste. It is lean to the point of sparseness, but nothing is redundant or buried.

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 fully documented parameter, an output schema, and complete annotations, the mechanical requirements are covered. What is missing is sibling differentiation across ten similarly named station tools, which is the main thing an agent needs to choose 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% and the single parameter's description enumerates the six valid station-type codes (A–F). The description adds no meaning beyond the schema, 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?

States a specific verb (get) plus resource (AMeDAS stations) and the filtering dimension (station type). However, it does not distinguish itself from siblings such as list_stations or search_stations, which read similarly at a glance.

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?

There is no guidance on when to use this tool instead of list_stations, search_stations, or search_nearby_stations, and no mention of prerequisites. The agent must infer that this is the lookup-by-category path.

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 already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that observations come from the nearest station rather than the exact point — but says nothing about what happens when no station is nearby (ocean, remote areas) or how stale the reading may be.

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?

A single front-loaded sentence with no filler; the mechanism ('nearest AMeDAS station') is stated immediately after the verb. Nothing here 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?

An output schema exists, so return values need not be explained, and both parameters are schema-documented. The only real gap is the absence of edge-case behavior for coordinates with no nearby station, which matters for an open-world lookup.

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 lat and lon documented in decimal degrees, so the schema does the heavy lifting and baseline 3 applies. The description confirms the coordinates drive nearest-station resolution but adds no format, range, or precision guidance beyond the schema.

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 ('Get current weather') plus the mechanism ('nearest AMeDAS station'), which separates it from get_current_weather and get_historical_weather. It does not name those siblings explicitly, so an agent must infer the routing, but the coordinate-based scope is 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?

Usage is only implied: the required lat/lon parameters suggest 'use this when you have coordinates rather than a station ID.' There is no explicit statement of when to prefer it over get_current_weather or search_nearby_stations, nor any mention of prerequisites or coverage limits.

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 already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is fully covered. The description adds only a vague granularity hint ('over hours or days'); it says nothing about data source, latency, pagination, or limits beyond the schema's max of 168 hours. Non-contradictory but thin.

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 short sentences, purpose front-loaded, zero filler. Nothing to trim.

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?

Output schema and rich annotations relieve the description of return-value and safety duties, and the schema fully covers parameters. The remaining gap is the unresolved overlap with get_historical_weather, which an agent needs in order to pick the right tool.

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% — all three parameters are documented with defaults, examples, and constraints (10/30/60 interval, max 168 hours). The description adds no parameter meaning beyond that, 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?

States a specific verb and resource ('Get time series weather data') and scopes it to a station, which separates it from get_current_weather and get_forecast. However, it never names or contrasts with get_historical_weather, the closest sibling, so an agent must infer the boundary between 'time series' and 'historical'.

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?

'Useful for analyzing weather trends over hours or days' implies a use case but gives no explicit when-to-use/when-not, no alternative named, and no hint about how it differs from get_forecast or get_historical_weather.

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 already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered elsewhere. The word 'all' usefully signals a complete, unpaginated enumeration, but nothing else about behavior is added. With an output schema present, return-shape disclosure is not required.

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 short sentence with no filler, front-loading the verb and resource. Nothing could be removed without losing meaning.

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 enumeration with an output schema and full annotation coverage, the description is nearly sufficient. The only real gap is not naming which sibling tools consume the returned codes, which would have made the workflow chain obvious.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies the tool needs no input.

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 ('List') plus resource ('prefecture codes') and a stated purpose ('for weather forecast'). It is clearly distinct from the station- and weather-oriented siblings, though it never explicitly says so.

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?

Usage is only implied by the phrase 'for weather forecast' — an agent can infer this is a lookup to obtain codes used as input elsewhere, but there is no explicit when-to-use statement or reference to the downstream tools that consume these codes.

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 already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds the total station count (1286) and pagination behavior, which helps an agent plan iteration, but says nothing about ordering of results or what happens if limit exceeds the total.

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?

A single front-loaded sentence with zero filler; scope, count, and pagination are all stated immediately.

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?

An output schema exists and annotations cover the safety profile, so the description need not explain return values. The remaining gap is routing guidance against the many sibling search tools, which keeps it from a 5.

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 defaults documented for both limit and offset, so the schema carries the parameter burden. The description only echoes 'with pagination' and adds no syntax or bounds beyond that.

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 plus useful scope detail (all AMeDAS stations, 1286 total). The word 'all' implicitly separates it from search_stations, but no sibling is named outright, so differentiation rests on 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?

The phrase 'list all' hints that this is the unfiltered enumeration path versus search_stations or get_station_info, but no explicit when/when-not guidance or alternative is stated.

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, idempotentHint, non-destructive and closed-world annotations already covering the safety profile, the description adds essentially no behavioral context of its own: nothing about ordering by distance, maximum radius, behavior when no stations fall inside the radius, or result limits. The mention of AMeDAS as the dataset is the only added signal.

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?

A single front-loaded sentence with zero filler and the resource and scoping stated immediately. It is efficient, though so terse that the brevity edges into under-specification rather than disciplined concision.

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?

Rich annotations, an output schema, and full schema description coverage mean the agent has what it needs to invoke the tool. Still, nothing tells the agent how proximity search relates to the station-search siblings, which is the main gap for a simple three-parameter tool.

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 lat, lon and radius_km (with its default) are already fully documented in the schema. The description restates coordinate-plus-radius semantics without adding format, range, or unit nuance beyond that baseline.

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 (Search) and resource (AMeDAS stations) with the geographic scoping ('within a radius from given coordinates'). However, it does not distinguish itself from close siblings such as search_stations or list_stations, so an agent must infer that this is the proximity-based variant.

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?

There is no statement of when to use this tool versus search_stations, get_stations_of_type, or list_stations, and no prerequisites or exclusions. The only implied usage comes from the word 'nearby' and the radius parameter.

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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description usefully adds that multiple script forms are accepted, which annotations can't convey. It says nothing about whether matching is exact or partial, how many results come back, or ordering.

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?

A single front-loaded sentence with no filler, which is good. It is arguably under-specified rather than concise: the brevity comes at the cost of matching semantics and guidance rather than from tight editing.

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 an output schema present, return values needn't be explained, and annotations cover safety. Still, for a search tool the description leaves the core behavior (match type, result limits, what happens on no match) unstated, so an agent must experiment to call it confidently.

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?

Only one parameter and schema coverage is 100%, so the schema documents the input adequately and the baseline of 3 applies. The description adds value by saying the name may be Japanese, Kana, or English, but gives no detail on exact vs. partial matching or ambiguity handling.

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 (search) plus the resource (AMeDAS stations) and the matching key (name), and clarifies the accepted script forms (Japanese, Kana, English). An agent can distinguish it from list_stations or get_stations_of_type without opening 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 usage ('search by name'), which is enough to know you need a name, but it never states when to prefer this over search_nearby_stations, get_stations_of_type, or list_stations. No exclusions or alternatives are offered despite several plausible siblings.

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