cattle-market

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

With no annotations, the description fully bears the burden of behavioral disclosure. It mentions 'ranking de actividad' and 'cabezas operadas y precio promedio' but fails to specify ordering (by volume or price), data freshness, possible result limits, or even that the ranking is descending. This lack of behavioral cues for a ranking tool with no annotations is a notable gap.

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

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

Two sentences with front-loaded purpose: first sentence states what the tool does with critical market context, second clarifies scope. No wasted words, but could be slightly more structured (e.g., bullet points for parameters).

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 output schema and 4 optional parameters, the description provides essential market context (reference vs national) and clarifies the metric. However, it misses details like whether the ranking covers daily or period data, if it's sorted, or what 'actividad' encompasses beyond heads and price. Adequate but not fully complete for an agent with no further 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 coverage is 100% (all 4 parameters documented), so baseline is 3. The description adds no additional semantic detail for any parameter beyond what the schema already provides. It mentions 'un período' generally but doesn't connect to the 'desde'/'hasta' parameters or add usage hints.

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?

Description clearly states the tool provides a ranking of consignataria activity (heads operated and average price) in the Cañuelas reference market, explicitly differentiating it from national totals. This verb+resource+scope specification distinguishes it from sibling tools like buscar_consignataria or get_precios_detallados.

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?

Description explains when to use (needing reference market data) and when not (seeking national totals) by stating this is the reference market, not national. However, it does not explicitly name alternative tools for the latter use case, though the context is clear enough for an agent to infer.

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 description discloses the dual behavior based on the presence of the tema argument, which is key to understanding how the tool behaves. Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description does not contradict them. It adds value by explaining the source and voluntary nature, though it does not mention the openWorldHint.

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

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

The description is two sentences long, front-loading the full name and source, then efficiently covering the two usage modes and cross-referencing sibling tools. Every sentence earns its place without redundancy.

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 the simple parameter and no output schema, the description adequately explains what the tool returns—either a list of 14 topics or implementation details (sections and practices). It also provides the source and clarifies the voluntary scope, making it complete for an agent to understand and use 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 100%, and the schema already describes the parameter's behavior (e.g., 'sin este arg lista los 14'). The description repeats this and adds 'con un tema, devuelve cómo implementarlo', which adds a little extra context, but not enough to raise the score above baseline.

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

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

The description clearly states that the tool lists 14 topics related to good livestock practices or returns implementation details for a given topic. It distinguishes from sibling tools by specifying that mandatory sanitary information should be obtained from sanidad_plan or sanidad_requisitos_movimiento.

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 explicitly explains two usage modes: without argument (list all 14 topics) and with argument (return implementation details). It also advises when to use alternative tools for mandatory sanitary information, providing clear context for selecting the right 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?

The description mentions the tool returns specific fields (name, location, category, contact, profile URL), but there are no annotations provided. It does not disclose behavioral traits like authentication requirements, rate limits, or data freshness. The description partially covers behavior but is minimal.

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 concise with two sentences, no unnecessary words, and clearly structured to convey purpose and return values. Every part adds value.

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 search tool with three parameters and no output schema, the description provides clear purpose and return fields. It could mention pagination or default limit, but the schema already covers 'limite' default. Overall adequately 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 coverage is 100% with descriptions for all three parameters. The description largely repeats the schema's parameter descriptions (e.g., query can be name, locality, business name). It adds no additional semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'Busca' (search), the resource 'consignatarias/casas de remate', and the search criteria (name, locality, province). It also lists the returned fields, distinguishing it from sibling tools like buscar_frigorifico.

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 explicit guidance on when to use this tool versus alternatives or when not to use it. While the sibling tools have different purposes, the description lacks context-specific usage instructions.

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 states 'Busca frigoríficos habilitados' (a read/search operation) but does not disclose behavioral traits such as authentication needs, rate limits, or what happens if no results are found. The description lacks detail on the nature of the operation (e.g., non-destructive).

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 (two sentences, one a fragment) and front-loaded with the main action. However, there is slight redundancy between the two sentences. It is efficient but not maximally 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 simple search tool with 3 parameters (none required) and no output schema, the description provides adequate context: search criteria, return fields, and a filter. It mentions the scale (1,100+ plants). Missing guidance on when to use vs. other search tools, but overall complete for its complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds some context by stating search criteria (name, province, CUIT) and the province filter, but does not significantly augment the schema's parameter descriptions. The limite parameter is not elaborated beyond the schema.

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

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

The description clearly states the tool searches for registered meatpacking plants (frigoríficos) by name, province, or CUIT, and returns specific fields. It is distinct from sibling tools like buscar_consignataria, but does not explicitly differentiate 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?

