Costo de la construcción (ICC) y redeterminación de obras públicas

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real value beyond that: the required auth token and the default no-range behavior of returning only the latest month, both of which affect how an agent must call it.

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?

Two dense sentences with zero filler: dataset identity and legal basis first, then the no-range default and the auth requirement. Legal citations (Decretos 1295/2002 and 634/2003) are compact identifiers that help an agent confirm the correct redeterminación dataset.

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 9-parameter, zero-required read tool with no output schema, the description covers purpose, dataset coverage window, default behavior and auth. It leaves response shape and column naming to the schema, and only lightly explains how 'fuente' switches between the two datasets, which is the one real gap.

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 89%, so nearly every parameter is already documented in the schema, including the tipo enum, date formats and pagination. The description adds marginally by tying 'aperturas' to the descripcion parameter and by stating the dataset's temporal scope (base 1993, nov-2015 onward), but it does not explain the icc vs. redeterminacion distinction at the parameter level.

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?

Names a specific resource (ICC del GBA, base 1993, desde nov-2015) and the second dataset mode (aperturas ICC/IPIB para redeterminación de precios de obra pública), so an agent knows exactly which data this returns. It does not mention any sibling tool, so it does not explicitly steer an agent away from indec_query_dataset or indec_ipc, which appear to overlap.

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 implied by the domain scoping: use this for ICC/redeterminación series rather than the generic dataset tools. It also states a concrete behavioral rule ('Sin desde/hasta devuelve el último mes') and a prerequisite ('Requiere INDEC_API_TOKEN'), but never names an alternative tool or an explicit when-not-to-use condition.

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