cattle-market

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context about time-period aggregation and ranking, which is useful 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?

Extremely concise: two sentences with no waste. Front-loaded with purpose and includes sibling differentiators.

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

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

The description covers input parameters and purpose well. It could mention output format explicitly, but it's implied. Given no output schema, it is sufficiently 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?

With 100% schema coverage, baseline is 3. The description adds defaults (7 days for desde, 15 max 45 for limite) and clarifies the categoria parameter with examples, adding 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 clearly states it ranks consignatarias by heads operated in the MAG market with average price, and explicitly distinguishes itself from siblings like get_precios_hacienda and 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?

It explicitly states when to use it ('para qué firma operó más') and what it does not do (market price, daily index), providing clear alternatives.

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=true and destructiveHint=false, establishing safety. The description adds behavioral context: it explains that the tool returns a list of topics without arguments, and provides implementation details with a topic argument. It also emphasizes the voluntary nature, which is not captured in 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 concise: four sentences covering purpose, behavior, and guidelines. It is front-loaded with the core function, and every sentence adds value. No unnecessary 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?

Given the tool has one optional parameter, no output schema, and annotations handle safety, the description fully covers the tool's behavior: listing topics vs. returning implementation, and differentiating from mandatory alternatives. An agent can confidently select and invoke the tool based on this description.

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

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

The description adds significant meaning beyond the schema: it explains the behavior with and without the 'tema' parameter, gives concrete examples of valid slugs (e.g., 'salud-animal', 'manejo-rodeo', 'agua'), and clarifies the output format. Since schema coverage is 100%, the description enhances usability.

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 provides 'Buenas Prácticas Ganaderas (BPG)' for beef cattle, summarizing the Red BPA (2019) guide. It specifies two modes: listing 14 topics when no argument is given, and returning implementation details when a topic is provided. This differentiates it from sibling tools like sanidad_plan and sanidad_requisitos_movimiento, which are for mandatory health procedures.

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 states when to use the tool (voluntary practices) and when not to use it (for mandatory health requirements), directing the agent to 'sanidad_plan / sanidad_requisitos_movimiento' instead. This provides clear guidance on tool selection.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds useful behavioral context: default and max for results, clarification that it does not provide market activity, and specifics about returned fields. 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?

The description is concise with no fluff. It front-loads the main purpose, provides essential usage details, and ends with a clear exclusion. 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?

Despite no output schema, the description thoroughly describes what is returned (nombre, localidad/provincia, categoría, CUIT, contacto, perfil). With 3 well-explained parameters and clear behavior, the tool is fully specified for correct invocation.

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

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

Schema coverage is 100%, but the description adds constraints not in schema: minimum query length (2 chars), default for limite (8), maximum (25). Also clarifies that provincia is optional.

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 uses a specific verb ('Buscar' meaning search) and resource ('Directorio de consignatarias/casas de remate'). It clearly distinguishes from sibling 'actividad_consignatarias' by stating what it does not do (market activity).

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 (search directory) and when not (for market activity, use actividad_consignatarias). Also includes minimum query length (2 chars) and default/max for limite.

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

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

Las anotaciones ya declaran readOnlyHint=true y destructiveHint=false. La descripción añade valor al especificar que marca las plantas inactivas en SENASA y describe los campos devueltos (nombre, provincia, matrícula, CUIT, ciclo). No contradice las anotaciones.

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 un párrafo bien estructurado que incluye todos los elementos clave: propósito, parámetros, comportamiento y limitaciones. Cada oración aporta información útil, sin repeticiones innecesarias.

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?

La descripción es completa para la complejidad de la herramienta: cubre el origen de datos (1.102 registros), criterios de búsqueda, estructura de respuesta (nombre, provincia, matrícula, CUIT, ciclo, inactivas), restricciones (query o provincia) y límites. Al no haber esquema de salida, la descripción compensa adecuadamente.

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

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

La cobertura del esquema es del 100%, pero la descripción añade información: requiere al menos 'query' o 'provincia' (aclara opcionalidad relativa), y para 'limite' especifica máximo 30 (el esquema solo menciona default 10). Esto supera la línea base de 3.

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

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

