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.

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so safety is covered. Beyond that, the description adds two things the annotations do not: the requirement for an INDEC_API_TOKEN and the accent-insensitive matching behavior. It does not clarify how 'texto' and 'codigo' interact if both are supplied, which is the remaining behavioral gap.

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 sentences, both earning their place: the first states scope and search modes, the second gives the concrete use case plus the auth requirement. No filler or repetition 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?

With no output schema, the description could have said more about what a match list looks like or what happens on multiple fuzzy hits, and it doesn't state whether both search parameters may be combined. For a four-parameter lookup tool with an enum-constrained type filter, though, the description covers enough to call it correctly.

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 75%, with 'tipo', 'texto' and 'codigo' documented but 'limit' not; the description adds that matching is accent-insensitive, which the schema does not say. It also frames 'texto' and 'codigo' as alternative lookup modes, though it leaves precedence unspecified when both are provided.

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 verb and resource ('Busca en el diccionario de comercio exterior') and enumerates exactly which dictionaries are covered (países, rubros, subrubros, usos económicos, GCE). The translation examples ('Brasil' → código de país, código → nombre) make the resource unmistakable against the sibling tools, which all query datasets rather than a code dictionary.

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 states the concrete situation that selects this tool — resolving a name to a code or a code to a name — which is clear usage context. It gives no explicit when-not-to-use or named alternative, but the dictionary-lookup framing is sufficiently distinct from the dataset-query siblings that an agent can route correctly.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new context: the INDEC_API_TOKEN requirement, the default of returning only the latest period when no range is supplied, and the different data start dates for the two basket families.

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 is front-loaded with the resource and its scope, followed by the default behavior and the auth requirement; it is dense but every clause carries information, with only slight compression cost in the long opening sentence.

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 nine-parameter, read-only query tool with no output schema, the description covers scope, defaults and auth adequately, though it could say more about what a returned row contains or how pagination fields behave.

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 parameters are already well documented; the description only reinforces the desde/hasta default and implicitly distinguishes the canasta values by their coverage periods, adding little beyond the schema text.

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 the exact indicators (Canasta Básica Alimentaria and Total for GBA, per adult equivalent and per household type since 2016, plus the crianza basket by age bracket since 2020) with their variations, which is specific enough to separate it from siblings like indec_ipc or indec_pobreza 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?

It gives a useful default behavior ('Sin desde/hasta devuelve el último mes') and the auth prerequisite, but never says when to pick this tool over sibling indicator tools or when the crianza basket is the appropriate choice.

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

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

Annotations already declare this a safe, idempotent read, and the description adds genuinely non-obvious behavior: an INDEC_API_TOKEN is required, confidential rows marked 's' are excluded from sums and reported, and agrupar_por changes the return shape from raw rows to named totals. Those are exactly the operational facts an agent could not infer from 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?

Front-loaded with the resource and units (USD, kg) before the filtering, aggregation, date-default and auth clauses; no filler sentences. It is a single dense block, so the auth requirement and the confidential-data caveat are easy to skim past, costing it the top mark.

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 13-parameter read tool with no output schema, it covers the essentials: units, defaults, aggregation semantics, auth, and the confidentiality quirk. Pagination mechanics (siguiente_offset) and the exact response envelope are not described, though the offset parameter hints at them.

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 92%, so the baseline is 3; the description earns above that by stating the cross-parameter constraint the schema cannot express — rubro/subrubro apply only to exports, gce/uso_economico only to imports — and by explaining what agrupar_por actually computes (suma de valor y peso, excluding confidential rows). Date formats and pagination are left to the schema, which already documents them.

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 the specific resource (exports FOB / imports CIF, monthly since 1986) and the dimensions each flow supports (rubros/subrubros vs. usos económicos/gran categoría), so an agent knows exactly what dataset it gets. It is clearly distinguishable from the topical sibling tools (indec_ipc, inde_emae, inde_salarios).

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 states when the tool applies (exports vs. imports), how to filter by name against the dictionary, that agrupar_por yields aggregated totals instead of raw rows, and that missing desde/hasta default to the last month. What it does not do is route the agent away from overlapping generic siblings (indec_query_dataset, inde_aggregate) when a hand-rolled query would be preferred.

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

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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value stands out: it discloses the auth requirement (INDEC_API_TOKEN) and a real behavioral trait, that the result is an exact total computed without transferring row data. It does not cover failure modes or rate limits, which keeps it out of the top band.

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 sentences with no filler, and the core promise (exact row total without data) is front-loaded ahead of the token requirement. Every clause carries information the agent needs.

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 two-parameter count tool whose annotations fully cover safety and whose schema enumerates datasets and operators, the definition supplies the missing auth prerequisite and the no-data-transfer behavior. The only real hole is filter-combination semantics, which matters when the optional filters array is populated.

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 schema is self-documenting for much of the surface (a 19-value dataset enum, per-op descriptions of eq/neq/like/in/is, and a column note pointing at indec_describe_dataset), so the baseline is 3. The description only adds "opcionalmente filtrado", confirming that filters affect the count, but says nothing about how multiple filter entries combine (AND vs OR) or how the nested filters array is shaped.

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?

