INDEC Argentina (no oficial)

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

Annotations already declare read-only, idempotent, closed-world, non-destructive behavior, so the bar is lower. The description still adds real context beyond them: the data only covers Gran Buenos Aires, begins in abr-2016 for baskets and 2020 for crianza, and returns variations alongside levels.

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 resource and then the alternative mode; nothing is redundant padding. It is slightly run-on with the 'o la canasta de crianza' clause, but every element carries information.

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 read-only, parameter-light tool with a full output schema, the description covers both data modes, the geographic scope and the temporal coverage, which is what an agent needs to call it correctly. The only gap is routing guidance against the 'poverty' sibling, which is a usage-guideline concern rather than a completeness failure.

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 schema already documents all four parameters, including the CBT/CBA/crianza values and the age_group tramos. The description restates the same basket semantics (CBT = poverty line, CBA = indigency line, crianza = cost of raising a child) without adding format or constraint detail beyond the schema, so the baseline 3 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?

The description names a specific resource — the peso value of the Gran Buenos Aires basic food/total baskets (CBA/CBT) and the 'crianza' basket — with its geographic scope and start dates (abr-2016, 2020). An agent can tell it apart from generic siblings, though it never states a verb (fetch/return) and does not contrast itself with the closely related 'poverty' 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?

Usage is only implied: by equating CBT with the poverty line and CBA with the indigency line, it hints when each basket variant is appropriate. There is no explicit when-to-use, no when-not-to-use, and no reference to the sibling 'poverty' tool that an agent might otherwise 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 establish readOnly/idempotent/non-destructive, so the description only needs to add context, which it does: it discloses that comparison is restricted to intersecting months and that the summary reports first-to-last variation, plus relative variation when exactly two series are supplied. The instruction "El resumen es CALCULADO: decilo al usarlo" is a genuinely useful behavioral disclosure about the derived nature of the output, though return-format detail is partly redundant with the existing 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 front-loaded sentences: purpose and scenarios first, then return behavior, then the caveat about the computed summary. Nothing is padded, though the return-behavior clause overlaps with what the output schema already conveys.

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 rich annotations, 100% schema coverage, and an output schema, the description supplies exactly the missing pieces: the shared-month alignment rule and the computed-summary caveat. An agent can call this tool correctly without consulting anything else.

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 schema already documents series syntax, enums of measure values, and the 'AAAA-MM' date format. The description adds only the semantic of intersecting months and the relative-variation rule tied to series count; it does not restate or extend parameter meanings beyond that.

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 ("Compara series mensuales en los meses que tienen en común") and enumerates concrete comparison scenarios (salarios vs inflación, canasta vs salarios, IPC por región, actividad vs precios), making the tool's scope unambiguous. It does not explicitly name which sibling to use for a single series (e.g. inflation_series, wages), so differentiation is inferred from the multi-series framing 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?

The use-case list gives clear context for when this tool is the right choice: cross-referencing two or more monthly series over their shared months. There is no explicit exclusion or pointer to alternatives for the single-series case, and the 2-to-4 series limit is only visible in the schema, not the description.

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 read-only, idempotent, closed-world query, so safety behavior is covered. The description adds real context beyond them by stating the series starts in nov-2015, which tells the agent the earliest valid range. It does not mention update cadence or that defaults fall back to the last 13 months, though the schema covers the latter.

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 front-loaded sentence that identifies the index, its geographic scope, its start date, and its breakdowns with no filler. The long trailing list is dense but each item corresponds to a real queryable dimension.

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 an output schema present and full parameter documentation, the description only needs to frame the dataset, which it does by naming scope, start date, and available breakdowns. Minor gaps remain (data publisher, monthly frequency) but nothing an agent needs to call it correctly is missing.

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 all four parameters are already documented with formats and defaults. The description's enumeration of categories loosely reinforces valid 'category' values, but the schema already gives concrete examples ('Albañilería', 'Pintura'), so little is added beyond the baseline.

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 index (ICC for Gran Buenos Aires) and enumerates the breakdowns it returns (nivel general, materiales, mano de obra, gastos generales, ítems de obra, materiales por producto), so an agent knows exactly what data comes back. It does not explicitly contrast itself with near-neighbors such as inflation_series or wholesale_prices, which is the only thing keeping it from a 5.

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?

