Pobreza e indigencia (EPH)

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's added value is the authentication requirement ('Requiere INDEC_API_TOKEN') and the fallback-to-latest-period behavior, both of which the agent cannot infer from annotations. It stops short of describing the returned measure fields or pagination defaults, which limits it to a solid 4 rather than a 5.

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?

Every clause carries information: scope, frequency, coverage window, accepted formats, default behavior and auth. It is front-loaded with what the dataset is before moving to invocation details, with no redundant restatement of the title.

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 filtered series-read tool with seven fully documented optional parameters and no output schema, the description covers identity, coverage, formats, defaults and auth needs. The remaining gap is that it never says which measures or columns the series exposes, which matters because 'columnas' invites column selection.

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 100%, so the baseline would be 3, but the description adds dataset-specific meaning by narrowing the date syntax to 'AAAA o AAAA-N (N = semestre 1 o 2)' with an example, resolving ambiguity left by the schema's generic 'según frecuencia del dataset'. The 'columnas' selector is not illustrated with available column names, so it does not fully exploit the parameter.

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 states a specific resource (poverty and indigence incidence in households and persons), the exact population scope (total of 31 urban agglomerations), frequency (semiannual) and temporal coverage (since 2nd semester 2016), which cleanly separates it from sibling series tools like indec_ipc, indec_canastas or indec_emae. An agent can pick this over indec_query_dataset without inspecting the 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?

It gives a clear default-behavior rule — 'Sin desde/hasta devuelve el último semestre publicado' — and pins the valid period format with a concrete example ('20261S'). It does not explicitly name when to prefer the generic indec_query_dataset instead, so the routing guidance is contextual rather than exclusionary.

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