"Devuelve el total exacto de filas de un dataset (opcionalmente filtrado) sin traer datos" states a specific verb (count) and resource (rows of a dataset), and the trailing "sin traer datos" separates it functionally from a data-fetching sibling like indec_query_dataset. It stops short of naming that sibling, so the differentiation is implied rather than explicit.

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 phrase "sin traer datos" hints at the situation where this is preferable to a full query, but the description never says when to use it versus indec_query_dataset or indec_aggregate. There are no exclusions or prerequisites beyond the token requirement, so the agent must infer the selection rule.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond them by stating 'No requiere token', which tells the agent no authentication step is needed before calling. It stops short of describing response shape or error behavior, which keeps it at a 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?

Two sentences, front-loaded with the return contents and followed by the routing instruction. Every clause carries information: what comes back, when to call it, and that no token is required.

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?

With no output schema, the description correctly takes on the burden of explaining return values and does so concretely (columns, ordering key, frequency). For a one-parameter enum tool this is nearly sufficient; only the response structure and error handling for an invalid dataset are left unstated, a minor 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 description coverage is 0%, so the description would normally have to carry the parameter meaning. It only says the tool operates 'de un dataset', adding minimal semantics beyond the parameter name; however, the single parameter is a fully enumerated list of 19 dataset identifiers, which is largely self-documenting. Baseline 3 is appropriate given the enum does most of the work.

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 verb (devuelve) and enumerates exactly what is returned: column names with type and meaning, the sort key for pagination, and the dataset frequency. It is immediately distinguishable from siblings like indec_query_dataset or indec_list_datasets because it is the schema/metadata inspection tool.

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 an explicit sequencing rule: call this before building filters with indec_query_dataset, naming the concrete alternative it complements. That is a real when-to-use instruction rather than an implied one, and it leaves little room for the agent to pick the wrong sibling first.

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

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

Annotations already cover read-only, idempotent and non-destructive, so the bar is lower, yet the description adds real context: the default scoping to the latest period (where categories are usually complete), the row-scan cap under all_periods, and the INDEC_API_TOKEN requirement. It does not describe the return shape (ordering, deduplication) or what happens when max_rows truncates results.

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 compact sentences with zero waste: purpose and use case first, then the default-vs-all_periods behavior, then the auth requirement. Front-loaded and easy to scan.

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 5-parameter tool with no output schema and low schema coverage, the description covers scoping, row limits and auth but omits how filters interact with the distinct-value computation and what the result looks like. Adequate to call correctly in the common case, incomplete for the parameterized cases.

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 description coverage is only 20% across 5 parameters, so the description must compensate. It does explain the interaction of all_periods and max_rows and the default period behavior, but says nothing about filters (the most semantically complex parameter) or the dataset/column pairing beyond what the schema enum and field descriptions already provide.

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 verb and resource: list distinct values of a column, plus a concrete use case (discovering regiones, rubros, sectores before filtering). That distinguishes it implicitly from indec_query_dataset, indec_aggregate and indec_describe_dataset, though no sibling is named.

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 clear when-to-use guidance ('útil para descubrir ... antes de filtrar') and explains the two operating modes (default: last period only; all_periods=true: scan up to max_rows). No explicit exclusions or pointers to the alternative tools for other exploration needs.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds real value with the INDEC_API_TOKEN authentication requirement and the default-latest-month behavior, but it says nothing about response shape, pagination mechanics, or rate limits, and there is no output schema to compensate.

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 tight sentences, front-loaded with the dataset identity and base year, then the two modes, then the default and auth requirement. Telegraphic phrasing is dense but every clause carries information; no filler.

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 an 11-parameter, zero-required read tool with no output schema, the description covers the essentials: dataset vintage, the two access modes, default behavior, and credentials. Remaining gaps — pagination flow and return-field listing — are partly handled by the offset and columnas schema descriptions.

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 91%, so the baseline would be 3, but the description genuinely adds meaning: it explains that nivel selects between two different result sets and which series each contains, and clarifies the variación semantics (monthly/interannual depending on series). The desde/hasta default behavior is echoed rather than extended, keeping it from a 5.

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 the specific dataset (EMAE, base 2004=100) and states exactly what each mode returns: nivel='general' gives serie original, desestacionalizada and tendencia-ciclo with índice and variaciones, while nivel='sectores' gives activity-sector series. This lets an agent distinguish it from dataset-generic siblings like indec_query_dataset, though it never explicitly says to prefer this tool over those.

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 operating conditions: which nivel values exist and what each contains, that omitting desde/hasta returns only the latest month, and that an API token is required. It stops short of explicit when-to-use vs alternatives (e.g., versus indec_query_dataset or indec_ipi), so routing between siblings remains inferred.

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

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