There is no when-to-use guidance at all: nothing says to pick this over inflation_series, wholesale_prices, or compare_series when the question involves construction input costs. Usage is only inferable from the topic name.

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 closed-world, so safety needs no restating. The description adds genuinely useful behavior beyond them: the schema exposes exact text-dimension values that are case-sensitive and must be pasted verbatim into SQL filters — a real gotcha an agent would otherwise hit.

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 what is returned, then the workflow constraint. The parenthetical about case sensitivity is dense but earns its place; the enumeration of returned fields is slightly list-heavy but not wasteful.

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 simple — one required parameter and an output schema that already documents the return shape — and the description still covers content, a case-sensitivity caveat, and its place in the query workflow. Nothing an agent needs in order to call it correctly is missing.

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?

There is a single parameter with 100% schema description coverage, and the schema already ties it to `list_datasets` with an example. The description adds nothing about the `table` argument, so the schema-only baseline of 3 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?

The description names a specific resource (a dataset's schema) and enumerates its contents: description, primary key, typed columns with meaning, exact text-dimension values, and sample rows. An agent can distinguish it from list_datasets (catalog listing) and query_sql (execution) without opening any 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 an explicit ordering rule: call this before writing `query_sql`. The alternative it gates is named directly, so the agent knows both the trigger and the downstream tool it feeds.

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, non-destructive and closed-world, so the safety profile is covered. The description adds useful scope facts (base year, 16 sectors, monthly frequency) but says nothing about pagination, missing periods, or how sector-level results differ from general-level 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?

Two sentences, front-loaded with the dataset identity and scope, with no filler. Slightly terse for a data tool but every clause carries information.

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 an output schema present, the description need not explain return values, and the fully documented schema plus annotations cover the mechanics. What remains thin is routing guidance relative to the many sibling indicator tools, but the core scope is complete.

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 start/end formats, sector examples and the measures vocabulary are already fully documented in the schema. The description only reinforces the sector dimension ('16 sectores') and adds no format or default detail beyond what the schema states, which is the baseline-3 case.

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 dataset (EMAE, base 2004=100) and states its scope: general level since 2004 plus 16 sectors, monthly, leading GDP. That is a clear resource statement an agent can match to a request for Argentine monthly activity data, though it does not explicitly contrast itself with siblings like industrial_production or construction_costs.

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?

There is no when-to-use or when-not-to-use guidance and no named alternative. The phrase 'indicador mensual que anticipa el PIB' hints at context but never tells the agent to prefer compare_series for cross-dataset comparison or latest_indicators for the most recent print.

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/closed-world, so the description's job is to add data-quality context, which it does: sums exclude confidential rows (statistical secrecy) and the result reports how many were excluded, with an instruction to mention it when citing amounts. That is meaningful behavior an agent could not get from annotations, though return shape and defaults are left to the schema/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?

Two dense sentences with no filler; the coverage period and units come first, followed by the confidentiality caveat. Slightly overloaded with clauses, but every element carries information.

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, all-optional aggregate tool with full schema coverage, an output schema and annotations, the description supplies the remaining essentials: temporal coverage, units, naming convention and the statistical-secrecy caveat. Nothing an agent needs to call or report it correctly is missing.

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 every parameter is already documented with formats, defaults and examples. The description adds only the units (millions USD, tonnes) and the names-instead-of-codes convention, which is mildly useful but does not deepen individual parameter meaning 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 concrete verb+resource: foreign trade in goods since 1986, in millions of USD and tonnes, aggregated by month, year, country or category. The phrase 'con nombres en lugar de códigos' implicitly separates it from the trade_codes sibling, but no sibling is named explicitly, so routing still requires inference.

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: the aggregation dimensions signal 'use this for grouped trade aggregates', and 'mencionalo al citar montos' gives a citation instruction. There is no explicit when-to-use/when-not guidance and no pointer to compare_series, query_sql or trade_codes for other 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 readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety behaviour is covered by structured data. The description adds real context beyond that: the statistical source (INDEC) and the hard historical floors (2016 for manufacturing, 2017 for mining), which tell an agent when a request will fail. It omits frequency (monthly), whether series are provisional/revised, and how the published 'variaciones' are expressed.

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 the identity and coverage windows front-loaded; no filler or marketing language. It is arguably too terse, 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 0 required parameters, 100% schema coverage and an output schema, the description only needs to anchor scope, which it does together with the temporal bounds. The main residual gap is frequency/units of the published series, which an agent would like before interpreting results.

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 goes slightly further by tying the sector split to the year windows and confirming what the index decomposes into (división y rama for manufacturing; commodity groups for mining). It still does not explain what the default measures list yields or how 'v_acum' is accumulated, but the schema already carries those parameter-level details.

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 resource (Índice de Producción Industrial) and enumerates the two sub-universes it covers (manufacturero desde 2016 por división y rama; minero desde 2017 con petróleo, gas, minerales, rocas), which lets an agent distinguish it from broader siblings such as economic_activity or construction_costs. It never states a verb (retrieve/query), but the noun-phrase identification 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?

There is no when-to-use or when-not-to-use guidance and no sibling is named as an alternative. An agent must infer that this is the right tool for industrial output versus economic_activity, and nothing tells it whether this replaces or complements that tool. The coverage start years are contextual facts, not selection guidance.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered upstream. The description contributes the dataset's temporal scope (from December 2016) and the fact that categories and regions are the slicing dimensions, but says nothing about row volume, granularity of the response, or pagination. That is a modest addition over 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?

It is a single sentence that front-loads the resource and base period before listing the available measures and dimensions. Nothing is padded, though the enumerations duplicate what the schema already documents, so one point is withheld rather than awarded.

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 five optional parameters fully documented and an output schema present, the description only needs to establish what the endpoint is and what it returns; it does that. The region/category interaction limitation (groups and classes only exist by region) lives in the schema rather than the description, which is acceptable but leaves the description one step short of fully self-contained.

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 every parameter already carries a documented meaning, including valid regions, category examples, and the measure codes. The description merely restates the measure families and the category/region slicing without adding format or semantics beyond the schema. Baseline 3 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?

It states a specific resource (the monthly CPI series, base Dec-2016) with its time coverage and the measures it delivers (monthly, year-on-year, cumulative variation, index, contributions), broken down by category and region. An agent immediately knows this is the CPI data source. It does not, however, distinguish itself from siblings such as wholesale_prices or compare_series, so it stops short of a 5.

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: 'serie mensual del IPC por categoría y región' tells the agent what data it can fetch, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative such as compare_series for cross-dataset comparisons. The agent must infer the boundary from the resource name 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 readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered externally. The description adds domain-scoping context (quarterly frequency, coverage starting Q2 2016, 31 agglomerates, EPH source) that is genuinely useful. However, it says nothing about how the empty-string default behaves in practice beyond what the schema states, and the return format is handled by the 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?

A single sentence that front-loads the indicator list before the temporal, geographic and source qualifiers. It is dense but wastes no words; the parenthetical is slightly packed but still readable.

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 an output schema present and full parameter documentation, the description supplies sufficient dataset scope for correct invocation. Its only meaningful gap relative to tool complexity is usage routing against siblings, which is minor for a simple read-only data query.

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 both start and end already document the accepted formats ('AAAA' or 'AAAA1T'...'AAAA4T') and the empty-means-full-series default. The description does not add syntax or meaning beyond the schema, so baseline 3 is appropriate.

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 resource and its measurable contents: quarterly rates of activity, employment, unemployment, formal/informal employment, and underemployment, sourced from EPH. It is clearly a labor-market dataset bounded to Q2 2016 onward across 31 urban agglomerates. It does not explicitly distinguish itself from siblings like economic_activity or wages, so it stops short of 5.

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?

There is no explicit when-to-use or when-to-use-another guidance. An agent must infer that this tool is for labor-market indicators while economic_activity or wages cover adjacent topics. No prerequisites or exclusions are stated.

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?

The annotations already establish that this is a safe, read-only, idempotent, closed-world operation. The description adds that each figure comes with its period and lists the covered indicators, but it does not disclose update cadence, data vintage, provisional status, or other behavioral caveats beyond 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?

The description is two sentences, front-loads the resource and scope, then gives the usage priority. The indicator enumeration is necessary to define coverage and no sentence is 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?

It is complete for a zero-parameter aggregator: it names the source, lists the included indicators, notes that each figure has its period, and gives routing guidance. An output schema exists, so return structure need not be explained in the description.

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 has zero parameters, so there is no parameter semantics to clarify beyond the schema. The description's enumeration of included indicators adds content context, but parameter semantics are not applicable and the baseline of 4 is appropriate.

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 exactly what the tool returns: the latest headline INDEC figures, each with its period, and enumerates the covered domains (inflation, activity, wages, baskets, poverty, labor). This clearly distinguishes it from sibling tools that each cover a single domain such as inflation_series, wages, or poverty.

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 explicitly says 'Usala primero para preguntas generales', giving a clear priority rule for broad questions. It does not name specific alternatives or state when not to use it, but the 'first' guidance implies follow-up use of the more specific sibling tools.

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, closed-world and non-destructive, so safety is covered structurally. The description adds the useful fact that results are a catalog of dataset metadata including sync status, but says nothing about ordering, completeness of the list, or behavior with unsynchronized datasets.

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 compact sentence with no padding, and the field enumeration is front-loaded as a parenthetical. It is slightly weaker as a lead because it is a noun phrase rather than an action statement, but nothing is 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 an output schema present, the description need not detail return values, and it correctly covers the input side (none) plus the general shape of entries. It falls short on the one thing that matters for a no-argument discovery tool: how it relates to describe_dataset and the domain-specific sibling tools.

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 the baseline of 4 applies; there is nothing for the description to clarify beyond confirming the call is argument-free. No schema semantics are missing.

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 resource ('los datasets del mirror') and enumerates the metadata each entry carries (SQL table name, description, row count, last period, sync status), so the resource is clear even though the verb is only implied by the tool name. It does not distinguish itself from the sibling describe_dataset, which an agent could easily confuse with this catalog listing.

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?

There is no statement of when to call this versus alternatives; describe_dataset and query_sql are obvious siblings that require routing guidance and none is given. The only implicit cue is that the tool takes no arguments, which a caller must infer on their own.

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?

The annotations already declare read-only, idempotent, non-destructive, closed-world behaviour, so the description does not need to cover safety. It does add one genuinely useful behavioural trait: the data comes from the 2022 Census base and is projected to July 1, which tells the agent how current the figures are. It says nothing about projection uncertainty, gaps for smaller units, or response shape, though an output schema already covers the response shape.

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?

It is a single dense sentence, and the key elements — indicator, reference date, source base, scope, breakdowns — all come first. It is efficient, though the trailing 'con apertura por...' clause is a little compressed and nearly restates the 'by' parameter.

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 an output schema present and all three optional parameters fully documented in the schema, the description needs only to frame scope and data vintage, and it does. Only the routing guidance (when to use this versus siblings) is missing, which is a minor gap for a read-only data 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?

Schema description coverage is 100%, so the schema already explains 'by', 'year', and 'place' in detail, including the default and the valid ranges. The description only echoes the breakdown dimensions ('por sexo, grupos de edad o departamentos') and the geographic levels; it adds no syntax or edge-case detail beyond the schema. A baseline 3 is appropriate.

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 precise resource — estimated and projected population as of July 1 (2022 Census base) — and states its full scope: country, province, or department, broken down by sex, age group, or department. That level of specificity is enough for an agent to pick it over siblings like poverty or labor_market, which cover different domains.

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 coverage of the tool is clear, but there is no explicit when-to-use guidance: it never says to prefer this over compare_series or query_sql, nor does it state any preconditions. The intended use can be inferred from the described scope, but that is all — the guidance is implied rather than stated.

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, non-destructive, and closed-world, so safety is covered. The description adds genuine behavioral context beyond that: the data is semestral, begins in the 2nd semester of 2016, and covers the 31-agglomerate urban total only (not a national or per-agglomerate breakdown), which affects interpretation. Return shape is covered by the 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?

A single dense sentence that front-loads the metric, then frequency, temporal coverage, and geographic scope. No filler, no redundancy, and everything an agent needs for a first pass is in the opening clause.

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, read-only series tool with a full output schema and complete parameter descriptions, the definition is nearly sufficient. The only material gap is the absence of any routing guidance relative to the many sibling indicator tools, plus no note on units beyond 'porcentaje' (already given) or on geographic granularity limits beyond the 31-agglomerate 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 description coverage is 100%, and both start and end already document the 'AAAA' / 'AAAA1S'/'AAAA2S' formats and the empty-equals-full-series default. The description adds only indirect meaning by stating the series is semestral from 2016, which helps an agent choose sensible bounds but is not tied to the parameters explicitly. Baseline 3 is appropriate.

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 metric: percentage of persons and households below the poverty and indigencia lines, with frequency (semestral), series start (2nd semester 2016), and coverage (31 urban agglomerates, EPH). An agent knows exactly what data this returns. It does not, however, name or differentiate itself from siblings such as latest_indicators or compare_series, which likely surface overlapping indicators.

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 by the subject matter — an agent can infer it should call this for poverty/indigencia figures. There is no explicit when-to-use statement, no mention of when to prefer latest_indicators for a single current value or compare_series for cross-indicator comparison, and no stated prerequisites.

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 openWorldHint=false, but the description adds hard operational facts the annotations cannot convey: single SELECT statement, 500-row cap, 5-second limit, and no file or network access. Those constraints directly shape how an agent must phrase queries and handle 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?

Front-loaded with the capability, then the limits, then the usage advice in three compact clauses. No redundant restatement of the name or title, and every clause carries actionable information.

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 an output schema present, return values need no explanation, and the description covers dialect, limits and isolation. The one gap is discoverability: it says 'las tablas del mirror' without indicating that list_datasets or describe_dataset reveal the available tables and columns, which an agent needs before writing valid SQL.

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% and the single parameter is already documented as 'una única consulta SELECT en dialecto DuckDB', so the baseline is 3. The description earns an extra point by adding a data-level detail absent from the schema: period columns are stored as text in 'YYYYMM' form, which prevents a common type-mismatch error.

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: read-only SQL (DuckDB) over mirror tables. That is unmistakably different from the domain-specific siblings such as inflation_series or labor_market. It stops short of a 5 because it never explicitly frames itself as the generic escape hatch alongside list_datasets/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?

Gives concrete usage direction: aggregate and filter in SQL rather than pulling raw rows, and notes periods are text ('202609'). This tells the agent how to use the tool well. It offers no explicit when-not or routing to the 16 domain siblings, which would be the natural alternative for common indicators.

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 closed-world, so safety is covered. The description adds a genuine behavioral trait beyond them — matching ignores case and accents — but says nothing about fuzzy vs exact matching, result limits, or ranking, and the existing output schema carries the return shape.

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 short sentences, front-loaded with the action and resource, then the matching rule. No filler and nothing an agent must read twice.

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 one-parameter lookup tool with rich annotations and an output schema, the description covers scope and matching semantics adequately. Minor gaps remain around matching behavior (prefix vs substring) and result size, but nothing essential to calling it correctly is missing.

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 illustrative examples ('china', 'carnes', 'MOI'), so the baseline is 3. The description adds real meaning to the single query parameter by declaring accent- and case-insensitive matching, which the schema does not state.

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 ("Busca") plus the resource ("códigos del diccionario de comercio exterior") and enumerates the code families covered (países, rubros, subrubros, usos económicos, grandes categorías). It is clearly distinguishable from numeric-series siblings like inflation_series or wages, though it never names foreign_trade or query_sql as related lookup paths.

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: look up trade-dictionary codes before querying. There is no explicit statement of when to prefer this over foreign_trade or query_sql, nor any exclusion such as whether it searches only the code dictionary and not indicator data.

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, non-destructive and closed-world, so safety is covered. The description adds genuinely non-structured context: the series starts oct-2015, comes from INDEC, and defaults to monthly + interannual variations. It does not discuss latency, revision policy or output shape, but the output schema exists to cover the latter.

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, zero filler: scope and coverage come first, then the routing hint to the alternative. Nothing in it repeats the schema or the annotations.

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 annotations covering the safety profile, a fully documented 4-parameter schema, an output schema and a sibling pointer, an agent has everything needed to call this correctly. No required parameters and clear defaults mean no missing prerequisite information.

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 sector enumerations, date formats and measure codes are already fully documented in the schema. The description restates that monthly, interannual and accumulated variations exist, which lightly reinforces the 'measures' parameter without adding syntax or defaults beyond the schema — the baseline 3 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 resource (índice de salarios por sector), its publisher (INDEC), its temporal coverage (desde oct-2015) and the three variation types it returns. It also differentiates itself from the sibling compare_series by naming when that tool is the right one, so an agent can separate it from inflation_series and labor_market 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?

Explicitly routes one alternative case — 'Para compararlos con la inflación usá compare_series' — which is clear when-to-use guidance for the most likely confusion. It does not state exclusions or conditions for the remaining siblings (labor_market, latest_indicators), so it stops short of full when/when-not coverage.

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 establish readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond them — the series starts in December 2015 and figures are INDEC-published — but says nothing about defaults, latency, or result shape. With annotations carrying the main burden, a 3 fits.

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 compact sentence with the source system and temporal coverage front-loaded, then the breakdown dimensions. No redundant or filler wording, though the heavy use of acronyms makes it slightly dense for an unfamiliar reader.

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 has an output schema and full schema descriptions, and the description adds the two facts those structures cannot convey: the source (INDEC) and the historical start date. Nothing critical to a correct call is missing, though a pointer to the overlapping sibling tools would complete it.

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 every parameter (including start/end format, index variants, category codes and measure names) is already documented in the schema. The description's mention of 'nivel general, origen (nacional/importado), sector o rubro' only restates the category parameter. Baseline 3 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?

Names the specific resource (Sistema de Índices de Precios Mayoristas) and enumerates the three variants (IPIM, IPIB, IPP) plus the breakdown dimensions. An agent can tell this is wholesale price data as opposed to inflation_series or construction_costs, though it never names those siblings 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 by the subject matter and the 'desde dic-2015' coverage note; there is no statement of when to prefer this over inflation_series, latest_indicators or construction_costs, and no exclusions. An agent must infer the routing decision from the topic alone.

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