Datos UY/AR

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 does disclose two useful traits: the boundary is inclusive ('a partir de una fecha (inclusive)') and the default is today when no date is given. It says nothing about timezone, what happens when no upcoming holiday exists, or the response shape, leaving meaningful gaps for an unannotated 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 tight sentences with the core purpose front-loaded and the default behavior appended; nothing is wasted. It is close to optimally concise, though the trailing 'y días restantes' is slightly ambiguous about whether it refers to input 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?

Complexity is low (one optional parameter), but with no output schema and no annotations the description should say more about what is returned. 'Días restantes' hints at output content but is ambiguous, and return format/default-when-none remain unstated.

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 the single parameter's meaning ('a partir de una fecha') and that the boundary is inclusive, plus the default (today). It does not restate the YYYY-MM-DD format, but the schema's regex pattern already covers that.

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

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

The description states a specific verb and resource: retrieve the next Argentine national holiday. 'Próximo' scopes it against the broader sibling ar_feriados (which presumably lists all), so an agent can distinguish the two. It stops short of naming the 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?

'Sin fecha: hoy' clarifies the behavior when the optional parameter is omitted, giving implied usage guidance. However, there is no explicit when-to-use-this-vs-ar_feriados routing statement, only the implicit 'próximo' scoping.

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 usefully discloses the official data source and the bounded set of supported years, but says nothing about return format, ordering, caching, or how filtered results behave when no holiday matches.

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

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

Two tight sentences with no filler, front-loading the resource and its scope. The available-years constraint follows immediately, so the most actionable detail appears early.

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 3-param lookup tool with no output schema or annotations, it covers source, year range, and type vocabulary. The omission of mes semantics and any description of the returned holiday records leaves gaps 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 description coverage is 0%, so the description must compensate for all three parameters. It clarifies anio (years 2025/2026) and restates the tipo enum values, but the mes parameter is never mentioned and no format/semantics are given beyond the schema's numeric bounds.

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: national Argentine holidays by year, sourced from the official argentina.gob.ar site. It is clearly distinguishable in intent from sibling ar_feriado_proximo (next holiday), though it 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?

It discloses hard usage constraints — only years 2025 and 2026 are available — which tells the agent when the call will succeed. However, it gives no explicit when-to-use/when-not guidance or routing to the 'proximo' sibling for upcoming-holiday queries.

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. It usefully discloses the side-effect-free trait "No consume cuota," which is exactly the safety information an agent needs for a quota-check tool, but it says nothing about auth requirements, rate limits, or behavior when quota is exhausted.

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: the purpose first, the cost profile second. No padding, and the most decision-relevant fact (it is free to call) is front-loaded after the 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?

For a zero-parameter tool with no output schema, the description effectively tells the agent what comes back (a count of remaining free calls for today). The main missing piece is what the result looks like when the quota is exhausted or how "this cliente" is identified.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to disambiguate beyond the implicit "this cliente" scoping.

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 ("Muestra") and a specific resource ("cuántas llamadas gratis quedan hoy para este cliente"), so an agent knows exactly what it retrieves. It does not need to name siblings because the surrounding tools (holidays, quotes, RUT) are clearly a different domain, though it also makes no explicit differentiation.

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 daily scope ("hoy") and the note "No consume cuota" imply when to call it (a cheap pre-flight quota check before spending calls), but there is no explicit when-to-use/when-not guidance or named alternative. Usage is inferable rather than spelled out.

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 must carry the full behavioral burden. It discloses key traits: default currencies, behavior without date (last close), and restriction to business days. However, it omits whether results are read-only, return format, pagination, rate limits, or error handling, leaving gaps for a tool with no annotation 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?

The description is front-loaded with the core purpose and key details, followed by parameter-related information and temporal behavior. It is appropriately sized for the tool's complexity, though the long currency list could be seen as slightly dense, but it is necessary given the lack of schema documentation.

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 no annotations, no output schema, and 0% schema coverage, the description covers essential aspects like default currencies and date behavior. However, it lacks information about return values, error cases, or authentication needs, leaving it incomplete for a tool that must rely solely on the description for behavioral guidance.

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 provides detailed semantics for the 'monedas' parameter by listing all valid currency codes, but it does not explain the 'fecha' parameter's format beyond what the schema pattern implies, nor does it clarify that 'fecha' expects YYYY-MM-DD. Still, the currency enumeration adds significant meaning.

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

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

The description states a specific resource: 'Cotizaciones oficiales del BCU en pesos uruguayos (compra/venta)', clearly identifying official BCU exchange rates. It distinguishes itself from siblings like uy_ui (which likely handles UI only) by listing multiple currencies. However, it doesn't explicitly contrast with siblings like ar_feriados or cuota, leaving some ambiguity about scope.

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 usage through examples ('Default USD, EUR, ARS, BRL') and temporal behavior ('Sin fecha: último cierre publicado. Solo días hábiles'), but it does not explicitly state when to use this tool versus alternatives or mention prerequisites. The context is implied rather than spelled out.

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 discloses the computed result ('feriado nacional ... y días restantes') and the date-inclusive semantics, implying a read-only lookup, but says nothing about the data source, update cadence, or what fields come back.

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, no filler, and the core operation is front-loaded with the default behavior trailing in four words. Nothing needs trimming.

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 say more about the response — whether it includes the holiday's name, its date, and how 'días restantes' is counted. For a single optional-parameter lookup it is adequate, 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?