La descripción especifica claramente el verbo 'Buscar' y el recurso 'frigoríficos y plantas de faena habilitados', distinguiéndose de herramientas hermanas como 'buscar_consignataria' que se enfocan en consignatarias. Indica explícitamente que no da precios ni faena, diferenciándose de otras herramientas de precios.

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 indica cuándo usar la herramienta (para buscar frigoríficos por nombre, CUIT o provincia) y qué no hace (no da precios ni faena). Aunque no menciona explícitamente alternativas, el contexto de las herramientas hermanas y la frase 'es directorio' guían adecuadamente al agente.

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, and the description adds extra behavioral context: fallback to MAG official index or INMAG when precio_novillo is absent, and the 'Estimación, no asesoramiento' disclaimer. No contradiction 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?

Concise, four-sentence description with formula front-loaded. Every sentence contributes meaning; no redundant or filler content.

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?

Explains return values (mensual, anual, per ha/mes) and fallback behavior, which is crucial since there is no output schema. Slightly incomplete in not addressing potential edge cases, but sufficient for a calculation 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 covers 100% of parameters with detailed descriptions. The tool description adds the formula relating kg_ha, hectareas, and precio_novillo, but this is a minor addition beyond what the schema already provides.

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: 'Calcula el canon de arrendamiento de campo' with a clear formula. Distinguishes from price lookup tools by explicitly saying 'Solo calcula' and referencing get_indice_novillo/get_precios_hacienda.

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?

Provides explicit guidance for when to use alternative price lookup tools ('para consultar precios usá get_indice_novillo o get_precios_hacienda'). However, it does not mention the sibling 'valuar_arrendamiento_campo', leaving potential ambiguity about when to choose this tool over that one.

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 declare readOnlyHint, idempotentHint, and destructiveHint false. Description confirms non-destructive behavior by stating 'NO cobra: devuelve el monto exacto y el endpoint x402 para pagar.' Adds context about currency conversion and product equivalence with /planes.

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?

Single paragraph with clear front-loading of main purpose. Each sentence contributes distinct information. Could be slightly more structured (e.g., separate lines for params) but remains efficient.

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

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

No output schema, but description clarifies output includes exact amount and x402 endpoint. Given low complexity (2 simple params), this is sufficient for an agent to understand and use the 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 covers 100% of parameters with brief descriptions. Description adds value by advising to use 'buscar_consignataria' if slug unknown and specifying valid range for 'meses' (1-12, default 1).

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?

Explicitly states it 'cotiza y explica cómo activar PRO Consignataria pagando en USDC (x402)' and lists included features. References sibling tool 'buscar_consignataria' for slug lookup, differentiating it from other tools.

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?

Instructs to use 'buscar_consignataria' if slug unknown and clarifies that the tool does not process payment. However, it does not explicitly state when to avoid this tool (e.g., if already subscribed or not interested in PRO plan).

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?

Discloses it is a write operation (consistent with annotations), authentication options (no key for free, Bearer/param for Enterprise), and limits (3 alerts for free, unlimited for Enterprise). Could add more on idempotency or duplicate prevention.

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?

Packs essential information into one paragraph without excessive length. Could be improved with bullet points or clearer separation of sections, but remains concise and front-loaded.

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

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

Covers key aspects: purpose, parameters, webhook behavior, pricing, return values (id and price). Lacks error handling or validation details, but overall adequate for a write tool without output schema.

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?

Adds significant meaning beyond the schema: explains categoria frequency (inmag daily vs weekly), direccion default, umbral units (ARS/kg vivo), and api_key placement. Schema coverage is 80%, and description fully compensates.

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 creates an alert for price threshold crossing and notifies a webhook. It distinguishes itself as the only write tool among siblings, which are all read tools.

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?

Provides clear context on when to use (create alerts) and differentiates from read siblings. Mentions free vs Enterprise limits. Lacks explicit 'when-not-to-use' but purpose is distinct enough.

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=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the exact data returned (dólar, maíz, novillo, spread, arrendamiento) and explaining the spread as a profitability proxy. 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 sentence (with semicolons) that front-loads the purpose and lists data items concisely. No wasted words; 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?

Given no output schema, the description fully specifies what the tool returns: all major market indicators and their units. It also explains the spread's meaning as a profitability proxy. With sibling tools, it is clear how this tool fits into the ecosystem.

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?

