Agregar datos (suma, promedio, mín., máx., conteo)

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: rows are pulled with pagination in batches of 1000 up to max_rows and aggregation happens client-side, and access requires INDEC_API_TOKEN. It does not describe the shape of the returned aggregate rows.

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?

Four sentences, front-loaded with the fetch-then-group mechanism before use cases and the statistical caveat. Each sentence carries information; only the first sentence is slightly padded with redundant phrasing ('Trae las filas que cumplen el filtro ... y las agrupa localmente').

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?

Treating this as a 7-parameter read with no output schema, the description covers the core mechanics, the auth requirement and the main misuse trap, which is enough to call it correctly. What's missing is the agg enum semantics and a hint at the returned grouped-result structure.

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?

At 57% schema coverage the schema already documents group_by, max_rows, max_groups, value_column and the filter op/column fields. The description reinforces max_rows ('hasta max_rows, paginando de a 1000') and constrains value_column to magnitudes rather than indices/rates, but adds nothing about the agg enum values, their default, or max_groups ordering.

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?

States a specific mechanism: fetches rows matching the filter and groups them locally by one or more columns, which separates it from a plain row-returning query. It never names the sibling it supersedes (indec_query_dataset) or that indec_count_rows is the cheaper option for counts, so differentiation is inferred rather than stated.

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 when-to-use examples ('exportaciones por año', 'población por jurisdicción') and an explicit when-not: do not sum indices or rates, only magnitudes (USD, kg, habitantes). It also flags the INDEC_API_TOKEN prerequisite. It stops short of routing between siblings such as indec_query_dataset, indec_count_rows or indec_distinct_values.

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