The description implies usage for searching by name, province, or CUIT, but does not provide guidance on when to use this tool versus siblings (e.g., buscar_consignataria) or when not to use it. No explicit alternatives or prerequisites are mentioned.

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, description carries full burden. It discloses the formula, default index, and fallback. Missing details on potential errors (e.g., if both indexes unavailable) but sufficient for a calculation 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 sentences, no wasted words, front-loads purpose and formula. Efficient and clear.

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 simple calculation, 3 params, no output schema, description fully explains formula, defaults, and fallback. Sufficient for agent to use 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 has 100% coverage; description adds value by providing typical range for kg_ha (3-6) and clarifying price default. Reinforces schema info concisely.

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 tool calculates a specific rural lease fee in pesos using a formula with kg per hectare, hectares, and price. It distinguishes from siblings by focusing on a specific calculation, not searching or listing.

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

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

Explains when to use (calculate lease fee) and describes default behavior with official index and fallback. Does not explicitly state when not to use or mention alternatives, but context is clear.

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?

Sin anotaciones, la descripción asume toda la carga de transparencia. Detalla que la operación crea una alerta, requiere autenticación, y que al cruzar el umbral se envía un POST a una URL webhook. También explica dos métodos de autenticación. Falta mencionar efectos secundarios como duplicados, pero es aceptable.

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?

La descripción es concisa: cuatro oraciones que cubren propósito, requisitos, autenticación y obtención de clave. No hay redundancia ni información innecesaria. La información más importante aparece primero.

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?

Para una herramienta con 5 parámetros, 3 requeridos y sin esquema de salida, la descripción cubre los aspectos clave: qué hace, cómo autenticar, unidades de umbral y destino del webhook. Faltaría mencionar el formato de la respuesta (ej. éxito/error), pero no es crítico para la operación.

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?

Aunque la cobertura de descripción del esquema es alta (80%), la descripción agrega valor significativo: especifica que 'umbral' está en ARS/kg vivo, que 'api_key' es opcional si se pasa por header, y proporciona la URL para obtener la clave. También aclara el evento del webhook. Esto va más allá del esquema.

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?

El nombre y la descripción indican claramente que la herramienta crea una alerta de precio por umbral. Se especifica el recurso (alerta de precio) y la acción (crear), además de detallar el comportamiento cuando se cruza el umbral y la notificación por webhook. No hay herramientas hermanas similares, por lo que se distingue fácilmente.

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?

La descripción proporciona instrucciones claras sobre cuándo usar la herramienta (para crear alertas de precio por umbral) y los requisitos (API key de plan Enterprise, autenticación por header o parámetro). Aunque no menciona alternativas explícitas, no existen herramientas hermanas con funcionalidad similar, por lo que la guía es suficiente.

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 description discloses the exact data points returned (dollar rates, corn price, spread), but does not state that the tool is read-only or discuss any side effects. There are no annotations to contradict, and the description is sufficient for a simple data retrieval 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?

The description is a single sentence, efficiently conveying the tool's purpose and outputs. It is front-loaded with 'Contexto macro del mercado ganadero argentino' and includes necessary detail without extraneous 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?

Given the tool has no parameters and no output schema, the description fully explains the returned data. It lists all key indicators and explains the spread, leaving no ambiguity about what the tool provides.

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 input schema has no parameters, so description does not need to add parameter meaning. The baseline for zero parameters is 4, and the description appropriately focuses on what the tool returns.

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 specifies the tool returns macro context of the Argentine livestock market, listing specific indicators (dollar rates, corn price, steer/corn spread). It distinguishes itself from sibling tools by focusing on macro context rather than individual prices or indices.

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 guidance on when to use this tool versus alternatives. It doesn't mention common use cases, prerequisites, or conditions where other tools might be preferred.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds value by specifying data sources (MAGyP, IPCVA), frequencies (monthly, trimestral), and the structural caveat about Cañuelas vs. national. No contradictions with annotations.

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

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

The description is a single paragraph that front-loads the key purpose and output. It is informative without excessive verbosity, though it could be slightly more concise by removing some parenthetical repetitions.

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 output schema, the description adequately explains the return values (Cañuelas fresh reading, national YTD anchor, historical national female slaughter). It covers sources, frequency, and interpretation caveats. Could specify data format or recency more precisely.

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?

Tool has zero parameters, so baseline score is 4. The description correctly states 'Sin args' (no args) and does not need to add parameter 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?

The description explicitly states the tool provides the 'Índice de Liquidación (% hembras)' with a clear verb ('Devuelve'), resource ('lectura fresca de Cañuelas'), and scope. It distinguishes itself from sibling tools like get_indice_novillo by focusing on female participation as an adelantado indicator.

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 explains the tool has no arguments and details the output components (Cañuelas data, national YTD anchor, historical series). It provides guidance on interpretation, warning that Cañuelas runs above national slaughter and not to compare 1:1. However, it does not explicitly state when to prefer this tool over siblings like get_indice_novillo.

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 full burden. It discloses that the tool returns price, variation, volume, and trend, is daily, and volume-weighted. It does not mention authentication or rate limits, but the nature is read-only and such details are not critical for a simple data retrieval 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 sentences efficiently convey the tool's purpose, data provided, and differentiation from a sibling tool. No redundant 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?

