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

The description goes well beyond the readOnly/openWorld annotations by disclosing that it fetches data from Open-Meteo archive, uses a lookback window, checks an extra day for streak boundary detection, and returns a status field ('ok'/'error'). This gives the agent important behavioral context about external dependencies and edge cases.

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 well-structured with clear sections for purpose, parameters, and return values, and it front-loads the core purpose. However, the return-dict listing is quite long and somewhat redundant given the output schema exists. Every sentence is informative, but the length makes it less concise than ideal.

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?

For a tool with six parameters and a rich return object, the description covers all essential aspects: algorithm, edge cases (streak_extends_beyond_window), error handling, and full return schema. The presence of an output schema does not hurt because the description adds algorithm and data-source context that a schema cannot.

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%, but the description's Parameters section provides thorough explanations for all six parameters, including units, defaults, and behavioral meaning (e.g., as_of_date determines when the streak ends, lookback_days defaults to 60 and fetches one extra day). This fully compensates for the empty schema descriptions.

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 opens with a specific verb+resource: 'Compute consecutive rain days ending on (and including) as_of_date.' This precisely states what the tool does and immediately distinguishes it from the sibling weather_history tool, which likely returns raw weather data rather than a derived streak metric.

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 clearly implies the use case (computing a rain streak for a given location and date) and explains all relevant parameters. However, it does not explicitly mention when not to use this tool or name any alternatives such as weather_history, so there are no exclusions or direct comparisons.

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?

The description adds meaningful behavioral details beyond the readOnlyHint annotation, such as 'no auth required,' calls the Open-Meteo archive API, and returns structured daily records with a 'status' field for success/error. It does not contradict the annotations and provides a good sense of the external dependency and result shape.

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 well-organized with clear sections for the summary, parameters, and return value. Every sentence serves a purpose, and the parameter list is easy to scan, making it appropriately concise despite covering many fields.

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 description is complete for a read-only weather history tool: it covers the API, parameter formats, defaults, and return structure. Even though an output schema exists, the description explains the return dict and status behavior, leaving little ambiguity for an agent invoking the 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 description provides rich semantic detail for all six parameters, including example values for latitude/longitude, YYYY-MM-DD format for dates, a list of common variable names, and the default timezone. This goes far beyond the schema, which only gives titles and types, so it fully compensates for the 0% schema description coverage.

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 begins with 'Fetch daily historical weather data for a location and date range,' which is a specific verb plus resource and scope. It clearly distinguishes itself by name ('weather_history') and by describing the exact data and API used, so the purpose is unambiguous.

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 clearly states that it fetches historical daily weather data and mentions the Open-Meteo archive API, giving clear context for when it should be used. It does not explicitly compare against alternatives or state when not to use it, but the purpose is specific enough that a user can infer when it applies.

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