Beyond the read-only/idempotent annotations, the description discloses the default behavior without date bounds, the historical starting point, the base period, and the API token requirement. It does not cover rate limits, error behavior, or pagination details beyond what the schema already states.

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 is short and front-loaded: purpose and scope first, then default behavior, then an example, then authentication. Every sentence carries useful information and there is no fluff.

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 ten-parameter but fully optional and fully documented schema, the description covers the essential context: what the data is, its temporal coverage, default behavior, a representative example, and the token requirement. It is not fully complete because it does not describe the returned row shape or output fields beyond what the schema implies.

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 already 100%, so the baseline is 3. The description adds meaningful context by explaining the default no-date behavior and giving an example parameter combination for national monthly inflation, which helps an agent map real queries onto the parameters.

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 and scope: IPC inflation data with regional, level, and category breakdowns since Dec-2016. It is clear what the tool returns, but it does not explicitly contrast itself with generic siblings such as indec_query_dataset or indec_describe_dataset.

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 useful usage cue by explaining that omitting desde/hasta returns the latest published month, and it includes a concrete example query. However, it does not explicitly say when to use this tool instead of the generic dataset query siblings or when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the INDEC_API_TOKEN requirement and the default last-period behavior, but it says nothing about pagination flow, rate limits, or response size, which matter for a 10-parameter open-world data tool.

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 compact sentences, front-loaded with the dataset identity and variants, then the default-range rule and the auth requirement. The base-year parentheticals are dense but each carries selection-relevant information; no filler sentences.

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?

Covers dataset identity, defaults, and auth, which is most of what an agent needs for a filtered time-series query. But with no output schema, the description never says what comes back (rows, columns, siguiente_offset for paging) — that paging detail only leaks through the offset parameter description — and the generic-vs-specific sibling choice is left unaddressed.

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 80%, so the baseline is 3, and the description earns an extra point by explaining the base-year switch tied to the rama enum and the series options — both of which the schema lists as bare enums without descriptions. It still adds nothing about actividad, columnas, or how tipo interacts with rama (unidades_fisicas only in minero is only noted in the schema).

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 the specific dataset (IPI manufacturero base 2004=100 desde 2016; minero base 2016=100 desde 2017) and the three series variants, which is far more specific than a tautology and implicitly separates it from siblings like indec_ipc or indec_emae. It never states an explicit action verb (list/query/fetch) and never disambiguates from the generic indec_query_dataset, so it is clear but not fully differentiated.

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 one genuinely useful usage rule: omitting desde/hasta returns only the latest month, which tells the agent how to get a snapshot. However, it offers no guidance on when to choose this tool over the generic indec_query_dataset/indec_aggregate siblings, and no note on which rama/serie combinations are valid together.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: no token required and no data consultation, plus the shape of the returned catalog entries (which matters since there is no output schema).

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 short sentences, front-loaded with what the tool returns and followed by the entry-point guidance and the no-token/no-data caveats. Nothing is redundant with the title or wasted.

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?

With no output schema, the description compensates by listing the catalog fields returned, and it clarifies the auth-free, read-only nature of the call. For a one-optional-parameter listing tool, an agent has everything needed to call it correctly.

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 description coverage is 100% and the single optional 'area' parameter is well documented in the schema itself, so the baseline is 3. The description never mentions filtering by area and adds no syntax or matching-behavior detail beyond what the schema provides.

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 verb and resource ('Lista el catálogo de los datasets de la API del INDEC') and even enumerates the returned fields (id, área, frecuencia, resumen). The phrase 'No consulta datos' separates it cleanly from siblings like indec_query_dataset and indec_describe_dataset.

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?