Given no parameters, no output schema, and no annotations, the description sufficiently explains the tool's purpose and output. It could be improved by specifying if the data is for the current date only, but 'hoy' implies that. Overall, it provides enough context for an agent to decide to use it.

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

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

The tool has zero parameters, so baseline is 4. The description adds value by explaining what data is returned (price, variation, volume, trend) and the index characteristics, which goes beyond the empty 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 states the tool returns the Índice Novillo (INMAG) reference price today in ARS/kg live weight with daily variation, volume, and trend. It distinguishes itself from sibling tool get_precios_hacienda, which provides weekly category prices.

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 explains that this tool gives a daily volume-weighted index from the formal MAG channel, contrasting it with get_precios_hacienda's weekly observations. This provides clear context for when to use this tool, though it doesn't explicitly list when not to use it or name alternatives beyond one sibling.

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 lists return fields but does not disclose behavioral traits such as data freshness, error handling, or side effects. The description adds minimal insight beyond the return schema.

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

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

The description is concise with two sentences, front-loading the main purpose and output. No redundant information, but could be slightly more structured with visual separation.

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 tool with one parameter and no output schema, the description covers purpose, output, and use case. However, it lacks examples, edge case behavior, and prerequisites, making it adequate but not fully comprehensive.

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

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

Schema coverage is 100%, and the description does not add information beyond the schema's parameter description. Baseline 3 is appropriate as the schema already documents the parameter adequately.

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 tool returns historical evolution of the INMAG index in ARS/kg vivo, including specific metrics (initial/final value, variation, min/max, sample). It distinguishes from siblings like 'get_indice_novillo' by focusing on historical 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?

The description indicates the tool is for trend analysis ('Sirve para tendencia'), providing clear context. However, it does not explicitly mention when not to use or compare to alternatives like 'get_indice_novillo'.

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, description carries full burden. It discloses output format (min, avg, max, units) but does not explicitly state read-only nature or any safety implications. Adequately transparent but could be more explicit.

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 core purpose, no wasted words. Every sentence adds value.

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, but description details return values (min, avg, max, units) and provides examples. Covers the tool's functionality adequately for its complexity (1 param, no nested objects).

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 0%, but description compensates by explaining the optional group filter and listing enum values. Adds meaning beyond raw schema by clarifying purpose and optionality.

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?

Description clearly states it retrieves prices by subcategory from Mercado Agroganadero with min, avg, max in ARS/kg live weight. It explicitly distinguishes itself from sibling get_precios_hacienda by noting higher 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?

Describes when to use (more granular than get_precios_hacienda) and mentions optional filter. Lacks explicit when-not-to-use or alternative tools beyond one sibling, but context is clear.

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 provided, so description carries full burden. It adds the weekly frequency and data source, but does not state rate limits, authentication needs, or what happens with invalid categories (though schema handles via enum). Still, the transparency is high.

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, no wasted words. The purpose is stated first, followed by a clear usage distinction. Perfectly concise and structured.

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 the tool has only one optional parameter, no output schema, and no annotations, the description covers all necessary aspects: purpose, parameter meaning, default, time resolution, source, and differentiation from a sibling. Completely adequate.

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 has 0% description coverage for the parameter. The description lists all enum values and explains that omitting the parameter returns all categories, fully compensating for the lack of schema documentation.

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 it returns livestock prices by category in ARS/kg live weight, weekly observation from SIO/Mercado Agroganadero, and distinguishes from the daily index (get_indice_novillo).

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 states the time resolution (weekly), contrasts with the sibling tool (daily index), warns against direct comparison, and explains default behavior (returns all categories when no argument).

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, yet the description does not disclose any behavioral aspects such as read-only nature, side effects, or required permissions. The lack of safety information is a gap.

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

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

The description is only two sentences, concise and front-loaded with the main purpose. It efficiently covers filters and return information without unnecessary words.

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?

Without an output schema, the description adequately describes return fields. However, it omits potential details like pagination, ordering, or performance considerations.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds value by mentioning optional filters and listing return fields, but does not enhance parameter meaning beyond the schema.

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

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

