get_daily_weather

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.