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

Annotations already declare readOnly, idempotent, and closed-world behavior, so the bar is lower. The description adds genuinely useful behavioral detail beyond that: aggregation semantics differ by variable (totals for rain/snow/precipitation hours/evapotranspiration, means otherwise) and partial years are skipped, which affects result interpretation.

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 short sentences with the core purpose front-loaded and no filler. The aggregation rule sentence is dense but each clause earns its place by preventing misinterpretation of the returned numbers.

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-value shape need not be described. However, with 0% schema coverage the definition still leaves the agent guessing at valid variable values and station format, which are the two required parameters — a meaningful gap for a tool whose whole purpose is selecting one of each.

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 0%, so the description carries the burden. It does name four variables that behave as totals and clarifies the station/variable scope, which is real added meaning, but it never enumerates valid variable names, does not explain the station identifier format, and says nothing about start_year/end_year beyond their obvious names.

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: it returns yearly values plus a linear trend per decade, scoped to one station and one variable. The 'one station' scoping implicitly distinguishes it from compare_stations, though no sibling is named explicitly.

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 'one station and variable' scope — an agent can infer this is the single-station trend tool rather than the multi-station comparison. There is no explicit when-to-use statement, no mention of alternatives like compare_stations or get_daily_weather, and no prerequisites.

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 closed-world behavior, so the safety profile is covered. The description adds genuinely non-structured behavioral context: results are aggregated across all stations and returned ordered low to high elevation, which an agent could not infer otherwise.

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 tight sentence with the core action front-loaded and no redundant padding. It is efficient, though it could have spent a few words covering the year-range parameters instead of nothing at all.

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 annotations cover safety. However, for a tool with zero schema-description coverage, the omission of any guidance on the year parameters and the 'variable' vocabulary leaves real gaps for correct invocation.

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 0%, so the description must carry all parameter meaning. It hints at the required 'variable' ('on one variable') but says nothing about start_year, end_year, their defaults, their accepted range, or the accepted variable names/formats, leaving two of three parameters undocumented.

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 ('Compare') and resource ('all stations') plus the exact computed outputs (average yearly value, trend per decade) and ordering. This separates it from list_stations and climate_trend, though it does not explicitly name a sibling to distinguish against.

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 no when-to-use context, no prerequisites, and no guidance on choosing between this and siblings like climate_trend or list_stations. Usage is only implied by the word 'compare'.

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 read-only and open-world access; the description adds real value by explaining the live-forecast pull, the scoring method against station history, the risk-level vocabulary, and the explicit caveat that this is screening not an official warning. The live-fetch wording also explains the non-idempotentHint annotation. It omits any note on auth, rate limits or data staleness.

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 summary sentence is front-loaded, and the following lines add methodology, the return vocabulary and a caveat without filler. Slightly longer than strictly required, but each sentence contributes distinct 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 structure needn't be spelled out, yet the description still enumerates the risk levels, which helps interpretation. Annotations cover the safety profile. The only notable omission is how to obtain a valid station identifier, given an undocumented string parameter.

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 0%, so the description must carry the parameters. It usefully pins the 'days' range to 1-16, which the bare integer schema does not, and anchors 'station' to 'at a station'. However it does not say what identifier format a station takes or point to list_stations as the source of valid values, leaving a real gap.

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 opening sentence names a specific verb+resource ('flash-flood screening outlook'), the scope (next 1-16 days) and the unit of analysis (at a station). It is clearly separable from siblings like get_daily_weather, rain_thresholds and climate_trend without opening either 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?

It states the tool's role ('a screening signal, not an official warning'), which implies when output should and shouldn't be acted on, but it never contrasts itself with alternatives such as get_daily_weather or rain_thresholds. Usage is inferable rather than 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond them: a hard 366-day per-call ceiling and the default column set (temperature min/max, precipitation, snowfall) when `variables` is omitted.

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 short sentences with the scope and limits front-loaded, followed by the parameter guidance and the alternative-route sentence. No filler or repetition of the tool name.

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-value documentation is unnecessary, and the description covers the remaining decision-relevant facts: scope, per-call cap, default output columns, and the multi-year alternative. Adequate for an agent to call this 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?

With 0% schema description coverage the description carries the full burden and largely meets it: it defines the date-range semantics (inclusive, YYYY-MM-DD), explains that `variables` narrows the returned columns, names the defaults, and points to list_stations for valid values. It stops short of clarifying whether `station` is an identifier from list_stations versus a free-form name, or what happens when the range exceeds 366 days.

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/scope combination: daily values, one station, bounded date range. The 366-day cap and the explicit contrast with climate_trend let an agent distinguish this from siblings such as climate_trend and list_stations without opening any 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?

"For multi-year questions use climate_trend instead" is an explicit when-not plus named alternative, and "Pass `variables` to limit columns (see list_stations)" routes the agent to the sibling that enumerates valid inputs. Nothing about when this tool is the right choice is left to inference.

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=true, idempotentHint=true and openWorldHint=false, so the safety and determinism profile is covered. The description adds which attributes are exposed per station, which is useful, but says nothing about result size, pagination or filtering limits for what could be a large station catalogue.

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 the verb and resource first and the returned attributes after; no filler and nothing 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?

With an output schema present, the description need not detail the return shape, and annotations cover the safety profile. The only gap is any hint about the volume of the result set or how it should be used downstream, which is minor for a zero-parameter listing 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?

The tool takes no parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly implies the call is unfiltered and returns the full station set.

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 ('List the weather stations') and enumerates the attributes returned (location, elevation, date coverage, variables). It is clearly a discovery/enumeration tool, but it never distinguishes itself from siblings like compare_stations or get_daily_weather that also operate on 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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of the sibling tools it complements (e.g. querying weather for a chosen station). Usage is only inferable from the tool name and the fact that it enumerates stations.

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 establish readOnly/idempotent/closed-world, and the description adds a genuinely important behavioral caveat: values reflect the ~25 km ERA5 grid cell including surrounding mountains, not valley-floor gauge readings. It also discloses the 35-year record basis. It does not cover return format, but annotations lower the bar on that.

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 definition, then the CRS/grid caveat, then the usage warning. Three tight sentences with no filler, though the colloquial 'in town' phrasing is slightly imprecise for a global tool.

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 the description covers scope, derivation window, and the grid-vs-gauge caveat well. The only real gap is the ambiguity of the single required 'station' argument.

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?

There is one parameter ('station') with 0% schema description coverage, and the description never says what identifier form it expects or where valid values come from (e.g., list_stations). With low coverage, the description was the place to compensate, and it does not.

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 resource and what it returns: percentiles of daily rain defining heavy/extreme/rare days, derived from a 35-year station record. That is far more informative than the bare name, but it does not explicitly distinguish itself from siblings like get_daily_weather, so the agent must infer the boundary.

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 intended use ('use them to judge how unusual a day is') and an explicit when-not ('not how much fell in town'), which steers the agent away from misusing thresholds as rainfall totals. It stops short of naming an alternative tool for actual amounts, so it is not fully prescriptive.

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