Clima en Salto Grande (INIA)

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

The annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description adds real context beyond them, including the 1971-2025 normal used as the anomaly baseline, the 400-day cap, the degrees-Celsius-per-decade unit, and the standard error returned with the trend. It does not discuss rate limits or data gaps, but for a read-only series endpoint it does more than the structured fields.

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, no filler: the source and series identity is front-loaded, then the no-dates mode, then the dated mode with its format and limit. Each clause constrains behavior or output.

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 values need not be spelled out; the description still defines both result shapes (trend plus standard error; daily values plus anomaly) and the constraints that determine which one is produced. Nothing an agent needs to call this correctly is absent.

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 0%, so the description carries the full burden and meets it: it names both parameters, gives the date format (AAAA-MM-DD), the range constraint (hasta 400 días), and the mutual requirement that both dates are supplied or neither. The empty-string defaults and the both-or-neither rule are thereby reconciled instead of left ambiguous.

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 names a specific resource (climate at the INIA Salto Grande station, series since 1970) and explicitly distinguishes the two operating modes: a trend of annual mean temperature with its standard error, and daily rainfall and maximum/minimum temperatures. An agent can tell exactly what the tool returns without opening a 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?

The condition that selects each mode is stated explicitly: 'Sin fechas' versus 'Con `desde` y `hasta`', and the caller is told 'Se pasan las dos fechas o ninguna'. What is missing is a pointer to the sibling weather tool (observaciones_inumet), so the agent is not told when to prefer this station series over that alternative.

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