No parameters exist; schema coverage is 100% (vacuous). The description confirms 'sin parámetros', which is necessary for the agent to know it's a zero-argument call. Baseline for 0 params is 4, and the description meets 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 clearly states it provides macroeconomic context ('Contexto macro del mercado ganadero argentino'), lists specific data points (dólar blue y oficial, maíz FOB, novillo INMAG, spread, índice de arrendamiento), and explicitly distinguishes from sibling tools by naming what it does not provide (serie INMAG, precios por categoría) and pointing to alternatives.

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 'sin parámetros' (no parameters) so the agent knows it can be called directly. It also says what it does NOT do and provides alternative tool names (→get_indice_novillo, get_precios_hacienda), giving 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 confirm readOnly, openWorld, idempotent, and non-destructive hints. The description adds significant behavioral context: it returns fresh monthly Cañuelas data, a national YTD anchor, and historical national slaughter data with specific time periods and sources, plus a structural bias warning. 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 long sentence containing all necessary information, but it is dense and could be more readable with sentence breaks. Nonetheless, every clause adds value, so it is efficient rather than verbose.

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 thoroughly explains the three returned components: fresh Cañuelas reading, national anchor, and historical context, with precise time periods and sources. It also includes a critical interpretation warning, making it fully self-contained for an agent.

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?

Input schema has zero parameters with 100% coverage. The description reinforces that no arguments are needed, which is already clear from the schema. For a zero-parameter tool, baseline is 4, and the description adds no extra syntax but confirms the empty-arg condition.

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 de Liquidación' (% females) as a leading indicator of liquidation vs. retention, sourced from Mercado Agroganadero. It distinguishes from siblings like get_indice_novillo by specifying the unique indicator and data source.

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 notes no arguments are required and provides context on what the tool returns. It warns that Cañuelas data runs structurally above national slaughter, recommending against direct comparison. However, it does not explicitly contrast with sibling tools or provide when-not-to-use scenarios.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context beyond annotations, such as clarifying that the variation marks thin trading sessions ('ruedas flacas') and that the result is volume-weighted. 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?

Two sentences with no redundancy. Front-loaded with the tool's core purpose and return values, followed by usage boundaries and sibling references. 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?

The tool has no parameters and no output schema, but the description fully explains what the tool returns (value, volume, variation, 5-session average) and its scope (daily INMAG index). For a stateless, read-only tool, the description covers all necessary context.

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?

No parameters exist, so the description doesn't need to add parameter meaning. Baseline for 0 parameters is 4. The description correctly omits any parameter-related guidance.

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

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

The description clearly identifies the tool as retrieving the daily INMAG index for steer (novillo) from the MAG market, including specific return fields (value, volume, variation, 5-session average). It explicitly distinguishes from siblings like get_precios_hacienda and get_precios_detallados, and mentions the historical alternative get_inmag_historico.

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 states when to use (daily INMAG index) and when not to use (not for prices by category or subcategory, not for 1:1 comparison). It names alternative tools for those purposes (get_precios_hacienda, get_precios_detallados) and for historical data (get_inmag_historico).

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?

Adds behavioral context beyond annotations: the series is spliced (empalmado) with a note that the response clarifies when crossing the market boundary. Also mentions it's daily volume-weighted and returns sample points. No contradiction 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 informative and front-loaded, but slightly verbose. Every sentence adds value, yet could be trimmed without losing essential information. Still, it is well-structured 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 the tool has 4 parameters, no output schema, and several siblings, the description covers all necessary context: return fields, parameter usage, data source changes, and cross-tool references. It compensates for missing output schema by listing returned items.

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 enriches semantics: it specifies defaults (dias=30, max=5000), clarifies that dias is ignored if desde/hasta provided, explains desde=hasta for single date, and details moneda conversion (dólar blue venta).

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 historical series of Índice Novillo (INMAG) with trend details. It distinguishes itself from siblings by specifying that today's value is via get_indice_novillo and weekly category data via get_precios_hacienda.

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 this tool vs alternatives: for today's value use get_indice_novillo, for weekly by category use get_precios_hacienda. Also explains parameter usage for date ranges (dias vs desde/hasta) and that desde=hasta gives a single date.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral specifics: returns last business day data, min/avg/max in ARS/kg live weight + heads. No contradictions. Minor gap: no mention of pagination or limits, but acceptable given safety 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?

Concise single sentence with front-loaded purpose. Every clause adds value: source, examples, sibling differentiation, parameter details. 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?

