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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description still adds real value by disclosing the aggregation shape (min/max attendance), the filtering side effect of minimo_citaciones, and a genuine edge-case warning that duplicate names may be homonyms. It does not discuss pagination or how many rows are returned by default.

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 plus a short warning sentence carries the output shape, filter rationale, and the homonym caveat with essentially no filler. It is slightly run-on, but the core (what is computed and for which chamber/legislature) is front-loaded.

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 formatting need not be explained, and annotations handle the safety profile. Still, for a 5-parameter tool with 0% schema coverage, the unexplained `cantidad` parameter leaves a real gap an agent must guess at to invoke 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 0%, so the description must compensate: it explains legislatura's range (46–50), the purpose of minimo_citaciones, and that nombre filters rows containing that string (implying substring match). But `cantidad` (default 10) is never explained — presumably row count — and `camara` is only indirectly covered by 'Senado o Diputados'. Partial compensation, not full.

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 (attendance to Senate/Deputy sessions in a legislature) and specifies what it returns: the lowest and highest attendance among legislators meeting minimo_citaciones, plus rows matching nombre. This is concrete enough to distinguish it from the parliamentary siblings (leyes, proyectos_parlamento, resultados_electorales), 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?

Useful constraints are implied — the legislatura window (46–50, 'la actual') and the rationale for minimo_citaciones (avoiding substitutes with only two citations) guide filtering choices. However, there is no explicit statement of when to use this tool versus another, and no mention of what happens when the filters return nothing.

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/non-destructive, and the description adds real behavioral detail: free-text word search that ignores accents and returns names rather than values. It doesn't discuss result ordering, pagination, or match behavior (prefix vs substring), which keeps it below 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?

Three tight sentences, front-loaded with scope, then the handoff to indicador_social, then the department query tip. The domain list is long but serves keyword-matching purposes, so it earns its space.

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?

An output schema exists, so return values needn't be described, and the search-then-fetch workflow is fully explained. The only gap is the unspecified 'cantidad' limit for a 1,260-item catalog, which an agent would want to know.

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% for both parameters, so the description must compensate. It clarifies the 'texto' parameter (word search, no accents, department keyword convention) but never explains 'cantidad' (default 20, max?), leaving one parameter undocumented in both places.

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) and resource (los ~1.260 indicadores sociales del Observatorio Social del MIDES), enumerates the covered domains, and explicitly distinguishes itself from the sibling indicador_social by noting it returns names 'para pasar a indicador_social'.

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?

Explicit two-step workflow: search here first, then feed the returned names into indicador_social. It also gives a concrete routing rule for a special case ('para un departamento, incluir la palabra departamento') with an example query.

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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description adds real context beyond them, including the 1971-2025 normal used as the anomaly baseline, the 400-day cap, the degrees-Celsius-per-decade unit, and the standard error returned with the trend. It does not discuss rate limits or data gaps, but for a read-only series endpoint it does more than 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?

Three sentences, no filler: the source and series identity is front-loaded, then the no-dates mode, then the dated mode with its format and limit. Each clause constrains behavior or output.

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?

An output schema exists, so return values need not be spelled out; the description still defines both result shapes (trend plus standard error; daily values plus anomaly) and the constraints that determine which one is produced. Nothing an agent needs to call this correctly is absent.

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 0%, so the description carries the full burden and meets it: it names both parameters, gives the date format (AAAA-MM-DD), the range constraint (hasta 400 días), and the mutual requirement that both dates are supplied or neither. The empty-string defaults and the both-or-neither rule are thereby reconciled instead of left ambiguous.

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 (climate at the INIA Salto Grande station, series since 1970) and explicitly distinguishes the two operating modes: a trend of annual mean temperature with its standard error, and daily rainfall and maximum/minimum temperatures. An agent can tell exactly what the tool returns 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?

The condition that selects each mode is stated explicitly: 'Sin fechas' versus 'Con `desde` y `hasta`', and the caller is told 'Se pasan las dos fechas o ninguna'. What is missing is a pointer to the sibling weather tool (observaciones_inumet), so the agent is not told when to prefer this station series over that alternative.

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, so the safety profile is covered. The description adds genuinely new context: prices are IVA-inclusive and administratively fixed by the Executive, and the catalogue-first pattern constrains how `producto` may be populated.

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 lines, zero filler, and the price definition is front-loaded before the parameter behavior. Every clause maps to a distinct decision the caller has to make.

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?

An output schema exists, so return values need no explanation, and the description covers the catalogue/query branching completely. Only the integer format of `anio` and `mes` is left implicit, which is a minor omission for a zero-required-parameter 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 coverage is 0%, so the description carries the full burden, and it does explain the role and interaction of all three parameters (catalogue mode vs. series mode vs. single-month mode). It does not state formats or ranges for `mes`/`anio` (e.g. 1-12, four-digit year), leaving a small gap.

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: maximum retail prices (IVA included) for ANCAP fuels as fixed by the Executive. This clearly separates it from siblings like ventas_combustible (sales volumes) or paridad_combustibles (parity), though those siblings are never 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?