'Empezá por acá para saber qué datos existen' gives an explicit entry-point instruction, and 'No consulta datos' implicitly steers the agent away from using it to fetch values. It stops short of naming which sibling to use for actual data retrieval, so the routing is clear but not complete.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond them by disclosing the default window (last published quarter when no range is given) and the authentication requirement (INDEC_API_TOKEN). It does not describe the response shape or row layout, which keeps it from 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?

Four compact sentences, front-loaded with the data scope before the filtering and default rules. Nothing is padded. The odd '20262T' period example is the one spot that costs a moment of decoding.

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 7-parameter, zero-required, read-only dataset tool with no output schema, the description covers scope, temporal coverage, accepted formats, default behavior and auth. What is missing is any indication of what a returned row contains — relevant since no output schema exists and 'columnas' takes arbitrary strings the agent cannot know in advance.

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 description coverage is 100%, so the baseline is 3. The description does add the key incremental detail that desde/hasta accept 'AAAA' or 'AAAA-N' with N as the quarter number, and gives the period example '20262T' — though this example format does not obviously match the 'AAAA-N' notation, and it is not stated for area, columnas, limit or offset. Net value over the schema is real but narrow.

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 enumerates exactly what this tool returns: activity, employment, formal/informal employment, unemployment and underemployment rates for the 31 agglomerations, quarterly from Q2 2016. That is specific enough to tell it apart from the other dataset-specific siblings (indec_ipc, inde_emae, inde_pobreza). It lacks an explicit action verb, but the resource scope is unambiguous.

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 through the filtering behavior ('Sin desde/hasta devuelve el último trimestre publicado'), which tells the agent what happens by default. However, it never says when to pick this tool over the generic inde_query_dataset / inde_describe_dataset siblings, nor any exclusions. The agent must infer the choice from the dataset subject matter alone.

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

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

Annotations already declare a safe, idempotent, read-only operation, so the bar is lower; the description still adds two non-obvious behaviors: the API token requirement ('Requiere INDEC_API_TOKEN') and the default of returning the current year clamped to the dataset range when desde/hasta are omitted. It does not mention rate limits or response shape, so it is not exhaustive.

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 measure definition is front-loaded, followed by level options, temporal defaults, and the auth requirement — every sentence carries information. The parenthetical enumeration is dense but functional; nothing is redundant.

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 an 11-parameter tool with no output schema, the description covers data semantics, level granularity, defaults, and authentication well. It omits anything about the returned row shape or pagination contract (only the offset schema field alludes to 'siguiente_offset'), which matters since no output schema exists to carry that burden.

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 description coverage is already 91%, giving a baseline of 3, but the description adds real meaning beyond the enum: it explains which dimensions each nivel value returns and its differing year coverage, and clarifies that desde/hasta are years (the schema only gives generic AAAA/AAAA-MM formats). Evidence: 'nivel="nacional" (por sexo y edad simple, 2022–2040)'.

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 the exact measure ('Población al 1.º de julio de cada año') and enumerates the three geographic levels with their respective dimensions and year ranges, so an agent knows precisely what dataset it retrieves. It does not contrast itself with generic siblings such as indec_query_dataset or indec_aggregate, so sibling differentiation is left implicit.

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 through the nivel enumeration (nacional = simple ages, jurisdiccion = quinquenal groups, departamento = 2022–2035) and the default time-window rule, which effectively guides level selection. However, there is no statement of when to prefer this tool over the generic query/aggregate siblings, nor any exclusion criteria.

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

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.

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 context: the historical boundary of the data (desde dic-2015), the default single-period fallback when no range is given, and the INDEC_API_TOKEN requirement. It does not describe the shape of the returned rows (pagination fields, siguiente_offset), but the annotations carry most of the remaining burden.

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 tight sentences: scope and content first, default behavior second, auth requirement last. Every clause carries information and nothing is repeated.

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 read-only query tool with full schema coverage, no required params and no output schema, the description gives the essential induction: what the indices are, the temporal floor, the default window, and the token requirement. The remaining gap is result-shape/pagination behavior, which the schema partly covers via offset's 'usar siguiente_offset' note.

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%, with enums for tipo and orden fully documented in-schema, so the baseline is 3. The description adds no semantics the schema lacks — it echoes the 'all types' and 'last month if no range' behavior that 'tipo' and 'desde/hasta' already state — and says nothing about limit/offset/columnas usage.

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 the specific resource (INDEC wholesale price index system: IPIM, IPIB, IPP) and what it returns (index levels, variations, incidences) with an explicit coverage window (since Dec-2015). That is well beyond a restatement of the name, but it never explicitly contrasts itself with sibling indec_ipc (consumer prices) or indec_ipi, leaving the agent to infer the wholesale-vs-consumer split.

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 one useful behavioral rule of thumb ('Sin desde/hasta devuelve el último mes') and states the auth prerequisite, which implicitly tells the agent this is a ready-to-call data query. It still offers no when-to-use/when-not guidance against the many siblings (indec_ipc, indec_ipi, indec_query_dataset) that an agent must disambiguate between.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real behavior beyond that: a 1000-row page cap, automatic ordering by the full primary key when order is omitted (for stable pagination), and the exact-total behavior of count=true. It stops short of rate limits or error behavior, which keeps it from 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?

