Weather values for a location

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

Goes well beyond the readOnly/openWorld annotations by disclosing the cost model, the authentication prerequisite, the row-limit behavior (series over 400 rows are summarised by year and written to CSV rather than listed), and that results include a per-variable summary. These are exactly the facts an agent needs before spending credits.

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 sentences, each load-bearing, with the scope statement front-loaded and the cost/auth caveats following in the order an agent would need them. No filler or restatement 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?

With nine parameters and no output schema, the description does well to describe return shape (per-variable summary, CSV fallback for long series) and the paid-tier gate. It could say more about what happens when confirm_credits is required but false, but nothing essential to a correct call is missing.

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 already 100%, and the description still adds meaning: the cost formula ties directly to time_scale and variables, and the 1961 floor bounds start/dates. It stops short of explaining the confirm_credits threshold workflow beyond the schema's own text, so it sits modestly above 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?

Opens with a precise statement of what is returned: temporal resolution (daily/monthly/annual), a single location, one or more variables, and the 1961-to-present coverage window. That cleanly separates it from get_climate_normals and the file-download siblings, 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?

Gives concrete operational context for choosing this tool: monthly/annual is free, daily costs 1 credit per day per variable and requires an account or API key in server config. It does not explicitly say when to prefer this over request_point_history or get_climate_normals, so alternatives remain unaddressed.

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