Without an output schema, the description provides sufficient detail on return values (examples, min/avg/max, units, time). The sibling context is clear. Could mention if results are limited to one day, but 'último día hábil' implies that.

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%, but the description fully explains the sole optional parameter 'grupo': its enum values and behavior when omitted ('sin filtro, todas'). This adds significant 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 it provides detailed prices by subcategory from MAG/Cañuelas for the last business day, with examples and units. It explicitly distinguishes from sibling tools: more granular than get_precios_hacienda and not the daily INMAG index.

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

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

It explicitly compares to get_precios_hacienda (categories) and get_indice_novillo (index), guiding when to use this tool. The optional group parameter is explained. Could include when not to use, but the differentiation is sufficient.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: weekly observation from SIO, units (ARS/kg live weight), a warning for fewer than 200 heads, and that omitting the parameter returns all categories. 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 efficiently conveys all necessary information. It front-loads the purpose and includes essential details. While it's compact, it could be slightly more structured with bullet points or clearer separation of concepts. Nonetheless, it earns its sentences without 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?

For a tool with one optional parameter and no output schema, the description is complete. It explains the return values (price, heads, warning), source (SIO, weekly), and unit (ARS/kg). Given the context of good annotations, no additional information 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?

The single parameter 'categoria' has an enum but no schema description. The description adds meaning by stating 'categoria (enum) filtra una; sin arg, todas.' This explains that the parameter filters to one category or returns all if omitted, significantly adding value beyond the enum list.

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 provides livestock prices by category from Mercado Agroganadero, including specific details like weekly observation, ARS/kg live weight, current price, heads, and a warning for low data. It distinguishes itself from siblings such as get_indice_novillo and get_precios_detallados, making the purpose 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?

The description explicitly explains when to use this tool (for category-level prices) and when not to use it (not for INMAG daily index or subcategories). It also clarifies that the optional categoria parameter filters a single category, and omitting it returns all categories. This provides clear usage context and distinctions from alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral constraints like only future dates, ordering, and return fields, providing useful context 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?

Three dense sentences with no filler. Front-loaded purpose, clear info on return fields, parameters, and alternatives. 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?

Fully compensates for lack of output schema by listing return fields. Covers constraints, ordering, parameters, and tool scope. Adequately complete for a read-only list 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 description adds semantic detail: 'provincia' accepts substring matching, 'limite' has default 10 and max 50. This enriches the agent's understanding beyond schema 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?

Clearly states it's a calendar of upcoming cattle auctions in Argentina, with specific fields returned. Distinguishes from siblings by explicitly excluding price data and directing to other tools.

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?