Four short sentences, each carrying distinct information: capabilities, page cap, ordering default, count behavior, auth requirement. The pagination constraint is front-loaded and there is no redundant restatement of the name.

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 7-parameter, open-world read tool with no output schema and partial schema coverage, the description covers pagination, ordering and auth but omits the discovery path (listing datasets, describing columns referenced by the schema's filter/column field). An agent can invoke it, but must look elsewhere to learn how to find valid dataset/column values.

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 only 43%, so several parameters (limit, offset, order.dir) arrive undocumented from the schema. The description compensates for part of that gap by explaining the 1000-row page maximum, the primary-key ordering default and count=true, but offset semantics and multi-column ordering remain unaddressed.

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 verb and resource ("Consulta cualquier dataset") plus the capabilities it bundles: select, filters, order, pagination. It is clear what the tool does generically, but it never names or contrasts with siblings such as indec_aggregate, indec_distinct_values or the topic-specific shortcuts (indec_ipc, indec_pobreza), so differentiation is left implicit.

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?

No when-to-use guidance is given: nothing says to prefer this over indec_aggregate for grouping or indec_list_datasets/indec_describe_dataset to discover datasets and column names. The one routing-relevant statement, that count=true returns the exact total, actually overlaps with the sibling indec_count_rows without clarifying which to pick.

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

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 genuinely useful context beyond them: the INDEC_API_TOKEN auth requirement and the default last-available-month behavior. It goes no further, though — nothing about pagination semantics, response shape, or rate limits.

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 tight sentences, front-loaded with what the index covers and its base period, followed by the default behavior and auth requirement. No filler; only the parenthetical format details risk feeling compressed.

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 an 8-parameter, all-optional read tool with 100% schema coverage and no output schema, the description supplies the two things the schema cannot: the data's temporal extent and the token prerequisite. What remains thin is routing guidance relative to the many sibling INDEC tools, which would complete the picture.

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 description coverage is 100%, and the enum/format details for tipo, desde, hasta, limit, orden, offset and columnas are already fully documented there. The description contributes only the temporal coverage window ('desde nov-2015') and restates the no-range default already present in the desde/hasta schema text, so it adds little beyond the schema.

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 resource and scope: the salary index by sector (registered private, unregistered, public) with variations, plus the index base (oct-2016=100). An agent can tell this is the domain-specific salary series, distinct from indec_ipc or indec_emae, though it never explicitly names a sibling to distinguish itself from indec_query_dataset.

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?

Implies usage through the default-behavior note ('Sin desde/hasta devuelve el último mes') and the auth prerequisite, so an agent knows it can call it bare for the latest month. However there is no explicit when-to-use versus indec_query_dataset or indec_aggregate, and no exclusions or guidance on combining tipo values.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety bar is low. The description still adds real context: no token is needed, the API is in BETA, and the tool compares the live public spec against the server's pinned version — behavior an agent could not infer from the annotations.

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?

A single dense sentence that front-loads the three reported facts before the caveats. The nested parenthetical about BETA status interrupts the flow slightly, but nothing is redundant.

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?

With no output schema, the description must convey what comes back, and it does enumerate the three return facets (token present, base URL, spec-drift flag). It does not describe the response shape or the drift field's type, a minor gap for a simple diagnostic tool.

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 tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming no token is required. Baseline 4 applies.

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 verb and resource: reports token configuration, base URL, and whether the public INDEC API spec has drifted from the one this server uses. The diagnostic/status purpose is unambiguous and clearly distinct from the data-query siblings, though no sibling is named explicitly.

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 only implied — an agent can infer this is a health/preflight check, but the description never says when to call it (e.g. before querying, on auth errors) or when not to. The 'No requiere token' note hints it is safe to call unauthenticated, which is useful but not a usage rule.

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