Get historical weather

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core behavior (daily historical observations, source archive, age of data) but does not mention response format, units, pagination, or any potential limitations. While not misleading, it is sparse. For a simple read-only tool, this is adequate but not thorough, justifying a 3.

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 with zero fluff. It front-loads the purpose ('Daily historical observations') and then provides a practical usage tip about finding station IDs. Every word earns its place; this is ideal conciseness.

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?

The tool is simple (4 params, no nested objects, no output schema). The description covers the core purpose and points to the sibling tool for station IDs, but it does not describe what the response looks like beyond 'observations'. Since there is no output schema, the agent must infer the return structure. Given the elements parameter and defaults, the response likely includes temperature, precipitation, and wind, but this is not explicitly stated. The description is adequate but could be more complete with a hint about the returned data shape.

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 all four parameters documented. The description adds only the suggestion to 'Find station ids with find_weather_stations', which essentially repeats the schema's hint for station_id. No additional meaning is added for 'from', 'to', or 'elements'. As per baseline, when schema covers everything, a 3 is appropriate since description adds minimal extra value.

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 clearly states 'Daily historical observations from a weather station', which is a specific verb+resource. It distinguishes from siblings like get_forecast and get_nowcast by emphasizing 'historical', and mentions the Frost archive for context. An agent can immediately tell this is the historical data tool vs. the forecast or nowcast ones.

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 clear context that this tool is for historical data, differentiating it from forecast/nowcast tools. It also explicitly instructs to find station ids via find_weather_stations, which is an alternative for obtaining a required parameter. However, it does not explicitly state when NOT to use this tool (e.g., 'use get_forecast for future data'), but the historical label is clear enough. So it has clear context but no explicit exclusions.

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