enaho_rastrear_variable

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: it warns about meaning changes, states what it returns (years, labels, gaps, alerts), and explains the underlying data issue. No contradiction, and the additional context goes beyond the simple read-only flag.

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 consists of three sentences, each with a clear role: function, when to use with rationale, and output summary. No redundant information exists; every sentence earns its place. It is appropriately sized and front-loaded.

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 contextualized well: it addresses the ENAHO time-series error, explains the problem, and states what the tool returns. With annotations and an output schema present, the description need not over-explain. Minor lack of parameter detail slightly reduces completeness.

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 makes no reference to parameters; it only mentions 'variable' in a general sense. Schema coverage is 50% (encuesta and variable have descriptions, anio_min/max do not), and the description does not compensate by adding semantic meaning for the optional year parameters. This is a notable gap.

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's function: 'Sigue una variable ola por ola y avisa si cambio de significado' (follows a variable wave by wave and warns if its meaning changed). This is a specific verb+resource that distinguishes it from siblings like enaho_serie or enaho_buscar_variable, emphasizing its unique role as a pre-time-series consistency check.

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 explicitly says 'Usala ANTES de construir cualquier serie de tiempo' (use it BEFORE building any time series) and explains the risk of variable code recycling. This provides clear when-to-use context without naming alternatives or when-not-to-use, so it falls just short of full explicitness.

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