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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about whether this is a pure calculation or a mutation ('Actualiza' is ambiguous), what the result represents, or any rate-source behavior. Only the date-range scoping is implied.

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?

Very short and front-loaded, which is good, but the trailing English tagline 'UDIS adjustment' merely restates the Spanish and earns no place. Efficient size is offset by that dead sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-param tool with no annotations and no output schema, the description should convey what comes back (an adjusted amount) and the date conventions. Neither is present, leaving key agent questions unanswered.

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 the description only weakly maps to the params: 'renta/deuda/sueldo' hints at monto and 'entre fechas' hints at fecha_ini/fecha_fin, but no date format (ISO? DD/MM/YYYY?) or units are given. This matters for a date-driven financial calculation tool.

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 clear verb (Actualiza/ajusta) and the target resource (renta/deuda/sueldo), scoped 'por UDIS entre fechas'. An agent can distinguish it from pure conversion siblings like convertir_udis_a_pesos, though the description never names the distinction 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?

No when-to-use guidance, no conditions, and no reference to alternatives such as convertir_udis_a_pesos or get_udis_hoy despite the crowded sibling set of UDIS/currency tools. The agent must infer when adjustment is preferred over plain conversion.

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?

With no annotations, the description carries the full behavioral burden, yet it discloses only the supported currencies and that the rate is for an exact date. It says nothing about rate source, supported date ranges, permissions, error behavior for invalid dates/currencies, or the return structure.

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 bilingual sentences with the core purpose front-loaded and zero filler. Every fragment earns its place, making it easy for an agent to parse quickly.

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 3-parameter conversion tool with no annotations and no output schema, the description covers the purpose and currency domain but leaves significant gaps: expected fecha format and what the tool returns. The agent can call it, but with avoidable uncertainty.

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 compensate. It does add meaning by listing the allowed divisa values (USD/EUR/JPY/GBP/CAD) and implying fecha is a specific date, but it omits date format and any constraints on monto_mxn, leaving key parameter semantics incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Convierte pesos a divisa' with an explicit list of target currencies and the 'a fecha exacta' scope. It clearly distinguishes a MXN-to-FX conversion from siblings like convertir_udis_a_pesos, though it does not name any alternative tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no exclusions, and no pointer to alternatives such as get_tasa_hoy or get_divisas_rango. The agent can only infer that this is the conversion tool from the name and description; no conditions or prerequisites are stated.

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

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

No annotations and no output schema, so the description carries the full behavioral burden and delivers almost nothing: it doesn't say which UDIS rate/date source is used, what happens on non-business days, rounding behavior, or the response shape. Only the input date format is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the operation, and the date format requirement is stated. The English translation duplicates the Spanish sentence rather than adding information, which is minor padding.

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 tool with zero annotations, no output schema, and two undocumented parameters, the definition is too thin — an agent cannot tell what value it will get back or whether the conversion uses an exact-date UDIS rate. More context is needed.

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%, and the description only compensates for one of two parameters by specifying the fecha format yyyy-MM-dd. monto_udis is left completely undefined (units, decimals, sign), so the semantics of the core amount input remain opaque.

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 (convertir) and resource (UDIS to MXN) with an exact-date scope, which differentiates it from the currency-conversion sibling convertir_mxn_divisa. It does not explicitly name or exclude any sibling, but the operation is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this versus the many other conversion/rate siblings (get_udis_hoy, ajustar_por_udis, convertir_mxn_divisa). Usage is only implied by the tool name and the conversion direction.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the data source (latest auction) and horizon (28 days), but says nothing about return format, currency of the result, or the assumption that the value only refreshes at auctions. Partial behavioral disclosure for a no-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short clauses, fully front-loaded with no filler. The bilingual duplication ('Cetes estimate') adds little but does not bloat the text.

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 simple one-parameter computation tool with no output schema, the description covers what and how it computes but leaves the parameter meaning and the shape of the result unaddressed. Adequate but with visible gaps.

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 the single required parameter monto_mxn is never mentioned in the description. The name implies an amount in MXN, so an agent can loosely infer it, but the description does not explain how the amount feeds the yield calculation, leaving the compensation burden unmet.

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 (estima) plus resource (rendimiento de CETES), with the method and horizon spelled out: 28-day yield using the latest auction. An agent can tell this is a yield-estimate tool rather than a raw rate fetcher, though it does not explicitly name which sibling (e.g., get_tasa_hoy) it should be preferred over.

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 says what the tool computes but never states when to choose it over the many sibling rate/convert tools (get_tasa_hoy, get_curva_tiie, etc.). The 28-day horizon implies a use case for CETES investment estimates, but no explicit when/when-not guidance is provided.

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?