Gives explicit conditional usage for every mode: with no `producto` you get the product catalogue, with `producto` you get the monthly series, and adding `anio`+`mes` narrows to one month. It also warns that the names returned by the catalogue must be passed verbatim — the exact trap an agent would otherwise fall into.

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 safety (readOnly, idempotent, non-destructive), and the description adds substantive traits beyond them: currency conversion at the day's rate, a data-quality caveat about impossible quantity × price records, and an explicit performance cost (first query of a year downloads ~30 MB and is slow). That is exactly the context an agent needs before calling.

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-loads the core question, then filters, then conversions, then caveats, then cost — a sensible order with little waste. The data-quality sentence is slightly awkwardly spliced in, but every sentence conveys 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?

An output schema exists, so return shape needn't be explained; the description still covers units, scope, filtering, cost, and data reliability. The only real omission is the meaning of `cantidad`, which slightly undercuts completeness for a four-parameter 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 0%, so the description carries the burden: it explains `organismo` and `buscar` with concrete examples, and implies `anio` via the 2002-onward scope. However, `cantidad` (default 10) is never mentioned, leaving one of four parameters undocumented in both schema and description.

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 (how much the Uruguayan State awarded in a year), the units (pesos), the temporal scope (2002 onward), and the shape of the answer (top buying organizations and largest items). No sibling tool covers procurement, and the description makes the domain immediately obvious.

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 usage context through worked filter examples («Intendencia de Montevideo» for organismo, «ambulancia» for buscar), which tells the agent how to narrow queries. It stops short of explicit when-not-to-use guidance or naming an alternative, but no sibling overlaps this domain, so the gap is minor.

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, non-destructive and open-world traits. The description adds genuinely new behavior: the no-publication rule for non-business days, the 7-day lookback cap, and the fact that the response reports which date was actually used. It stops short of stating what happens when no prior business day falls inside the window.

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 blocks, front-loaded with the core purpose, then the currency list, then the edge-case rule. Every sentence adds information an agent needs; nothing is restated from the schema or 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 an output schema present, return-value structure need not be described, and the description still notes that the response reports the date used. All three parameters are explained, and the main non-obvious failure mode (weekend/holiday) is documented.

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 must carry the load and it does: it spells out the date format (AAAA-MM-DD), expands each currency enum value (dólar billete, Unidad Indexada, peso argentino billete, real billete), and defines hacia_atras's exact fallback semantics and limit.

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+resource: the official BCU exchange rate for a given date, in Uruguayan pesos, and enumerates the supported currencies. The single-date scope implicitly separates it from cotizacion_mensual, but the sibling is never named, so differentiation is inferential 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?

Gives concrete operational context: weekends and holidays have no publication, and hacia_atras=true falls back to the previous business day within a 7-day window. It does not say when to prefer this tool over cotizacion_mensual or what to do if no publication exists within the window.

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 bar is lower; the description nonetheless adds real behavioral facts: a hard 240-month cap, per-month published-day counts, and the current month being flagged as incomplete. It does not discuss rate limits or error behavior on out-of-range dates.

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, zero filler, and the core operation is front-loaded before the qualifiers about day counts and incomplete months. Slightly dense as a single run-on sentence but efficient.

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 three-parameter, read-only aggregation tool with an output schema already defining return shape, the description covers scope, limits, and the notable 'incomplete current month' caveat. The only residual gap is the currency parameter's semantics.

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 must carry parameter meaning; it does clarify the AAAA-MM month format and that 'desde'/'hasta' are the two bounds, which is genuinely additive. However, it says nothing about 'moneda' beyond what the enum values convey, so compensation is partial.

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: monthly average of a BCU quote between two months, with published-day counts. This clearly separates it from the daily quote sibling 'cotizacion', though the description never names that sibling 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?

The phrase 'Promedio mensual ... entre dos meses' implies this is the multi-month aggregation tool rather than a single-quote lookup, but there is no explicit when-to-use/when-not guidance or reference to alternatives such as 'cotizacion'.

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 the safety profile is covered. The description's 'No sale a la red' restates openWorldHint=false in plain language and adds the diagnostic framing, but discloses nothing further about cost, freshness guarantees, or failure modes.

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: what is reported, why it matters, and the network constraint. The purpose is front-loaded and every sentence earns its place.

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 zero parameters, an output schema describing the returned cache data, and annotations covering the safety profile, the description is essentially complete for an agent to call it correctly. Only a note on whether results can be empty for never-fetched sources 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?