The description clearly states the tool lists upcoming livestock auctions in Argentina and specifies optional filters (province, limit) and return fields (date, auctioneer, location, category, live transmission). It distinguishes itself from sibling tools that focus on searching or calculating other aspects.

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 to use (to get upcoming auctions) but does not provide explicit guidance on when not to use or how it compares to siblings like 'buscar_consignataria' or 'get_precios_hacienda'.

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 description adds that the tool never invents a day, aligns with readOnlyHint and idempotentHint annotations, and clarifies the nature of the data (windows and citations), going beyond annotations.

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

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

The description is two sentences, front-loaded with key details (year, resolution), and every sentence adds value without redundancy.

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?

Despite no output schema, the description fully explains the return structure (campaign windows, zone status, note about exact day) and is complete for a simple tool with one optional 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?

With 100% schema description coverage, the parameter's meaning is clear from the schema, and the description reiterates it but does not add significant new 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?

The description clearly states the tool returns the aftosa vaccination calendar for 2026 with campaign windows and zone status per province, distinguishing it from sibling tools like sanidad_plan or sanidad_renspa.

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 context implies when to use (e.g., for aftosa calendar info), but there is no explicit guidance on when not to use or alternatives, such as comparing with other sanidad tools.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds context that it does not emit or consult a real DT-e and is purely reference, which provides behavioral clarity beyond the annotations.

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

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

The description is highly concise: two sentences that front-load the core purpose and immediately clarify what the tool does not do. No unnecessary words.

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 that the tool has no parameters, no output schema, and annotations cover safety, the description completely covers the necessary context: what it explains, requirements, limitations, and link to sibling 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?

There are no parameters in the input schema, so the description does not need to add parameter semantics. The baseline of 4 is appropriate as the description is not required to compensate for missing parameter information.

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 it explains the DT-e concept, requirements, and linkage. It specifies the verb 'explica' and the resource 'DT-e', and distinguishes itself from the sibling tool sanidad_requisitos_movimiento by stating it does not emit or consult a real DT-e.

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 explicitly says when to use (for reference about DT-e) and when not to use (no actual emission/consultation). It provides a clear alternative: 'Para el detalle de requisitos por movimiento usá sanidad_requisitos_movimiento'.

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 readOnlyHint, openWorldHint, idempotentHint, destructiveHint are already present. The description adds that this is regulatory cited information, not operational, which aligns with annotations and provides useful context beyond them.

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, each earning its place: explains what it is, what it returns, behavior without argument, and usage guidance versus a sibling tool. No redundancy.

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 tool with one optional parameter and no output schema, the description adequately explains return fields and behavior. It covers the key information needed by an AI agent. Could mention error handling but not essential.

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 single parameter (enfermedad) is fully described in the schema with enum values. The description adds valuable information: without the argument, it returns all 4 plans, which is not in the schema. Also lists the diseases explicitly.

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 it is a fact sheet for SENASA mandatory livestock health plans, lists specific diseases (aftosa, brucelosis, tuberculosis, garrapata), and specifies what data it returns (agent, regimen, categories, zoonosis, resolutions). It distinguishes itself from sibling tools like sanidad_requisitos_movimiento by stating it is not for moving cattle.

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 states when to use (to consult a specific plan or list all 4) and when not to use ('para mover hacienda usá sanidad_requisitos_movimiento'). Provides clear guidance on behavior without argument.

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 indicate read-only and idempotent behavior; the description adds that the tool does not consult live databases and explains what it returns, complementing the annotations well.

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 action and format, then a clear limitation. No wasted words.

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 output schema, the description adequately explains return segments and limitations. Covers validation, decoding, and live-check exclusion, making it complete for this 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 100%, but the description adds meaning by explaining the expected format (17 characters with dots) and the segments decoded, going beyond the schema.

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

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

The description clearly states it validates and decodes a RENSPA code, detailing the format and segments, and distinguishes from sibling tools by its specific function.

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 states it does not check live validity and directs users to the official public consultation, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral context: it informs requirements, does not emit DT-e (requires SIGSA/ARCA), and conditionally checks barrier crossing. No contradictions.

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 well-structured sentences: first lists requirements, second explains conditional behavior and what the tool does not do. No wasted words, front-loaded with actionable info.

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?

Despite no output schema, the description explains the return information (requirements list, barrier crossing status). It covers input behavior, limitations, and prerequisites. Complete for a 2-param optional 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 has 2 optional string parameters with descriptions. The description adds meaning: if both province parameters are provided, it signals if movement crosses the aftosa barrier. This enriches the schema's existing descriptions.

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 it provides SENASA health requirements for moving bovine livestock, listing specific requirements (RENSPA, DT-e, aftosa, brucelosis, etc.) and indicating what it does NOT do (emit DT-e). It distinguishes from sibling tools like sanidad_dte_tropa and sanidad_renspa.

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 indicates when to use: to get requirements for moving cattle, and to check if crossing the aftosa barrier. It also clarifies what it does not do (emit DT-e), providing implicit guidance on alternatives.

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