Schema coverage is 0%, so the description must compensate and partly does: it defines 'desde' as inclusive and specifies today as the fallback when omitted. It does not restate the YYYY-MM-DD format, though the schema pattern already pins that down.

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: it returns the next Uruguayan national holiday from a given date, plus remaining days. The 'próximo' framing implicitly separates it from uy_feriados (list), but 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?

The description covers the default case ('Sin fecha: hoy'), which is useful invocation guidance for an optional parameter. It gives no guidance on when to prefer this over uy_feriados or uy_feriados, so usage is only implied.

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 bears the full burden. It helpfully discloses the data's legal basis and the Monday-shift rules (19/4, 18/5, 12/10) plus Carnaval and Semana de Turismo, which is genuine behavioral context. However, it says nothing about read-only nature, output shape, or whether `mes` narrows results.

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

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

A single dense sentence that front-loads what the tool returns and tucks the parameter note at the end. No filler or repetition; effectively sized.

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?

No output schema and no annotations, so the description is the only source of behavioral detail. It covers the calculation basis and one enum, but omits how `mes` affects results and what the returned records look like, leaving gaps for a no-schema 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 must compensate: it defines the `tipo` enum values (pago = no laborable, laborable), which is the most ambiguous parameter. But `mes` (a 1-12 filter) is never explained and `anio` is only implied, 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+resource — national holidays of Uruguay by year — and adds scope (calculated under Law 16.805). This clearly distinguishes the resource, though it never names or contrasts with the sibling uy_feriado_proximo, so sibling differentiation is left implicit.

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

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

The description implies usage (query holidays 'por año', filter by tipo) but gives no explicit when-to-use or when-not-to-use guidance, and does not distinguish this year-list tool from uy_feriado_proximo. Usage is inferable but not 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?

With no annotations, the description carries the full burden and does disclose a critical limitation — it explicitly says it does NOT query DGI and does NOT confirm existence or vigencia, preventing an agent from over-trusting the result. It stops short of describing the return value shape (no output schema exists), so the transparency is useful but not complete.

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, the capability is front-loaded and the limitation follows immediately. No filler.

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

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

For a one-parameter validator with no annotations and no output schema, the description covers scope and the key negative guarantee, but leaves real gaps: the exact accepted input format and what the tool returns on success or failure.

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

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

Schema description coverage is 0% — the single 'rut' parameter has no description, only min/max length. The description partially compensates by stating the expected format (12 digits), but this conflicts with the schema's maxLength of 32, leaving the accepted input format (separators, hyphens) 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?

States a specific verb and resource plus the exact scope: validates format and check digit of a Uruguayan RUT. No sibling in the list (feriados, cotizaciones, ui) does anything comparable, so no differentiation is needed.

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 to validate a RUT) but there is no explicit when-to-use, when-not-to-use, or named alternative. The scope disclaimer 'no consulta a DGI' borders on guidance but describes behavior rather than when to pick this 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?

With no annotations, the description carries the full burden and does add real domain context: the index exists every day including weekends and is published roughly one month ahead, which is critical to knowing which dates are valid. It stops short of stating return format or error behavior for 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?

Three short clauses, front-loaded with the resource definition, followed by availability behavior and the default. No filler sentences.

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

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

No output schema and no annotations, so the description must stand alone; it covers availability, publishing horizon, and the optional-date default well. It leaves the returned value's format and behavior for dates outside the published window unspecified, a minor remaining gap.

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

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

Schema coverage is 0% and the single parameter has only a regex pattern, so the description must compensate; it does so by naming the parameter's meaning (a date) and defining the default when omitted (today). The expected YYYY-MM-DD shape is left to the schema pattern rather than restated, which is acceptable.

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 verb-like retrieval ("Valor de la Unidad Indexada (UI) del BCU para una fecha"), which is immediately distinguishable from siblings like uy_cotizaciones. It does not, however, explicitly distinguish itself from uy_ui_historico, which an agent may reasonably confuse with a single-date lookup.

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 note "Sin fecha: hoy", which tells the agent the parameter is optional and what the default is. There is no explicit guidance on when to prefer this tool over uy_ui_historico for historical queries, so the agent must infer the boundary.

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. It usefully discloses the 366-day maximum and the default-to-today behavior when `hasta` is absent, but it does not mention read-only status, permissions, rate limits, or error handling for out-of-range requests.

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 with zero filler; the core behavior is front-loaded and the default rule follows immediately. 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?

For a simple data-retrieval tool with no output schema and no annotations, the description explains the data and range constraint but does not describe the return shape (e.g., date/value pairs) or error behavior. Adequate to call, but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that two dates define the range, that `hasta` defaults to today when omitted, and that the range is capped at 366 days — adding substantial meaning beyond the bare date-pattern 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 the resource and scope precisely: daily Unidad Indexada series between two dates. The historical nature is implied by the date-range constraint, but the description does not explicitly distinguish this tool from the sibling uy_ui (current value), 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 guidance on when to use this tool versus siblings such as uy_ui or uy_cotizaciones. It only documents the default behavior when `hasta` is omitted, which is a parameter rule rather than a usage rule.

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