The tool takes zero parameters, so the baseline is 4; there is no parameter meaning for the description to carry, and the schema is trivially complete.

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 concrete resource (the cached file per data source, its timestamp, and its size) rather than restating the name 'diagnostico'. It is clearly a meta/diagnostic tool distinct from the data-returning siblings, though it never explicitly contrasts itself with any of them.

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 use case: 'Sirve para saber si un numero viejo viene de una copia vieja', telling the agent to call this when results look stale. There is no explicit when-not or named alternative, but the intended trigger is unambiguous.

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 behavior, so the safety profile is covered. The description adds useful scope context (the CTM network, both river banks) and says the response includes each station's published variables plus its latest reading. It does not say how 'nearest' is computed, whether a search radius applies, or what happens with sparse coverage.

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?

One sentence that front-loads the data source and the core operation, with no filler. It is appropriately sized, though the single sentence leaves little room for the missing operational detail.

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?

An output schema exists, so return values need not be described, and annotations cover safety. However, with three undocumented parameters including an unexplained 'cantidad' and no guidance on choosing this tool over related weather/river siblings, the definition is only minimally sufficient for correct invocation.

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 must compensate. It implies the first two parameters via 'más cercanas a un punto' but never names lat/lon, states their format or CRS, or mentions 'cantidad' at all — the default of 5 and its meaning are left entirely undocumented.

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 resource and operation: nearest stations in the CTM Salto Grande network to a point, returning each station's variables and latest reading. The basin/scope detail ('cuenca del río Uruguay, las dos orillas') makes the dataset identifiable. It stops short of naming how it differs from siblings like clima or nivel_rio, which also deal with weather/river data.

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 indication of when to pick this over clima, nivel_rio, or ubicar_punto, all of which appear in the sibling list. There is no statement of prerequisites, expected radius, or what happens when no station is near the given point.

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 behavior. The description adds meaningful behavioral context beyond those annotations: it names the official API, distinguishes result quality levels, and explains that when the API returns another street or the locality center, no coordinate is given. This is strong transparency for a read-only geocoder.

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 compact and front-loaded: it states the output, source API, result-quality levels, failure condition, parameter tip, and corner syntax. Every sentence adds actionable information without repetition.

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 three-parameter read-only geocoder with an output schema and safety annotations, the description covers purpose, API source, result quality, failure behavior, and a key parameter tip. The main remaining gap is that it does not explicitly route the agent away from sibling tools such as ubicar_punto or localidad.

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 must carry parameter meaning. It explains that direccion can be an address or corner and gives corner syntax examples, and it says localidad and departamento improve results. It does not fully explain expected formats or values for localidad/departamento, so the compensation is only partial.

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 operation: returning lat/lon coordinates for an address or street corner in Uruguay via the official IDE.uy API. It clearly defines the resource and scope, including result-quality categories. It does not explicitly differentiate itself from siblings such as ubicar_punto or localidad, so it falls 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?