Provides explicit usage context: only scheduled auctions from today forward, sorted by date, optional filtering by provincia and limite. Clearly states what the tool does not do (prices/INMAG) and names alternatives (get_precios_hacienda, 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?

The description states that the tool 'deja tu búsqueda activa' and sends alerts, implying a side effect (creating a subscription or ongoing notification). This contradicts the annotation readOnlyHint=true, which asserts no modifications. The description does not clarify the apparent write behavior.

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 well-structured, starting with an example, then explaining behavior, then listing parameters. It is concise yet comprehensive, with 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?

The description covers the core functionality (returning matches and setting up alerts) and mentions the output fields (fecha, consignataria, lugar, link). However, it omits details on alert management (e.g., how to unsubscribe) and error handling, which would be useful given no output schema.

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 valuable context: it specifies that 'categoria' accepts synonyms and that at least one of 'email' or 'webhook_url' is required (which is not enforced by the schema). This enriches the schema definitions.

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 returns matching upcoming auctions and sets up alerts for new matches, using a concrete example. It distinguishes itself from siblings like 'list_remates' by combining search with persistent alerting.

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 a concrete usage example and explains the dual behavior (immediate results + alerts). However, it does not explicitly compare to alternative tools or state when not to use it, though the context makes it clear for buyer search and alerts.

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 readOnly, idempotent, and non-destructive behavior. The description adds valuable context: it does not invent dates, returns windows from a specific resolution, and clarifies zoning logic (CON or SIN vacunación). 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 four objective sentences, front-loaded with the year and resolution, and every sentence adds value. No waste, well 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?

Despite no output schema, the description fully explains what the tool returns (campaign windows, zone status) and what it does not (invent days). For a simple tool with one optional parameter, this is complete.

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

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

Schema coverage is 100% (one optional parameter documented). The description adds context that the parameter filters by province for zone status, but does not explicitly state behavior when omitted (e.g., returns all provinces). 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 it returns the 2026 aftosa vaccination calendar by province, including campaign windows and zone status. It distinguishes itself from other sanitation tools by specifying the exact content (1st and 2nd campaign, zone status) and referencing the specific SENASA resolution.

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 what the tool returns and notes that exact dates are determined locally, but does not explicitly state when to use this tool over alternatives. However, no sibling tool provides similar calendar information, so usage context is implicitly 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces that this tool is purely reference and does not emit or consult real data. It also adds context about prerequisites (RENSPA, clave fiscal ARCA, vaccination) and how it chains with sanitary requirements, without contradicting 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 somewhat lengthy but every sentence adds value. It front-loads the core purpose and includes necessary clarifications. It could be marginally more concise, but overall it is well-structured and informative.

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

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

Given zero parameters and no output schema, the description fully covers the tool's role as a reference. It explains what the tool does, what it does not do, and where to find more detail. No gaps remain.

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, and schema coverage is 100% trivially. The description does not discuss parameters because there are none. For zero-parameter tools, the baseline is 4, and the description adequately fulfills its role.

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 explains the DT-e (Documento de Tránsito electrónico) or number of tropa, its requirements, and how it links to sanitary requirements. It distinguishes itself from the sibling 'sanidad_requisitos_movimiento' by specifying that for detailed movement requirements, that sibling should be used.

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 states when not to use this tool (it does not issue or query a real DT-e) and directs users to an alternative tool for detailed movement requirements. This provides clear guidance on appropriate use cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it is regulatory information cited from official sources, not operational, and specifies the return fields. No contradiction.

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

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

Three sentences, front-loaded with key information, includes alternative tool mention. Could be slightly more compact but overall efficient.

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

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

Tool has no output schema, so description compensates by listing returned fields. It also provides regulatory context and alternative tools. Complete for this type of read-only info 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% with the single parameter 'enfermedad' fully described in schema. Description does not add new meaning beyond the schema, so baseline 3 applies.

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

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

Description clearly states it returns a 'ficha' of a specific SENASA sanitary plan, listing fields like agent, regimen, categories, zoonosis, and resolutions with URLs. It distinguishes from sibling tools by noting it is non-operational and suggests sanidad_requisitos_movimiento 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 says when to use (to consult plan info) and when not to (for moving cattle, use sanidad_requisitos_movimiento). Also explains behavior without argument (lists all 4 plans).

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 readOnly, idempotent, non-destructive. Description adds critical context: it does NOT query live SENASA database due to authentication requirements, directing to official public query for validity. No contradiction 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?

Two well-structured sentences: first states core function and output, second clarifies limitation and alternative. 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?

Despite no output schema, description explains returned segments and their meaning. Covers limitation and alternative for full verification. Complete for a simple validation 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 covers 100% with 'Código RENSPA, con o sin puntos'. Description adds format structure and what the decoded segments represent, providing additional clarity beyond 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?

Clearly states it validates/decodes a RENSPA code, gives format (17 chars, 00.000.0.00000.00), and explains it returns segments (provincia, departamento, etc.). Distinguishes from sibling tools by specificity.

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 what it does (validate/decode) and what it does NOT do (live validity check). Provides alternative for verification: 'remite a la consulta pública oficial'.

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 declare readOnlyHint, idempotentHint, destructiveHint. The description adds that it provides source resolutions, checks aftosa barrier with province input, and clarifies it only informs requirements without emission, adding value 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?

Two sentences in Spanish, concise yet comprehensive. Information is front-loaded with main purpose, followed by conditional behavior and exclusions. No wasteful 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?

Despite no output schema, the description fully explains what the tool returns (list of requirements with source resolutions, plus aftosa barrier info) and what it does not do, making it complete for a read-only informational 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% and descriptions are clear. The description adds meaning by explaining that province parameters trigger aftosa barrier crossing check, which is not evident from schema alone.

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 provides sanitary requirements for moving bovine livestock, listing specific items (RENSPA, DT-e, aftosa, etc.) and distinguishing itself from siblings by explicitly stating it does not emit 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 tells when to use (to get movement requirements) and explicitly says what it does not do (emit DT-e), pointing to SIGSA as alternative. However, it does not directly compare to other sanidad siblings like sanidad_calendario_aftosa.

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

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

Annotations already declare readOnlyHint, idempotentHint, and no destructive behavior. The description adds valuable behavioral context: free tier with daily quota (by origin), paid option with USDC, and the specific index used. 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?

The description is a single paragraph that front-loads a concrete example. It is informative without being verbose, though it could be slightly more structured with line breaks for clarity. Still, it earns its 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 exists, so the description explains the return format (annual/monthly canon in ARS and USD). For a 3-parameter tool, it covers scenarios, pricing, and index source. Missing details on error handling but complete enough for expected usage.

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 covers all parameters with basic descriptions. The description adds meaning: example values (3,500 has in Corrientes), the effect of kg_ha_anio (exact vs scenario range 40-100), and units (ARS/USD). This goes 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 values (calculates) the cost of renting a field in Corrientes, using a specific index (MAG). It gives an example query and distinguishes itself from sibling tools by mentioning specific parameters and 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?

The description explains when to use the optional kg_ha_anio parameter (without it, scenarios are returned) and mentions the free tier with daily quota. It does not explicitly list when to avoid this tool, but the context and examples provide clear 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?

The description goes far beyond the annotations by revealing the methodology (own survey crossing appraisers, published series, cadastre, sale ads), the distinction between livestock and agricultural valuation in different currencies, the inclusion of sources for each data point, and the free/no-quota policy. This rich behavioral context adds significant value without contradicting the read-only, idempotent, and non-destructive hints.

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 long but every sentence contributes value: examples, core function, methodology, currency distinction, and free status. It is front-loaded with questions and ends with a param list. However, the param list omits qq_soja_ha_anio, which creates a structural inconsistency, and the flow could be slightly more organized. Overall, it's efficient for the tool's complexity.

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 does a good job explaining what the tool returns (value per hectare, range, typical rental in kg/novillo, sources) and covers the main use cases. It also clarifies optional parameters' effects. The main gap is the incomplete param enumeration (missing qq_soja_ha_anio), though the prose mentions the agricultural unit concept. Overall, it is quite complete for a valuation tool with no output schema.

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 coverage, the baseline is 3, and the description does add meaning beyond the schema by explaining the two valuation currencies ('el ganadero en kg de novillo por ha por mes, el agrícola en quintales de soja por ha por año') and how optional parameters like hectareas affect the output. However, it omits the explicit parameter name qq_soja_ha_anio from the param list, even though the concept is described, so it doesn't fully compensate for that gap.

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

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

The description clearly states the tool's purpose: valuing land in dollars per hectare with detailed context like typical rental and source. It uses specific verbs and examples ('¿Cuánto vale la hectárea en Corrientes?'). However, it does not explicitly differentiate this from sibling tools like valuar_arrendamiento_campo, even though it covers rental information too, so it lacks explicit sibling distinction.

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 clear usage context through example questions, specifies the geographic coverage (15 provincias, 52 zonas), and notes it's free and without quota. It also lists required and optional parameters with practical hints (e.g., 'acepta el nombre de la zona o el partido'). However, it does not explicitly state when not to use the tool or mention alternative tools, so exclusions are absent.

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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe. The description adds valuable behavioral context: cost structure (free with cap, paid otherwise), payment mechanism (x402), and daily limit per origin. 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 efficiently conveys purpose, output, pricing, and optional parameters. It could be split into shorter sentences for better scannability, but it is not verbose and includes only essential 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?

Since there is no output schema, the description fully explains the return values (total ARS, USD blue and official, per-head value, dated source). It also covers input semantics, cost, and reference link. For a tool of this complexity, the description is complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that 'kg_promedio' is optional and defaults to typical weight per category, and 'provincia' is optional but does not change the national reference. This is helpful beyond the schema's dry definitions.

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 values a herd of livestock using official MAG prices, returning total value in ARS and USD, per-head value, and a dated source. The verb 'valúa' and resource 'tropa' are specific, and the tool is well-differentiated from siblings like 'valuar_arrendamiento_campo' which values leases.

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 mentions free usage with a daily quota and paid usage otherwise, giving context for when to use. It does not explicitly compare to alternatives, but the tool is unique among siblings, so the lack of explicit exclusion is acceptable.

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