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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that no API key is required, data is open via Bright Sky (MIT licence), and details the data fields per hour and the 10-day/240-record limit. This goes beyond the annotations to set expectations about data scope and availability.

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, well-structured paragraph. It front-loads the primary action, then explains the conditional behavior, followed by data fields and limits. Every sentence provides essential information without redundancy or fluff, though it is slightly long.

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 does not need to detail return formats. It covers the core usage (past/future dates), geographic scope (Germany), data content (per-hour fields), maximum range (10 days/240 hours), and access requirements (no API key). An agent can call this tool correctly with the given information. Minor lack of explicit examples or error conditions prevents 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%—all five parameters have descriptions, including the date field's past/future behavior and unit options. The description adds contextual details like the 10-day range and hourly record count, but these relate to overall behavior rather than clarifying individual parameters. Since the schema already carries the parameter semantics, a baseline of 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 clearly states the tool gets hourly weather observations or forecasts for any location in Germany, sourced from DWD. It explicitly explains that past dates yield historical observations and future dates yield forecasts, distinguishing it from siblings like brightsky.weather.current which provides current conditions.

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 clearly specified: pass a past date for history, future date for forecast, and the tool returns up to 10 days of data (240 hourly records). It doesn't explicitly name alternatives like brightsky.weather.current, but the past/future distinction and hourly focus make when to use this tool clear. A more explicit 'when not to use' would elevate it to 5.

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