No annotations are provided, so the description carries the full disclosure burden. 'en un lote' hints that all tenors come back in a single batched call, which is useful, but nothing is said about data freshness, source, units, or error conditions for a rate-fetch tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact phrases, front-loaded with the resource name and immediately followed by scope. No filler, though the heavy abbreviation ('fondeo') borders on cryptic rather than concise.

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 zero-parameter read tool with no output schema, the description effectively substitutes for the missing return spec by listing the exact tenors returned (1d, 28, 91, 182). The only gap is the absence of format/freshness details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the schema is trivially complete. Baseline 4 applies for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource (TIIE curve) and enumerates its scope (1d overnight plus 28/91/182 tenors returned in a batch), which distinguishes it from siblings like get_tasa_hoy that return a single current rate. The bilingual phrasing is terse but unambiguous about what is fetched.

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 guidance, no prerequisites, and no named alternative. The agent must infer that this is the tool for multi-tenor TIIE term-structure data versus the single-rate siblings.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a historical read operation but omits permissions, rate limits, timezone, date inclusivity, and any mutation/read safety 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?

The description is very short and front-loads the currencies and date range. The Spanish and English currency lists are partially redundant, but there is no wasted sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-date range tool with no annotations, no output schema, and bare parameter schema, the description is underspecified. It does not state what is returned (e.g., MXN-based rates per currency), date inclusivity, or error behavior.

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 the parameter titles are only 'Fecha Ini' and 'Fecha Fin'. The description supplies the required yyyy-MM-dd format, which adds useful meaning, but does not clarify inclusivity, timezone, or start/end semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names specific currencies (EUR/JPY/GBP/CAD) and a date range, which identifies the resource clearly. It distinguishes from get_dolar_hoy (today's dollar) and partially from get_tasas_rango by restricting to four currencies, though it lacks an explicit verb.

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 provides no when-to-use guidance, alternatives, or exclusions. It only states the currencies and date format, leaving the agent to infer why to choose this over get_tasas_rango or get_dolar_hoy.

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?

No annotations exist, so the description carries the full burden. It does disclose the return content (FIX plus DOF rates and a 30-day window), which is genuinely useful, but says nothing about data freshness, update timing, or whether the call is a pure read.

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?

Extremely short and front-loaded, with the key facts (dollar, today, FIX+DOF, 30d) in the first clause. The full bilingual restatement roughly doubles the length for no added information, which is the only structural waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and zero parameters, the description is the only documentation. It covers what data sources are returned but leaves 'contexto 30 dias' ambiguous (does it return a 30-day series or just compare against it?) and gives no freshness or update-frequency information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to clarify about inputs. The description's mention of '30 dias' is arguably a hidden behavior rather than a parameter, so it does not lower this score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource (USD/MXN dollar today) and even the two data sources it draws on (FIX and DOF), which is more than most sibling names reveal. It lacks a verb and does not explicitly contrast itself with get_divisas_rango or get_tasas_rango, so it is clear but not fully disambiguated from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer 'call this when you need today's dollar rate.' There is no statement of when to prefer it over get_divisas_rango (other currencies) or why the built-in 30-day context should be used instead of a range 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?

No annotations are provided, so the description carries the full behavioral burden. It conveys the semantic nature of the value (a specialist forecast, year-end horizon), which is useful, but says nothing about whether it is a read-only lookup, its return shape, caching, or data freshness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no waste, appropriately sized for a zero-parameter lookup. The bilingual restatement adds a little redundancy but no real bloat.

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 simple zero-param read tool this is mostly sufficient, but with no output schema the description never indicates what the returned value looks like (rate, percentage, series, units) or its horizon precision, leaving an inference gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond confirming no inputs are needed.

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: inflation expected by specialists at year-end, which is a distinct data series from the sibling actual-inflation tools (get_inflacion_udis, get_inflacion_ytd). It does not explicitly name a sibling or contrast itself, 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?

No when-to-use guidance and no named alternatives. The agent must infer from the name alone that this returns a forecast series rather than realized inflation, and nothing tells it when this is the right tool versus get_inflacion_ytd or get_inflacion_udis.

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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no auth requirements, no units or currency, no indication of whether the returned figures are aggregated, rates, or totals. The only concrete behavior conveyed is the date-range scoping.

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?

Very compact and front-loaded: metrics first, then the range constraint and format. The slash-separated bilingual fragment is slightly cryptic but there is no wasted prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema and 0% parameter coverage, this tool needs more than a terse fragment. An agent cannot tell what the response contains, in what units, or what constraints the date range carries, leaving meaningful gaps for a data-retrieval 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% and both fecha_ini/fecha_fin are undocumented in the schema, so the description must compensate. It does usefully supply the expected date format (yyyy-MM-dd) and implies the pair forms an inclusive range, but adds nothing about which ranges are valid or what the boundaries mean.

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 concrete resource and scope — public finance data covering Gasto, ISR, IVA and IEPS over a date range — which is clearly distinct from siblings like get_tasa_hoy, get_dolar_hoy or get_udis_hoy. It lacks an explicit verb, but the metrics and domain make the purpose 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?

It specifies a date range but gives no guidance on when to prefer this tool over alternatives or what prerequisites apply. There is no mention of when-not to use it, nor any reference to sibling tools covering other financial indicators.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the output is a % variation acting as an inflation proxy, but says nothing about date handling, whether the period bounds are inclusive, auth requirements, or what the response contains. This is a thin disclosure for a tool with zero annotation 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?

A single compact sentence with the core meaning front-loaded and zero padding. The duplicated English gloss adds little for an API whose parameters are already Spanish, but it is a minor cost.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, no annotations, and 0% parameter coverage, the description should explain the return shape and date format. It leaves the two required parameters, the return value, and the period semantics entirely to inference.

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 required parameters, so the description must compensate and does not. It implies the two dates frame a period, but adds no date format (ISO vs DD/MM/YYYY), ordering rules, or boundary semantics for fecha_ini and fecha_fin.

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 (UDIS), an operation (percentage variation over a period), and adds interpretive framing (inflation proxy), which lets an agent distinguish it from get_udis_hoy and get_inflacion_ytd. It is clear, though the bilingual repetition and terse notation keep it from being maximally crisp, and it never explicitly names the sibling it is not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no exclusions, and no reference to alternative tools such as get_inflacion_ytd or get_udis_hoy. The agent must infer from the phrase 'en periodo' alone that this is the ranged option.

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?

No annotations are provided, so the description carries full burden. It does add the useful basis of calculation ('UDIS 1-ene a hoy'), implying a read-only, single-value snapshot, but it never states the return unit (percentage vs. index) or format. Adequate but incomplete for a description with zero structured behavioral support.

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 bilingual lines that are front-loaded and easy to scan. The phrase 'en un clic' is mild marketing filler that doesn't add informational value, preventing a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should clarify what the caller actually receives (e.g., a percentage figure for the year to date). It states the concept and window but leaves the returned value's form implicit, which is a real gap for a zero-param call with no schema to fall back on.

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 per the rubric the baseline is 4. No parameter semantics are needed or missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Inflacion acumulada del anio' / year-to-date inflation) with a concrete calculation window (UDIS 1-ene a hoy), so the resource is unambiguous. However, it does not distinguish itself from close siblings like get_inflacion_udis or get_expectativa_inflacion, leaving the agent to infer how this differs.

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 only asserts what the tool returns; it gives no when-to-use context, no prerequisites, and never names the alternative tool for a different inflation view. The agent must guess between get_inflacion_ytd, get_inflacion_udis and get_expectativa_inflacion on its own.

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

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

No annotations are provided, so the description carries the burden. It does disclose the shape of the payload (weekly and annual variation of reserves), which is useful beyond the name, but it says nothing about update frequency, source (e.g., central bank), units, or currency of the series.

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 short, front-loaded statement that conveys the resource and its variations immediately. The bilingual duplication ('/ FX reserves') is mildly redundant but negligible in length.

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 parameterless data tool with no output schema or annotations, the description covers what the tool returns in broad terms but omits key operational details: data source, units, frequency of refresh, and historical depth. An agent can call it, but cannot fully anticipate the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly implies no inputs are needed.

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 data resource (international/FX reserves) and its content (weekly and annual variation), which clearly distinguishes it from sibling rate/inflation/FX-quote tools such as get_dolar_hoy or get_divisas_rango. It does not name an alternative tool, but the resource itself is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the other 16 financial-data siblings, nor any stated context about scope (national reserves? which country/period?). For a zero-argument data fetch the risk is low, but the agent gets no usage signals at all.

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?

No annotations are provided, so the description carries the burden, and it does disclose the returned content (current value + last increment). However, it says nothing about freshness/update cadence, units or currency, or whether the increment includes an effective date, which are the traits an agent would want for a data tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short bilingual clauses, front-loaded with the resource and then the extra payload. Nothing is wasted and the format is scannable.

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 zero-parameter, no-output-schema fetch, the description is nearly sufficient: it says what comes back. The only gap is that return semantics (units, currency, effective date of the increment) are not stated and there is no output schema to fall back on.

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 and the schema is trivially complete, so there is no parameter semantics for the description to add. Baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (minimum wage) and the exact payload (current value plus the most recent increment), which is concrete enough to distinguish it from the FX/inflation/UDI siblings. It stops short of naming any sibling or scope constraint, so it is clear but not sibling-differentiating beyond the topic itself.

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 statement, but the topic is unique among the siblings (none of the other tools cover wages), so usage is implied by the description alone. No prerequisites or exclusions are given, which is acceptable for a zero-parameter read.

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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: no auth requirements, no rate limits, no indication of whether results are paginated or how monthly aggregation is applied. The agent has no behavioral signal at all.

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 short, but shortness here reflects under-specification rather than economy. The two slash-separated fragments ('SPEI mensual en rango' and 'SPEI transfers') are redundant and ambiguous rather than front-loading a clear purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and 0% schema coverage on both required params, the description needed to carry the whole load. It leaves the metric being returned, the aggregation semantics, and the date-bound conventions entirely undefined.

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 only supplies a partial format hint ('yyyy-MM-dd') for the date range; it does not clarify which bound is start vs end, inclusive/exclusive semantics, or acceptable date ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (SPEI) and hints at a monthly, range-based query, but 'SPEI mensual en rango' / 'SPEI transfers' never says what is actually returned (transfer volume? amount? count?). It is close to a restatement of the name rather than a statement of purpose.

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 guidance on when to use this tool versus siblings such as get_divisas_rango, get_tasas_rango or get_dolar_hoy. The date-range constraint is implied by 'en rango' but there is no when/when-not or 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?

No annotations are supplied, so the description carries the full burden; it discloses what data comes back (target rate plus three TIIE/Cetes tenors), which is the most useful behavioral fact here. It says nothing about read-only nature, units, timezone of 'today', data source, or freshness — gaps that a no-annotation tool should ideally fill.

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 clauses, front-loaded with the resource and its contents, with no filler. The Spanish/English duplication is mild redundancy but aids cross-language matching.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description is the only place return shape and behavior could be explained; it names the series but not units, currency, or the exact date semantics of 'today'. Adequate for a simple lookup, but not fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a 0-param tool applies. 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?

States a specific verb (get) and resource (reference rates for today) and enumerates the exact series: objetivo, TIIE 28/91, Cetes 28. The 'hoy' scope implicitly separates it from the sibling get_tasas_rango, though the description never names that alternative 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?

Usage is only implied by the temporal qualifier 'hoy' — the agent can infer this is the current-snapshot tool versus get_tasas_rango for history, but there is no explicit when-to-use, when-not-to-use, or named 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?

No annotations are provided, so the description carries the full burden. It does disclose one meaningful behavioral constraint the schema lacks: the 365-day maximum range. Beyond that it says nothing about return format, spread calculation basis, auth requirements, or error behavior, leaving significant gaps.

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 compact bilingual phrases, front-loaded with the resource and the key constraint. Every element earns its place, though the duplicated Spanish/English text is slightly redundant for an agent.

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 simple 2-param range tool with no output schema and no annotations, the definition covers the essentials (what it returns, the range cap, date format) but omits when-to-use guidance and any return-shape hints. Adequate but with clear gaps given the absent structured metadata.

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% for the two required date parameters, so the description must compensate. It does add the expected date format (yyyy-MM-dd) and implies the range semantics, which is useful. However, it does not clarify the inclusive/exclusive bounds of fecha_ini/fecha_fin or the 365-day limit's effect per parameter, so 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?

The description states a specific verb+resource: retrieving rates over a date range plus the TIIE-Cetes spread, which distinguishes it from get_tasa_hoy (single day) and get_divisas_rango (FX). It is terse and bilingual but the core purpose is identifiable. It does not, however, explicitly differentiate from other rate/curve siblings like get_curva_tiie.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling is named. The 'max 365d' note is a constraint on input rather than guidance about choosing this tool over get_tasa_hoy or get_curva_tiie. Usage must be inferred from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one useful behavioral quirk — the value may correspond to a future official date — but says nothing about return format, units, or update cadence.

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?

Extremely short and front-loaded, with the key concept first. The bilingual restatement is redundant but harmless, and nothing is padded.

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 zero-parameter, no-annotation, no-output-schema tool, the description conveys the core meaning and one quirk, but omits the value's format/units (e.g., MXN per UDI) that an agent would need to interpret the result.

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 nothing for the description to clarify beyond what the empty schema already conveys.

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 (get) and resource (UDIS value) with the scope 'latest/timely'. An agent can tell it retrieves the current UDIS figure, but nothing distinguishes it from siblings like get_inflacion_udis, ajustar_por_udis, or convertir_udis_a_pesos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no alternatives named among the many UDIS-adjacent siblings. The parenthetical about a future official date is a data nuance, not routing guidance.

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