Offers useful usage advice: passing localidad and departamento greatly improves results, and corner addresses should be written as '18 de Julio y Ejido' or 'Artigas esq. Solari'. However, it does not explicitly say when to use this tool versus sibling alternatives such as ubicar_punto or localidad, nor does it state exclusions.

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 description earns credit for what it adds: the default data source (INE's Continuous Household Survey), the 2023-2024 freshness ceiling, and especially the data-quality traps in `avisos` (mixed total rows, single-year `parcial` maps, ficha/table mismatch). It stops short of saying what happens on a bad indicator name or whether `avisos` is always present.

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 purpose and return contents, then `filtro`, then the `avisos` warning — a sensible ordering with no filler. The middle sentence is a long parenthetical chain, but every clause carries operational information an 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?

Even though an output schema exists, the description adds the interpretive layer the schema cannot: where the indicator name comes from, how to narrow rows, and how to read the warning field. For a two-parameter read tool this leaves no meaningful gap before invocation.

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 0%, so the description must carry the load and largely does: `filtro` is defined as comma-separated dimension values with concrete examples ('Salto', 'Mujeres,Pobre'), and `indicador` is defined operationally as the name returned by `buscar_indicador_social`. What's missing is that `indicador` is required and whether values are case/accent-sensitive.

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?

Specific verb+resource (reads a MIDES Social Observatory indicator) plus an explicit inventory of what comes back: title, unit, calculation method, data source, and the dimension/period table. It even states the temporal coverage (2023-2024), so an agent knows exactly what artifact it gets and cannot confuse it with numeric siblings like `cotizacion` or `ipc_argentina`.

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 the agent through the sibling `buscar_indicador_social` to obtain the `indicador` value, which is the decisive precondition for a correct call. It also tells the agent what to do after the call (`Leer los avisos`), turning the description into a small workflow rather than a bare capability statement.

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 read-only, idempotent, non-destructive, and open-world behavior. The description adds important semantic context beyond annotations: the base period (dic-1993 = 100) and the distinction that it returns an index, not inflation. It does not discuss rate limits or data availability, but given annotation coverage this is a solid addition.

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 short sentences, front-loads the key resource and output semantics, and wastes no words. The most important clarification (index, not inflation) is placed immediately after the range definition.

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 indicator tool with an output schema, the description supplies the essential context: what IPCA is here, the index base, the input date format, and that the return is an index rather than an inflation rate. Minor gaps such as range inclusivity or data availability are not critical for correct invocation.

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 must carry parameter semantics. It meaningfully explains that the two parameters are months in AAAA-MM format and together define a range, which compensates substantially for the bare schema. It still leaves boundary inclusivity and per-parameter labeling implicit.

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 clearly identifies the specific indicator (IPCA de Brasil as an index number with base Dec-1993=100) and the date range it accepts. It also clarifies that it returns the index rather than inflation, which adds useful distinction, but it does not explicitly name or differentiate against sibling tools such as ipc_argentina.

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 note 'Devuelve el índice, no la inflación' implies when to use this tool (when an index value is needed, not an inflation rate). However, it provides no explicit when-not-to-use guidance or named alternatives, leaving the agent to infer usage boundaries.

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?

Las anotaciones ya declaran readOnlyHint, idempotentHint y destructiveHint=false, por lo que la carga es menor. La descripción añade contexto valioso no cubierto por las anotaciones: la base del índice y que el valor retornado es el índice, no la variación porcentual, evitando un mal uso frecuente.

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?

Dos oraciones sin relleno; la identidad y base del índice van primero y la aclaración sobre el valor devuelto al final. Cada frase aporta información esencial.

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?

Con anotaciones de solo lectura, esquema de salida presente y solo dos parámetros, la descripción cubre lo esencial: qué es, el formato de fechas y qué devuelve. Falta mencionar la disponibilidad temporal de los datos (inicio en dic-2016) y el comportamiento ante fechas inválidas o fuera de rango.

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?

La cobertura de descripción del esquema es 0%, por lo que la descripción debe compensar. Lo hace al especificar el formato AAAA-MM para los dos meses ('desde' y 'hasta'), que es la información crítica que falta en el esquema. No aclara si el rango es inclusivo ni el orden requerido.

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?

La descripción nombra un recurso específico (IPC nacional de Argentina) con su base (dic-2016=100) y aclara el resultado ('Devuelve el índice, no la inflación'). Esto lo distingue implícitamente de hermanas como ipca_brasil, pero no las menciona ni diferencia explícitamente.

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?

Se indica el contexto de uso (rango entre dos meses AAAA-MM) y una advertencia semántica útil (devuelve índice, no inflación), lo que implica que la inflación debe calcularse. Sin embargo, no hay instrucciones explícitas de cuándo usarlo frente a alternativas ni condiciones de exclusión.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds useful scope and behavior details beyond annotations: the 1985 coverage boundary, accent-insensitive title search, date format, and that the return value points to the updated IMPO text.

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 resource and scope, then the search modes and return value. There is no redundant or filler language.

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?

Output schema and annotations are present, so the description need not explain return structure or safety profile in detail. It covers the main query modes and scope; the only notable omission is the meaning and effect of the 'cantidad' parameter.

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 must carry parameter meaning. It explains the title-search, date-range, and number parameters, but does not explain 'cantidad' or its default limit, leaving one of five parameters undocumented in both schema and description.

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 clearly states the resource and scope: promulgated laws since 1985, searchable by title text, date range, or number. It also says it returns the link to the updated IMPO text. It does not explicitly differentiate from sibling tools, but the purpose 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?

It gives clear usage contexts: search by title text (accent-insensitive), by date range in AAAA-MM-DD format, or by number. It does not name alternatives or exclusions, but the query modes are explicit enough for an agent to select the tool.

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/non-destructive, so the safety profile is covered. The description still adds real behavioral detail beyond them: accent-insensitive matching, multi-row return when the name spans several departments, and descending-population ordering with a cap. What is missing is what happens on a no-match (empty result vs. error).

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 dense clauses, front-loaded with the data and time frame, then the matching rule, then the disambiguation and listing modes. No filler sentences; each clause carries load-bearing 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 all three parameters and both calling modes. For a read-only, idempotent lookup tool this is sufficient to invoke 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 0% and all three parameters carry bare titles, so the description must compensate — and it largely does: accent-insensitivity and disambiguation for `nombre`/`departamento`, and the cap semantics of `cantidad`. It does not state what an empty `nombre` default does, leaving the implicit listing mode to be inferred from the departamento clause.

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 (población y viviendas 2023) and scope (localidad uruguaya) with a clear retrieval verb, and it distinguishes itself from every sibling, none of which handle locality population/housing data. An agent immediately knows what data comes back and at what granularity.

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 lays out two concrete call modes: pass `nombre` to look up a locality (optionally with `departamento` to disambiguate), or pass only `departamento` to list its localities sorted by population up to `cantidad`. The conditions for each mode are explicit, though there are no exclusion cases or sibling alternatives to steer against.

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 useful behavioral facts beyond that: readings every 15 minutes, per-day aggregation, a 92-day maximum window and a 14-day default. It does not discuss behavior at the window limit or how a station name is resolved, keeping it just short of 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?

Front-loaded with what is returned, then parameters, then the sibling fork. Every clause adds information — the interval, the aggregation, the window limits and the default — with 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?

An output schema exists, and the description still summarizes the return shape (min/mean/max, latest, delta), so an agent has enough to call it confidently. The one gap is the relationship to nivel_rio_comparado, which an agent must infer.

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 0%, so the description must carry all parameter meaning, and it largely does: `estacion` accepts a name or an id (default Salto), `desde`/`hasta` are AAAA-MM-DD with a 92-day cap and a 14-day default. Only edge behavior (invalid station, dates beyond the limit) is left unstated.

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 (river height H at a Salto Grande Mixed Technical Commission station) and exactly what it returns: daily min/mean/max, latest reading and net change over the period. It is clearly distinct from siblings like nivel_rio_comparado and estaciones_cercanas, which it names as the alternative for locating a station.

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 explicit routing for one sibling: 'Para encontrar una estación cerca de un lugar, usar estaciones_cercanas.' It also implies the appropriate scope (historical window up to 92 days, default 14). It does not, however, state when to prefer this over nivel_rio_comparado, which is presumably the multi-station comparison tool.

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 safety is covered. The description adds real behavioral context beyond them: years with sparse readings are excluded and surfaced in the output, and the first call may be slow (cold-start latency). That latency warning is exactly the kind of thing annotations cannot express.

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 with the user-facing question front-loaded, then mechanics, then the edge-case caveats. Nothing is redundant; the only minor cost is that the question framing delays the operative description by one 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?

An output schema exists, so return values need not be described, and the comparison logic and exclusion rule are well covered. The gap is the entirely undocumented `estacion` parameter — for a tool whose entire result depends on which station is queried, leaving that undocumented in a 0%-coverage schema is a real omission.

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?

With 0% schema description coverage the description must carry all parameter meaning, and it only partly does: `dias` gets a range (1–31) and `hasta` gets a default (today), but the date format for `hasta` is unstated and the `estacion` parameter is never mentioned at all, even though it defaults to "Salto". Two of three parameters are addressed, one is invisible.

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 precisely what the tool computes: the average river height over the last `dias` up to `hasta`, compared against the same calendar days in every year since 2017, plus the resulting ranking. That is specific enough to separate it from the sibling `nivel_rio`, though the differentiation is only implicit (comparison vs. raw level) and is never stated outright.

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 opening question ("¿El río está alto o bajo para la época?") frames the use case well and implies when this tool is the right pick. However, no alternative is named and no exclusion is given — nothing tells the agent to prefer `nivel_rio` for a plain current reading, which is the most likely confusion given the sibling set.

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 read-only/idempotent safety, and the description adds substantial non-obvious behavior: the source publishes in UTC but days are Uruguay local (UTC-3), an incomplete day returns null rather than a partial total, and the query window is capped at 400 days. The null-instead-of-partial rule in particular prevents an agent from silently producing wrong aggregates.

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 source, granularity and station list, then moves in a single step to mode semantics and constraints. Dense without redundancy; every sentence (timezone, null rule, aggregation rule) carries operational weight.

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?

An output schema exists, yet the description still sketches both return shapes (coverage metrics; per-day values), which is appropriate for a tool with two modes. Minor omissions for a tool this complex: no units (°C, mm), no behavior when `hasta` precedes `desde`, and no statement of what an empty `estacion` implies beyond the coverage-mode hint.

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 must carry the load, and it does: date format AAAA-MM-DD, the 400-day ceiling on desde/hasta, the mandatory nature of `agregacion`, and the variable-to-aggregation mapping. Gaps remain on the meaning of `promedio` across variables, the empty-string defaults for `estacion`/`desde`/`hasta`/`agregacion`, and how free-text station names map to the seven listed stations.

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 the specific resource (hourly INUMET weather observations aggregated to local days) and enumerates the seven stations covered, so the agent knows the data source and geographic scope. It does not, however, contrast itself with nearby siblings like `clima`, `nivel_rio`, or `estaciones_cercanas`, so the boundary of what this tool is *for* versus those is left to 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?

Explicitly describes two invocation modes: passing only `variable` returns per-station coverage, while adding `estacion`, `desde`, `hasta` and `agregacion` returns per-day values. It even routes the agent to the correct aggregation per variable (max/min for temperature, suma for rain). It stops short of naming when to prefer a sibling tool instead.

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 that the tool is read-only, idempotent, non-destructive, and open-world. The description adds important non-obvious context: the comparison is tax-exclusive, monthly since 2022, constructed by this server rather than an official figure, and the agent should read `metodo`.

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 opening question front-loads the tool's purpose, and the `Sin producto`/`Con producto` structure makes the two call patterns easy to scan. Every sentence contributes scope, mode behavior, or the non-official-metric caveat.

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 annotations covering safety, the description supplies the remaining context an agent needs: what is compared, the data scope, parameter modes, and the derived-metric caveat. No essential invocation detail 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 0%, so the description carries the full burden and largely succeeds. It defines `producto` as a mode switch, lists the four fuel products, and specifies that `desde` and `hasta` are AAAA-MM bounds for the series when `producto` is supplied.

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 opens with the exact decision question and then states the specific comparison: ANCAP ex-plant fuel price versus URSEA's import parity price, tax-exclusive, in $/litre, monthly since 2022. This is a clear verb+resource definition and identifies a comparison operation rather than generic fuel-price retrieval.

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 explicit conditional behavior for the two modes: without `producto` the tool returns the latest month and 12-month average for four fuels; with `producto` it returns a series and the latest PPI breakdown. It does not name sibling tools or when-not conditions, so it provides clear context but not full alternative routing.

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 the description adds genuinely new behavioral context: only requests past the 45-day legal deadline are counted, and responses arrive late so recent requests always look less answered. That is exactly the kind of caveat an agent could not infer from 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 what is counted and the legal-deadline scope, then filter behavior, then the cohort caveat last. Dense but every sentence contributes a distinct fact; nothing is repeated from the schema or 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?

An output schema exists, so return values need no explanation, and the description still covers aggregation scope, filter semantics, date format, and the interpretation hazard. For a 4-parameter read tool this leaves nothing material 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 0%, so the description must carry the load and largely does: `organismo`/`tema` are text filters that must be written without accents, `presentados_hasta` is AAAA-MM-DD and defines the cohort. Only `cantidad` (page size) goes unexplained, which is a small residual gap.

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 concrete resource (pedidos de informes de Diputados), the legal basis (artículo 118) and precisely what the output aggregates: answered counts per organismo and semester, plus counts per party. It is clearly distinguishable from sibling parliamentary tools like leyes or proyectos_parlamento, though it never names them 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?

It gives real usage context — use `presentados_hasta` to compare a fixed cohort, and read `nota` before comparing — but never states when to prefer this over siblings or what it is not for. Guidance is implied and conditional rather than an explicit when/when-not 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 cover the safety profile (readOnly, idempotent, non-destructive, open world). The description adds meaningful behavioral context by disclosing the computation method—deflation via the BCU average Unidad Indexada—which an agent needs to trust the result. It does not discuss failure modes such as missing UI data for a month, so not 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?

Three compact sentences with the core operation front-loaded, followed by parameter formats and the use case. No filler or repetition.

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?

An output schema exists so return values need not be explained, and both parameters plus the nested map shape are covered. The only gap is handling of months lacking UI data or invalid date keys, which would matter for correct invocation.

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%, yet the description fully compensates: it documents that `montos` is a map of {"AAAA-MM": monto} and `base` is a "AAAA-MM" string, including the exact date format. Both parameters are unambiguous without opening 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 transformation: converting amounts in current pesos from different months to a base month by deflating with the BCU's average Unidad Indexada. The verb+resource is precise and understandable. It does not explicitly name the closest sibling (variacion_real) that an agent might confuse it with, so not 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?

The final sentence gives the use case ('Sirve para comparar en términos reales pesos de fechas distintas'), which implies when to use it. However, there is no explicit when-not guidance, no mention of prerequisites (e.g., whether UI must be available for all months), and no named alternative despite variacion_real being a plausible competing tool.

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 genuinely useful behavior beyond that: deduplication across legislatures ('cuenta una vez') and the fetch cost that the first search without a legislature downloads nine files. This is meaningful operational context.

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-loads the resource and scope, then adds the dedup rule and the download note. Compact and mostly waste-free; the download note is slightly tangential but still informative.

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 search criteria, deduplication and fetch behavior. Only the 'cantidad' limit is left unaddressed, so it is nearly complete for a search 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 coverage is 0%, so the description carries the burden. It clarifies 'buscar' (title text), 'legislatura', and 'tipo' (adding example values ley/resolución/minuta/declaración that the schema lacks as an enum), which is valuable. However, 'cantidad' (default 20) is never explained, leaving one of four parameters undocumented.

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: bills entered into Parliament since 1985 (legislatures 42–50), searchable by title, legislature or type. The verb 'entrados' plus the field list makes the retrieval purpose clear. It does not explicitly distinguish itself from the sibling 'leyes' tool, which covers an adjacent domain, 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?

The grammar of the search (by text, legislature or type) is conveyed, implying how to use the parameters, but there is no explicit when-to-use vs when-not guidance and no routing to alternatives like 'leyes'. Usage is inferable 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 read-only, idempotent, non-destructive, open-world behavior. The description adds useful context beyond annotations by specifying that it returns current ('vigentes') files with name, URL, format, and date, though it does not discuss pagination, authentication, or failure modes.

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 front-loaded sentence with no filler. Every element—resource type, returned fields, source domain, parameter, and example—earns its place.

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 annotations covering safety semantics, the description supplies enough context for a one-parameter lookup: domain, identifier semantics, and returned fields. A minor gap is that it does not say how to obtain a valid dataset identifier or what happens when it is invalid.

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 must carry parameter meaning. It does so by explaining that 'dataset' is the dataset identifier and giving a concrete example slug, which substantially compensates for the bare 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?

The description clearly identifies the resource: current files (name, URL, format, date) for a dataset from catalogodatos.gub.uy, retrieved by dataset identifier. It lacks an explicit verb such as 'obtiene' and does not differentiate from siblings, but the purpose is unmistakable.

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: call it when you already have a dataset identifier and need its current files. There is no explicit when-to-use/when-not-to-use guidance or named alternative, which is acceptable only because this is a narrow lookup tool.

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 genuine domain context beyond that: the data provenance (per-mesa Corte Electoral data), the inclusion of votos observados scrutinized in special tables without locality, and the percentage base (votos emitidos). This last point materially affects interpretation of the numbers.

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, all content-bearing, with the core purpose front-loaded and the methodological caveats following. Slightly dense prose but no filler or repetition.

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?

An output schema exists, so return-value explanation isn't needed, and the description still usefully covers provenance and the votos observados nuance. The remaining gap is the eleccion/departamento relationship, which an agent must guess before calling.

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 must carry parameter meaning. It partially does: 'del país o de un departamento' explains what the departamento parameter controls, and the three election types named in the text roughly map to the eleccion enum. However, it never specifies the expected format for departamento (name vs. code vs. canonical spelling) or whether it interacts with the eleccion values.

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 resource (Uruguayan election results) and enumerates exactly what it returns: habilitados, emitidos, participación, votes by party and by option. It also scopes the geography (whole country or a single departamento). No sibling tool covers elections, so explicit differentiation isn't required, but it doesn't name a complementary or alternative tool either.

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 ('resultados de una elección uruguaya') and by the eleccion enum in the schema, but there is no explicit when-to-use/when-not statement or prerequisite. Crucially, it never says whether the departamento filter is valid for all three elections (e.g. nacionales-2024) or only departamentales-2025, leaving a real selection question to inference.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that the result includes the Monday and Sunday of the week, which is useful behavioral context, but says nothing about timezone handling, week-numbering edge cases (e.g., dates in early January belonging to week 52/53 of the prior year), or error behavior for malformed dates.

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?

One short sentence with zero waste; the key information (what is returned) is front-loaded. Nothing to trim.

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?

An output schema exists, so the description need not explain the return shape, and annotations cover the safety profile. For a single-parameter pure computation, the remaining gap (edge-case behavior on week boundaries or invalid input) is minor.

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 carries the burden for the single 'fecha' parameter. It does add the expected format (AAAA-MM-DD), which the schema omits, but it does not cover edge cases such as invalid dates or whether the input is parsed strictly.

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 operation on a specific resource: computes the ISO 8601 week (W1, W2...) for a given date, plus the Monday and Sunday bounding that week. An agent can tell exactly what it returns. No sibling does date-week math, so differentiation is implicit 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?

There is no explicit when-to-use, when-not-to-use, or named alternative. Usage is implied by the purpose (call it when you need the ISO week or week boundaries for a date), which is adequate for a simple utility but leaves no guidance about alternatives such as computing weeks client-side.

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 that: the data source (official INE polygons), the 2023 population enrichment, the fallback behavior when the point falls in open country (nearest locality plus distance), and the IDE.uy nearest-address augmentation.

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 core purpose is front-loaded in the first clause and every subsequent clause adds information (population, countryside fallback, address enrichment, sibling combination). It is a long run-on sentence that could be split for scannability, but nothing is truly 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 and rich annotations, the description need not explain return values, and it still covers provenance, fallback logic, and workflow composition. The one meaningful gap is behavior for coordinates outside Uruguay, which an agent would want to know before calling.

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 0% — both parameters are bare numbers with only titles. The description compensates partially by specifying that lat/lon are in degrees, which the schema does not say, but it omits the coordinate reference system and any valid range or out-of-country error behavior.

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: given a point (lat/lon), return the department and locality in Uruguay it falls in, per INE polygons. It also implicitly distinguishes itself from the sibling geocodificar_direccion by framing that tool as the address→coordinates direction.

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 tells the agent to combine this with geocodificar_direccion to go from an address to a department, which clarifies the intended role in a two-step workflow. It lacks an explicit when-not-to-use statement (e.g. points outside Uruguay), so it falls short of a 5.

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 readOnly, idempotent, closed-world and non-destructive behavior, so the bar is lower. The description adds genuinely new behavioral context with 'No consulta a DGI: es validez aritmética', telling the agent the result is an arithmetic check and not an authoritative registry lookup — critical for trusting the output. It stops short of describing failure modes (e.g. qué devuelve si el dígito no coincide).

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 that front-load the core action, then the accepted input formats, then the crucial scope caveat. Zero filler and nothing repeated from the schema or 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?

For a two-parameter validation tool with an output schema (so return values need no explanation) and strong annotations, the description supplies what an agent needs: which documents, input format tolerance, and the non-authoritative nature of the check. Only edge-case behavior (invalid input, what a failed validation returns) 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 description coverage is 0%, so the description must carry the parameter meaning, and it does: it ties the digits (12 vs 8) to the two documents selected by 'tipo' and specifies that 'numero' accepts puntos, guiones y comas. This resolves the main ambiguities even though the enum literals 'rut'/'ci' are never named verbatim nor is it stated whether separators count toward the digit total.

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 (valida el dígito verificador) and two concrete resources (RUT de 12 dígitos, cédula de identidad de 8 dígitos) with the country scope. No sibling tool in the list does document validation, and the description makes the numeric/length distinction between document types 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 description implies when the tool applies by naming the two document types and the accepted separators (puntos, guiones, comas), which is useful input guidance. However it never states when to use this versus an alternative lookup, nor what to do for non-Uruguayan documents or invalid formats; usage is inferred rather than prescribed.

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 that the tool is read-only, idempotent, open-world, and non-destructive. The description adds useful behavioral context beyond annotations: it explains what is returned (nominal variation, period inflation, real variation, and final-month equivalent value) and maps each index to a currency. It does not discuss data availability limitations or source freshness, which would be needed for 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?

The description is compact and front-loaded with the core purpose. It moves efficiently from the operation to index mapping to returned fields. Every sentence contributes useful information, though it could be slightly tighter.

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, so the description does not need to exhaustively explain return values, but it still helpfully summarizes them. Given the 5 parameters and multiple inflation indices, the description provides enough information to invoke the tool correctly. It is missing explicit guidance about sibling alternatives and data coverage or freshness caveats.

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 carries the burden. It explains the `indice` enum values and their currencies (UI for Uruguay, IPC_AR for Argentina, IPCA_BR for Brazil), specifies the month format as AAAA-MM, and clarifies the monetary comparison. It does not explicitly describe every parameter or mention that `indice` defaults to UI, but it compensates well for most semantic gaps.

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 operation: calculates the nominal and real change of an amount between two months, including sales, prices, salaries, or rent. It clearly identifies what the tool computes and mentions the inflation indices it supports. It does not explicitly distinguish itself from a related sibling such as `pesos_constantes`, so it falls 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?

The description gives example use cases (sales, prices, salaries, rent), which implies when the tool is useful. However, it does not say when to use this tool instead of alternatives like `pesos_constantes`, nor does it state exclusions or prerequisites. Usage is inferable but not explicitly guided.

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, so safety is covered; the description adds real value with output-shape behavior (product list + missing months vs. monthly series) and a comparability caveat about not comparing years with different month counts. It does not cover auth, rate limits, or pagination, so not 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?

Front-loaded with purpose then per-parameter and per-mode details; dense but nearly every clause carries information. Slightly heavy with parentheticals and the units note tacked on at the end, but 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?

Given an output schema exists, the description still supplies the things the schema cannot: the two behavioral modes, mercado vocabulary, date format, and unit caveat (miles de m3 except petcoke in tonnes). 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 0%, so the description carries the full burden and does so: it defines `linea`'s toggle semantics, enumerates `mercado` values (vacio = todos), and specifies `desde`/`hasta` as AAAA-MM format.

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+resource: quantity sold by ANCAP of each fuel, per month, explicitly scoped as volumes not prices. It also names the sibling to use for prices (combustible_ancap), so an agent can distinguish it from that tool immediately.

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 splits behavior: without `linea` you get the product catalog plus unpublished months, with `linea` you get the monthly series and yearly totals. It also gives an explicit when-not (prices → combustible_ancap) and enumerates mercado values.

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