Consignatarias · Argentine Cattle Market

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds value beyond that by disclosing the return shape (agente, régimen, categorías afectadas, zoonosis, source resolutions with official URLs) and the free-call default. No auth or rate-limit detail, but that is minor against the annotation coverage.

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

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

Front-loaded with the resource and its contents in the first sentence, then the default behavior, then the sibling disambiguation, closing with a compact EN gloss. Every sentence earns its place and nothing is redundant.

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, but the description enumerates the returned fields (agent, regimen, categories, zoonosis flag, source resolutions), so return expectations are set. Combined with annotations covering safety, the definition gives everything needed to call it correctly.

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

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

Schema coverage is 100%, and the single enum parameter is already fully documented in the schema, including the 'sin este arg devuelve los 4' default. The description's mention of the no-argument behavior largely repeats the schema, so it adds only marginal meaning. 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?

States a specific verb+resource: returns the ficha of a mandatory SENASA health plan for bovine diseases, and enumerates the four options (aftosa, brucelosis, tuberculosis, garrapata/tristeza). It also details what the ficha contains, so an agent understands the payload without opening anything. It distinguishes itself from livestock_movement_rules by contrasting regulatory vs operational info.

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 behavior with and without the argument ('Sin argumento lista los 4 planes') and names the correct alternative for the movement use case ('para mover hacienda usá livestock_movement_rules'). Both when-to-use and when-not-to-use are covered.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuine context beyond them: the ranking returns average price per firm and the hard cap of 45 firms (limite max) that the schema does not state. It does not describe auth or rate-limit behavior, keeping it from a 5.

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

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

Front-loads purpose, then exclusions, then arguments; every clause carries information. The bilingual restatement is mildly redundant but aids the Spanish-market audience, so it is efficient without being maximally tight.

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 purpose, alternatives, parameter syntax with defaults, and the return content, which is sufficient given no output schema exists. Only marginal gaps remain, such as whether the ranking truncates to 'limite' firms or aggregates beyond 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?

Schema coverage is 100%, so the baseline is 3. The description still adds the max value of 45 for 'limite', which the schema omits, and restates defaults and the category examples concisely, so it earns a bump 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?

States a specific verb and resource (ranking of consignatarias by head traded) with the exact market scope (MAG, Cañuelas) and the return content (average ARS/kg per firm). It also names the siblings it is not (livestock_prices, cattle_price_index), so an agent can distinguish it without opening any schema.

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

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

Explicitly gives the selecting question ('qué firma operó más') and two named exclusions with their alternatives (no market price → livestock_prices; no daily index → cattle_price_index). This is a textbook when/when-not/alternative statement.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description goes further: it discloses the computation formula, fallback data sources with specific identifiers (haciinfo000013, INMAG), the output values returned (mensual, anual, por ha/mes), and a legal disclaimer ('Estimación, no asesoramiento'). This is rich context beyond structured fields.

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

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

Front-loads the formula, then fallbacks, then exclusions, then disclaimer. Every sentence earns its place; the English translation at the end is a minor redundancy but does not bloat significantly.

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?

Complete for a calculation tool with no output schema: the formula, fallback data sources, return values, and exclusions are all disclosed. Annotations already cover the safety profile, so nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so parameter meanings are fully documented in the schema itself (including the periodo enum and default). The description restates the formula driving parameter combination and clarifies the unit ambiguity (monthly vs annual) for kg_ha, but adds no syntax or format details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (calcula) and resource (canon de arrendamiento de campo), gives the exact formula (kg novillo/ha/mes × hectáreas × precio), and explicitly excludes sibling uses ('Solo calcula: para consultar precios usá cattle_price_index o livestock_prices'). An agent can distinguish this from value_farmland, value_farmland_rent, and cattle_price_index without opening schemas.

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 names the alternatives (cattle_price_index, livestock_prices) and states the condition that selects them ('para consultar precios'). Also clarifies fallback behavior when precio_novillo is missing (MAG index, then INMAG). Nothing is left to inference.

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

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

The annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds meaningful behavioral context: it returns matching auctions right away, leaves the search active, sends email or webhook alerts for new matches, and is free. It does not cover permission or rate-limit behavior, but that is not critical given 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 definition is front-loaded with a concrete example and outcome, then compactly lists key parameters and behavior. It is efficient overall, though the Spanish and English versions partially duplicate content rather than adding new 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?

For a 7-parameter mutation tool with no output schema, the description is complete enough: it explains the immediate return fields, the persistent search behavior, notification channels, cost, and matching logic. The remaining parameter details are fully covered by the 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 description coverage is 100%, so the baseline is 3. The description adds useful semantics beyond the schema, including that categoria accepts synonyms and that email and/or webhook_url must include at least one for alerts. It omits contacto_para_operar, but that parameter is fully documented in 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 states a specific action and resource: posting a cattle buying request in Argentina and receiving matching upcoming auctions immediately plus ongoing alerts. It implicitly distinguishes itself from auction-listing siblings by emphasizing request creation, matching, and active notifications rather than browsing.

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 example "Quiero comprar 300 terneros en Corrientes" makes the intended use clear, and the description explains the immediate-match plus alert workflow. However, it does not explicitly name alternatives such as upcoming_auctions or create_price_alert, nor does it state when not to use this tool.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context: volume weighting, that thin trading sessions are flagged, the variation-vs-previous-session semantics, and the 5-session average. It stops short of describing error/empty conditions or refresh cadence, so it earns a 4 rather than a 5.

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

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

The core definition and constraints are front-loaded in the first clause, with siblings and exclusions following. The bracketed [EN] restatement is partially redundant duplication, which keeps it from a perfect score.

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

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

Output schema covers the return shape and annotations cover the safety profile, so the description's job is scope and routing, both of which it does fully. Weighting method, limitations, and the historical sibling are all disclosed.

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?

Zero parameters, which is the baseline-4 case, and the description explicitly confirms 'Sin args' so the agent won't hunt for optional filters. Nothing further can be said about parameter 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?

States a specific resource (INMAG daily index for the Mercado Agroganadero), the exact reference (live-weight steer, ARS/kg, volume-weighted), and the timeframe (HOY). It also names the siblings it is not (livestock_prices, livestock_prices_detailed) and warns against 1:1 comparison, so an agent can place it precisely in the tool family.

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

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

Explicit routing: use this for today's index, use inmag_history for historical series, and do not use it for category or subcategory prices. Both the alternative and the exclusions are stated outright rather than implied.

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

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

Annotations already state readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context that this is a proprietary indicator based on actual Mercado Agroganadero lot sales and returns a publish-ready quote, but it does not describe error behavior, data availability, or return structure.

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

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

The Spanish definition is front-loaded and relevant, but the full English translation duplicates the same content and adds token overhead. The description is not bloated to the point of unuseable, but the bilingual repetition weakens conciseness.

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 read-only tool with one optional parameter, no output schema, and safety annotations already present, the description is largely complete: it explains the indicator, data source, weekly scope, default behavior, and that it returns a ready-to-publish quote. It could do more to identify its closest sibling alternative, but the core calling context is covered.

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 optional fecha parameter is fully described in the schema, including YYYY-MM-DD format and default to the latest data. The description reinforces the weekly framing but does not add parameter meaning beyond what the schema already provides, so the 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 identifies the specific indicator: the weekly gap between the bottom and top deciles for the same cattle category/day from actual lot sales. It distinguishes itself from generic averages, but it does not explicitly differentiate from the closely related sibling price_dispersion_history.

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 weekly dispersion analysis and says the result is a ready-to-publish quote, but it gives no explicit when-to-use/when-not-to-use guidance or alternatives such as price_dispersion_history. The optional date default is covered by the schema.

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=false, openWorldHint=true, idempotentHint=false and destructiveHint=false. The description adds quota behavior (3 free alerts per origin, unlimited with an Enterprise Bearer key or api_key param) and what is returned (id and price), which is useful beyond the structured fields. However it omits what happens on duplicate alerts, how to update or delete an alert, and whether webhook delivery is retried.

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?

Dense but front-loaded: trigger, delivery, sibling positioning, pricing/quota, then params. The trailing bilingual restatement repeats the opening sentence in English, which is defensible for cross-language routing but is redundant padding for an agent reading the Spanish 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?

No output schema exists, yet the description states the return payload (id and price), the auth model, the quota, and the delivery semantics, which is enough for an agent to call this correctly. Nothing essential to invocation is missing.

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

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

Schema coverage is already 83%, yet the description adds real meaning: 'inmag' is a daily index while the other categories are weekly, umbral is in ARS/kg en pie, direccion defaults to above, and at least one of email/webhook_url is required – a cross-field constraint the schema does not encode. It does not explain the api_key/auth interaction beyond naming it as an alternative to the Bearer header.

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

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

States a specific verb and resource (create a price alert) plus the trigger condition (price of a category crosses a threshold) and the delivery channels. It also positions itself among siblings by declaring it is one of only three tools that write data, alongside cattle_buying_request and market_match.

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

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

Explicitly routes the agent: this tool writes, 'el resto lee', so read queries go elsewhere. It also disambiguates the delivery channel ('para una persona usá email', webhook only for integrations) and states the free-tier ceiling (3 active alerts per origin) versus Enterprise keys.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered; the description adds genuinely new context by clarifying this is purely informational and does not emit or query a real DT-e (that requires the ARCA fiscal key), which prevents an agent from expecting a live lookup. It doesn't discuss return shape, but with annotations present this is solid.

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

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

Front-loaded with the resource and scope, then the explicit exclusion, then the sibling routing, with a brief EN gloss. Dense but every clause adds routing or scope value; the bilingual restatement is slight padding but harmless.

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

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

No output schema and no parameters, so the description carries the load and does it well for a reference tool, enumerating the requirement categories it covers (RENSPA, ARCA fiscal key, vaccination) and its chaining to sanitary rules. Sufficient for an agent to call it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

States a specific resource (DT-e / número de tropa) and its scope: explaining what it is, the requirements to issue it, and how it chains to sanitary requirements. It explicitly declares what it does NOT do ('NO emite ni consulta un DT-e real') and names the sibling it is not, so an agent can separate it from livestock_movement_rules without opening schemas.

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?

Names the alternative explicitly ('Para el detalle de requisitos por movimiento usá livestock_movement_rules') and gives the exclusions (reference only; the real DT-e lives behind ARCA fiscal key in SIGSA). The when-to-use/when-not-to-use split is fully spelled out.

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

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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds meaningful detail beyond that: it enumerates return components (USD/ha, annual rent, product-denominated canon in kg novillo or quintales soja, yield %, payback years) and explains that canon is product-nominated to avoid devaluation. Data freshness or sourcing is left unstated, keeping it from a 5.

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

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

Front-loaded with the core computation and return values, followed by an Args block and an English summary. The bilingual repetition and the closing note about zona núcleo add some bulk, but the structure is logical and nearly every sentence earns its place.

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

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

No output schema exists, so the description carries the return-value burden and does so thoroughly. All four parameters are documented, including optionality and defaults. The one gap relevant to correct use is that it does not clarify how it differs from near-duplicate rent tools.

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 the baseline is 3. However, the description adds real semantics by explaining that presupuesto_usd is distributed across hectares and by restating the aptitud options, going beyond the schema's own 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?

Specific verb and resource: annual yield on invested capital for Argentine farmland, broken down by zone and three aptitudes, with a clear list of computed outputs. It is easy to tell what the tool does. It stops short of 5 because there is no differentiation from overlapping siblings such as calculate_farmland_rent or value_farmland_rent.

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 offers a target persona ('Para el comprador del exterior que evalúa entrar'), which implies usage context, but never states when to choose this tool over calculate_farmland_rent or value_farmland_rent. No exclusions or alternatives are named, so selection remains inferential.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered. The description goes further by disclosing the return shape (name, locality/province, category, CUIT, one contact channel, profile URL) and the result limits (default 8, max 25), plus an explicit scope boundary that it does not return market activity. No auth/rate-limit context, which keeps it short of a 5.

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

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

Front-loaded with the resource and its dimensions, then return fields, then the exclusion and alternative. Dense but each sentence carries information; the trailing [EN] gloss is partly redundant with the Spanish text, which is the only mild waste.

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

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

With no output schema, the description compensates by enumerating returned fields, and it covers the cap on results and the no-term case. It stops short of describing what happens on zero matches or how far beyond 25 results the agent can page, which a directory tool of this size could reasonably state.

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 the baseline is 3, but the description adds real meaning the schema lacks: the hard cap of 25 on `limite` (the schema only mentions the default of 8) and the OR relationship between `query` and `provincia`. The English gloss also reframes `query` as including tax ID (CUIT).

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

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

Names a specific verb and resource (directory lookup of consignatarias/casas de remate de hacienda) and lists the searchable axes (nombre, razón social, localidad). It explicitly separates itself from the sibling that covers market activity data, so an agent can route without opening either schema.

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

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

States the condition that makes a call valid with no search term ("Alcanza con el nombre O con la provincia") and gives a concrete example query. It also gives a clear when-NOT-to-use plus the named alternative (broker_activity_ranking for cabezas/precio).

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description usefully adds behavioral detail beyond them: the per-plant return fields, that inactive plants are flagged in SENASA, and the result cap (default 10, max 30). It does not mention pagination or error behavior, keeping it out of the top band.

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

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

Front-loaded with the resource and selectors, with the return fields and the exclusion follow. The Spanish/English duplication adds length, but each clause (requirements, limit, exclusions) carries distinct information, so waste is limited.

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?

There is no output schema, so the description carries the return-value burden — and it does, enumerating name, province, matrícula, CUIT, ciclo and the inactive flag, plus the result cap. Nothing an agent needs to call this search tool correctly is missing.

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

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

With 100% schema coverage the baseline is 3, but the description adds meaning beyond the schema: it states that query and provincia are alternatives where one suffices, and it documents the max limit of 30 that the schema only partly conveys (schema says default 10 only). This is incremental value over the structured fields.

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: a directory of SENASA/MAGYP-licensed meat plants and slaughterhouses searchable by name, tax ID (CUIT) or province. It explicitly carves itself away from price and slaughter-volume tools ('No da precios ni faena — es directorio'), so an agent can distinguish it from siblings like livestock_prices or value_cattle_lot.

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

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

Gives clear invocation conditions: 'Requiere query (nombre/CUIT) o provincia (una alcanza)' — at least one selector is needed — and a when-not ('No da precios ni faena'). It stops short of naming a sibling alternative, but the context and exclusions are explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds non-obvious behavioral context: it will never fabricate an exact day and always returns the window plus the official citation, which is valuable for an agent reasoning about data reliability.

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 are well front-loaded: the resource and regulatory basis come first, then the return contents and the caveat about exact days. The English translation is redundant but small; overall it is efficient and readable.

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

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

For a zero-required-parameter, read-only lookup with a fully documented schema and annotations covering safety, the description is complete enough: it names the resource, the legal basis, the returned windows, the zone classification, and explicitly states what it will not return.

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 there is only one optional parameter whose semantics are already documented in the schema. The description adds context about zone status (Patagonia/Calingasta) but does not extend the parameter's meaning beyond what the schema provides, so the baseline of 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?

States a specific resource (FMD vaccination calendar for 2026, per SENASA Res. 711/2025) and exactly what it returns: first-campaign windows for all categories, second-campaign windows for calves only, and zone status (WITH/WITHOUT vaccination) per province. No sibling tool in the list covers this resource, so it is clearly distinguishable.

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?

Implicitly tells the agent to query by province for zone status, but never states when this tool should be used versus alternatives (e.g., animal_health_plan or livestock_movement_rules) or what an absent province argument yields. Usage is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is mostly covered. The description adds genuinely useful behavioral context beyond that: the argument-less call returns a 14-item list while a topic argument returns structured implementation guidance (sections and practices). No auth/rate-limit notes, but for an informational read tool this is solid.

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 purpose and mode behavior are front-loaded, followed by the routing rule to the mandatory-sanitary siblings. A bilingual EN gloss is appended for accessibility; it is mildly redundant but earns its place for a Spanish-named resource. Dense but no filler sentences.

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

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

There is no output schema, so the description carries the return-shape burden; it does so at a reasonable level ('cómo implementarlo (secciones y prácticas)' vs. a 14-topic list). Combined with the sibling routing and mode description, an agent has enough to invoke it correctly, though exact response fields are not enumerated.

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 documents the 'tema' slug with examples, so the baseline is 3. The description adds practical meaning on top: omitting the argument enumerates all 14 topics, while supplying one returns how to implement it (sections and practices), and it even lists the 14 valid topic names, which is richer than 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 states a specific resource (Buenas Prácticas Ganaderas for beef cattle production, sourced from the 2019 Red BPA guide) and the two operating modes: no argument lists the 14 topics, with an argument returns implementation sections and practices. It also names the sibling tools it is NOT (animal_health_plan / livestock_movement_rules), so an agent can distinguish it without opening any schema.

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

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

It gives an explicit when-to-use/when-not rule: these practices are voluntary, and for mandatory ('OBLIGATORIO') sanitary matters the agent should use animal_health_plan or livestock_movement_rules instead. The alternative tools are named alongside the condition that selects them, leaving nothing to inference.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile, so the bar is lower. The description still adds real value by disclosing the return payload (fresh Cañuelas monthly reading 2026→, YTD national anchor from MAGyP PDFs, historical national female-slaughter series 1998-2025) and the comparability caveat.

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

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

Front-loads the core definition before the data-source and caveat detail. Dense with parentheticals and em-dashes, but each clause (sources, periods, caveat, EN gloss) earns its place; only the bilingual gloss feels optional.

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

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

With no output schema, the description carries the burden and does so: it names every returned component with its source and periodicity, plus the cross-series comparability warning. An agent can call and interpret it without further 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?

Zero parameters, so the baseline of 4 applies. 'Sin args' explicitly confirms no inputs are needed, matching 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?

States a specific metric — the share of females (cows + heifers) in cattle moved through the Cañuelas market — and frames it as a leading indicator of liquidation vs. retention. This is precise enough to distinguish it from sibling data tools like cattle_price_index or inmag_history.

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

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

Gives interpretive context (leading indicator of liquidation vs. rebuilding) and an important caution not to compare Cañuelas levels 1:1 with the national slaughter figure. However, it never states when to pick this tool over siblings like price_dispersion_history or macro_context; usage is implied rather than routed.

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

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

Annotations already declare readOnly/idempotent/openWorld, and the description adds substantial context beyond them: no rate cap at any depth, the data-lineage caveat that pre-May-2022 values come from Mercado de Liniers and the response flags range crossings, the USD conversion rule (blue venta, last known value per date), and what is actually monetized (mass download/redistribution, not the query).

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

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

Front-loaded and information-packed, but redundant: the return payload (inicio/fin/variación/min/máx/~8 points) and the free/no-cap claim are each stated two or three times, and the [EN] one-liner duplicates the opening sentence. Editing out the repetition would tighten it without losing 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?

No output schema exists, so the description rightly describes the returned fields and sample size, and it covers cost, depth and the provenance boundary an agent needs to interpret results. Only minor gaps remain (e.g. exact behavior on out-of-range dates), but the essential picture 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 description coverage is 100% and the schema already documents dias (default 30, max 5000), desde/hasta (default today, desde=hasta = single date) and moneda (blue venta rule). The description restates these but adds negligible new syntax or edge-case meaning beyond what the schema provides, so the 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?

States a specific verb+resource ('Serie histórica del Índice Novillo (INMAG)'), its cadence and depth (daily since 2015-01-05, spline-spliced market switch in May-2022), and explicitly disambiguates from siblings: today's value goes to cattle_price_index, weekly by-category to livestock_prices. An agent can route without opening any schema.

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

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

Explicit when-to-use-this vs alternatives ('Valor de HOY → cattle_price_index; por categoría (semanal) → livestock_prices, no comparar 1:1'), plus the row-by-row case routed to Enterprise API key or x402. Also clarifies fresh-vs-historical and warns against a naive 1:1 comparison.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description goes beyond that with real methodological disclosure: live weight only in every country, no carcass-yield estimation, and only sources that publish live weight are admitted.

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

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

The core definition is front-loaded and the warning about Brazil is well placed, but the full Spanish text is then repeated in English, and phrases like 'no la publica nadie armada' add flavor rather than information. Roughly half the length is duplication.

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?

Good on units (USD per live kg) and country coverage, but there is no output schema and the description never says what the response looks like or what period it covers — current snapshot versus a historical series. For a remote data tool with openWorldHint, that is a meaningful gap for correctly framing the result.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate beyond the implicit unit and country scope, which it does state. Baseline for a zero-parameter tool.

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

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

States the exact metric: the Argentine steer price gap versus the US, Uruguay and Australia, expressed in USD per live kilogram. The resource and unit are unambiguous, but no sibling tool (e.g. livestock_prices, cattle_price_index) is ever named, so the separation from those is left implicit.

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

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

Frames the use case clearly as the question asked by someone outside the country looking to buy cattle or farmland, and adds a concrete scope caveat that the gap is defensible against the northern hemisphere and Uruguay but not against Brazil. No explicit when-not-to-use or alternative-tool routing is given, though.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so safety is covered; the description adds useful non-annotation context: it does not emit the DT-e, that requires a SIGSA fiscal key (ARCA), and it returns each requirement with its source resolution. That said, it does not describe response shape or enumeration format, so the added behavioral value is moderate.

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

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

Front-loaded with the core purpose and requirement list, then the conditional behavior, then the boundary note and an English gloss. Every sentence earns its place, though the [EN] translation is mild redundancy that slightly dilutes density.

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

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

With no output schema, the description carries the return-value burden and largely does so: it states it reports the required documents/conditions with each one's source resolution ('con la resolución fuente de cada uno'). For a read-only lookup tool this is sufficient, missing only minor detail on output structure.

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 both params are optional, giving a baseline of 3, but the description goes further by explaining what passing origin/destination actually does — it determines whether the movement crosses the aftosa vaccination barrier — adding semantics beyond the schema's bare '(opcional)'.

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

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

States a specific verb+resource: it enumerates the SENASA sanitary requirements (RENSPA, DT-e, aftosa, brucelosis serology, tick barrier, habilitated transport) for moving cattle between Argentine provinces/regions. It distinguishes itself from siblings by clarifying it informs requirements rather than emitting documents, unlike dte_lookup/renspa_lookup. An agent can identify its scope without opening the schema.

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

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

Explains the conditional behavior (passing origin/destination provinces triggers a barrier-crossing determination) and draws a clear boundary against the DT-e issuance process (SIGSA/ARCA), telling the agent what this tool will NOT do. It lacks an explicit 'use X instead' pointer to the dte_lookup sibling, so it stops short of full alternative routing.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: weekly rather than daily data, ARS per live kilogram, SIO as the source, and a low-data warning threshold of fewer than 200 head per category. It does not discuss latency, auth, or pagination, but those are low-relevance for a public read-only price endpoint.

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 definition is front-loaded with the core purpose, then exclusions, then parameter behavior, which is the right order. It is dense and somewhat telegraphic (SIO, ARS/kg vivo, cab) and the bilingual duplication adds length, though that duplication genuinely helps an English-speaking agent parse an otherwise Spanish-only definition.

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

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

A single optional parameter read tool with an output schema and safety annotations needs exactly this: what data is returned, at what cadence, in what units, from what source, with what caveat about thin categories, and which siblings it must not be confused with. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry semantics. It identifies 'categoria' as an enum that filters to a single category and states that omitting it returns all categories, which is the key invocation behavior. The enum values themselves are already in the schema, so the description does not need to repeat them, but its first-sentence listing reinforces them in human terms.

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

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

The description names a specific resource (Argentine cattle prices by category from the Mercado Agroganadero), the unit (ARS/kg live), the cadence (weekly SIO observation), and the exact categories covered. It also names the siblings it is NOT (cattle_price_index for daily INMAG, livestock_prices_detailed for subcategories), so an agent can route without opening schemas.

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

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

Explicit when-not guidance is present: 'NO es el INMAG diario (cattle_price_index, no comparar 1:1) ni subcategorías (livestock_prices_detailed)'. The default behavior ('sin arg, todas') and the filter behavior ('categoria (enum) filtra una') are both stated, leaving no inference needed about when to call this versus its 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 readOnly/idempotent/non-destructive, so safety is covered. The description adds useful behavior the annotations don't: data freshness ('último día hábil'), units (ARS/kg vivo), and the payload shape (min/avg/max plus head count). It stops short of rate limits or caching behavior, so not a 5.

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

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

Dense but front-loaded: purpose, then the disambiguating comparisons, then the parameter note, then an English gloss. Uses compressed notation, but every clause carries information; slightly long for a one-parameter read tool.

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 carries the return-value burden — and it does, specifying min/avg/max, units, live-weight basis, and head counts, plus the optional filter. Nothing needed to call this correctly is missing.

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

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

Schema coverage is 0%, but the single enum parameter is fully explained: the description lists the grupo values and defines the no-filter default ('sin filtro, todas'), which the schema does not state. Adds real meaning about default behavior 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?

States a specific resource (precios por SUBCATEGORÍA del Mercado Agroganadero) with concrete example categories ('NOVILLOS Regular +430'), the returned measures (mín/prom/máx en ARS/kg vivo + cabezas) and the data recency (último día hábil). It also explicitly names the siblings it is not (livestock_prices, cattle_price_index), so an agent can disambiguate without opening schemas.

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

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

Gives the exact selection rule against both nearest alternatives: more granular than livestock_prices (categorías), and explicitly NOT the daily INMAG index (cattle_price_index). Both when-to-use and when-not-to-use are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuine context beyond them: the zero-argument nature of the call and the conditional availability of the MAG lease index ("si hay"), which warns the agent a field may be absent. Return shape is covered by the output 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?

Front-loaded with the resource and scoping, and every clause contributes content or routing. The main body is a single long sentence stacked with parentheticals and unit annotations, which is dense but still parseable; a bulleted or slightly split structure would read faster.

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

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

An output schema exists, so return values need not be explained, yet the description still enumerates the key metrics and their units, which is exactly the right amount of detail. The sibling disambiguation and the optional-field caveat close the remaining gaps for a zero-parameter read 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?

Zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description reinforces this with "sin parámetros", preventing an agent from inventing inputs.

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

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

Names the exact resource (macro context for the Argentine cattle market) and enumerates its contents: blue/official USD rates, FOB corn, steer INMAG, the steer/corn spread and an optional MAG lease index. It explicitly disclaims two neighboring capabilities and routes them to cattle_price_index and livestock_prices, so an agent can distinguish it from siblings without opening any schema.

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

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

States "sin parámetros" up front, which tells the agent this is a zero-input call, and gives explicit exclusions with named alternatives ("NO da la serie INMAG (→cattle_price_index) ni precios por categoría (→livestock_prices)"). Both when-it-applies and when-to-go-elsewhere are covered.

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 only say readOnlyHint=false and destructiveHint=false; the description goes much further, disclosing that results are aggregated and anonymous with no volume or identity, that the lookup is free with no commission, and that setting registrar:true with consentimiento creates a persistent request on the 'mesa' that a human will follow up on. That conditional-write and consent context is information the structured fields cannot convey.

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?

Scoping examples are front-loaded and each one disambiguates a real use case, so they earn their space; the closing bilingual one-line summary is mildly redundant with the opening. The inline parameter list duplicates the schema, which is the only real 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 10-parameter, open-world, conditionally-writing tool with an output schema and annotations, the description covers anonymity, consent, cost, and sibling routing. It stops short of explaining what 'tasar' returns or what the aggregated ranges look like structurally, but the output schema carries that load.

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 the parameter list restatement (quiere/categoria/cabezas/hectareas/provincia) adds little, but the description does clarify the registrar + consentimiento pairing and the email-or-telefono alternative beyond the schema text. Good added value on the mutation-related params, baseline behavior on the rest.

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

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

The description opens with three concrete user questions and then states exactly what the tool returns: open counterparties today for that category, in per-region ranges ("2 a 4 en el NEA"), anonymous and without volume. It also names the pricing siblings it is not (value_cattle_lot, livestock_prices), so an agent can separate it from the valuation tools without reading the schema.

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

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

It gives an explicit selection rule: use this when the person wants to OPERATE (sell, buy, lease), and use value_cattle_lot or livestock_prices when they only want the price. It further spells out the escalation path — ask permission, then repeat the call with registrar, nombre, email/telefono and consentimiento — which is exactly the when-to-use guidance an agent needs.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real context beyond them: full-series delivery without an API key, the key being needed only for bulk export, and no cap on historical windows. It stops short of describing the response structure or granularity, so it is strong but not complete.

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

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

The rhetorical opening question front-loads intent well, but the text repeats the free/no-quota claim three times and carries a full bilingual restatement plus a '(VR v1.0)' tag. Several sentences could be trimmed without losing guidance.

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 purpose, alternatives, cost model, and parameter guidance for a three-parameter, zero-required tool with no output schema. The main gap is what the returned series looks like (granularity, units, date alignment), which the agent must infer.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds that the window published in /mercado and /vr is only a default and that any window is free, which changes how an agent should set dias. It restates default 30 and optional categoria, which is redundant but harmless.

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

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

States a specific resource and scope: a historical series of the observed P10–P90 price band by category, framed around whether dispersion is widening or tightening. It explicitly contrasts with point-price tools, so an agent can distinguish it from livestock_prices and value_cattle_lot without opening any schema.

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

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

Gives explicit routing: 'Valor de HOY → livestock_prices' and 'valuar una tropa → value_cattle_lot', leaving this tool for the historical-band question. Also states access conditions (free last 30 days, unlimited backward, no quota), so the agent knows there is no cost penalty for large windows.

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 carry readOnly/idempotent/openWorld, so the bar is lower; the description still adds real context: data starts 2015, methodology (ratio over centered 12-month moving average, median across years, normalized to 1.00), and the deliberate USD-vs-pesos choice. It also discloses the default month behavior. Missing only coverage of edge cases or compute cost.

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

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

Front-loaded with the core question, then methodology, then args, then rationale — a sensible order. The bilingual restatement adds length that partially duplicates the Spanish, but it is functionally tight and each substantive sentence (methodology, USD rationale) earns its place.

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

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

With no output schema, the description usefully tells the agent what the returned index means (normalized to 1.00, ratio vs 12-month moving average), which enables correct interpretation of results. Complete for a single-optional-param read tool, though it doesn't describe the exact output fields/shape.

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 value beyond the schema by stating the default for `mes` ('default el último con índice'), which the schema only labels 'opcional'. Format YYYY-MM is already in the schema, so no extra credit there.

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 precisely what it computes: a seasonal index of Argentine cattle prices in USD by month (since 2015), plus where today sits against that norm. It implicitly distinguishes itself from daily-price tools by contrasting 'que es lo que el precio del día NO contesta', though it doesn't name the specific sibling (livestock_prices / cattle_price_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?

Gives a clear decision context ('¿conviene comprar ahora o esperar?') and frames it against the daily price tool as the alternative for a different question. Lacks an explicit 'when-not' or prerequisites statement, but the use case is unambiguous.

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

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds real value on top: it discloses the input length/format, what fields are decoded, and the important limitation that it cannot verify live vigencia because SENASA sits behind ARCA fiscal keys. That scope boundary is the kind of behavioral context annotations cannot convey.

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

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

Front-loaded with the verb, resource and format before the caveats, and each sentence earns its place. The appended English translation is mildly redundant for an agent but does not harm routing.

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

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

With no output schema, the description carries the return-value burden well by listing the decoded segments (provincia, departamento, jurisdicción, establecimiento, productor). Combined with the format and the vigencia limitation, an agent has everything needed to call and interpret 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?

One parameter with 100% schema coverage, so baseline is 3. The description adds meaning beyond the schema by specifying the 17-character structure and format mask (00.000.0.00000.00), reinforcing the segment layout the schema's example only implies.

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 pair (valida/decodifica) and resource (código RENSPA), defines the resource, gives the exact format (17 caracteres, 00.000.0.00000.00), and enumerates the returned segments. No sibling tool overlaps with RENSPA decoding, so it is easily distinguished.

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 a when-not: it does NOT check live validity ('NO consulta la vigencia en vivo') and routes the agent to the official public source for that purpose. Strong context, though it does not name a sibling tool alternative, so not a full 5.

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

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

Goes well beyond the annotations by resolving the apparent write-vs-read tension: it states it does not charge, returns an exact amount plus an x402 endpoint, and prices at the blue-dollar rate of the day against the ARS 45.000/mes list price. That is exactly the behavioral context an agent needs to avoid assuming a payment is executed.

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?

Purpose and the no-charge caveat are front-loaded, but the middle is a long semicolon-chained list of PRO benefits (sello ★, remates resaltados, newsletter, panel de visitas, cruce Cañuelas) that mostly sells rather than informs tool selection. Two sentences carried by that list do the work of one.

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

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

With no output schema, the description usefully says what comes back (amount and x402 endpoint), what the pricing basis is, and what the two parameters mean. It does not say what happens on an invalid slug, or whether a follow-up call completes activation after payment.

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 the baseline is 3; the description still adds the provenance of 'slug' (directorio entry) and the sibling tool to resolve it, which the schema does not say. The 'meses' range and default merely restate the schema.

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

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

States a specific verb and resource ('Cotiza y explica cómo activar PRO Consignataria pagando en USDC'), and the key sentence 'Esta tool NO cobra: devuelve el monto exacto y el endpoint x402 para pagar' pins down what the call actually does versus what its name implies. The long benefits enumeration occupies most of the text and slightly blurs whether this is a marketing blurb or a transactional quote tool.

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

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

Gives an explicit routing rule for the required parameter ('usá find_livestock_broker si no lo sabés'), which is the most likely failure mode for an agent. No guidance on when *not* to use it, or on how it relates to the /planes web page beyond the price equivalence.

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

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

Annotations already cover readOnly/idempotent/openWorld/non-destructive, so the safety profile is free. The description then adds genuine behavioral context beyond them: only future scheduled auctions, date-ascending ordering, default 10 with a hard cap of 50, and live-broadcast flag in the response.

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

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

Front-loaded with purpose and scope, then return fields, then params, then exclusions — a sensible ordering with no filler. The trailing [EN] one-liner is mildly duplicative of the opening sentence but aids routing.

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?

Two-parameter, read-only tool with an output schema and full schema coverage. The description covers scope, ordering, defaults, caps, filter semantics, and the nearest alternatives — nothing an agent needs for correct invocation is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: provincia is a substring match (not exact) and is optional, and limite has a maximum of 50 that the schema description omits.

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

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

Names a specific resource and scope: a calendar of upcoming Argentine cattle auctions, restricted to future-dated scheduled events, ordered by date. It also enumerates the returned fields, so an agent knows exactly what it is getting without opening the schema.

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

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

Explicitly states the negative case and routes elsewhere: no prices or INMAG here, use livestock_prices/cattle_price_index. Combined with the 'solo programados, fecha ≥ hoy' constraint, an agent can decide between this and the price siblings without inference.

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

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

Beyond the annotations (readOnly/openWorld/idempotent, non-destructive), it discloses meaningful behavior: never invents a range, degrades to national reference and says so, reports the sample size behind the band, includes both blue and official USD rates, and is free with no quota. That is substantive, though the return details partially overlap with the existing output 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 hook question is front-loaded and earns its place by demonstrating the input shape, and the fallback/methodology notes are relevant. Some waste remains: the trailing parameter list duplicates the schema and the [EN] sentence repeats already-covered meaning.

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 read-only valuation tool with four params, full schema coverage and an output schema, the description covers what an agent needs: what it returns, what happens when data is thin, and how to call it. Nothing material is missing.

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

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

Schema description coverage is 100% with an enum on categoria, so the schema already carries the parameter burden. The description only restates the params and the kg_promedio default, adding little beyond what the schema and its descriptions already say.

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

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

States a specific verb and resource (valúa una tropa de hacienda) plus the exact output shape: P10/median/P90 band from observed MAG lot operations, with lot/head backing, USD totals and dated source. The quantity-based scoping ('¿Cuánto valen 350 novillos?') makes it clearly distinct from index-style siblings like livestock_prices, cattle_price_index or price_dispersion_history.

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 leading example establishes the use case concretely, and the description gives an explicit fallback rule (falls back to MAG national reference and declares it when a category lacks lot depth) plus notes which params are optional and what happens when kg_promedio is omitted. It does not name a competing sibling to route away from, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description adds value on other axes: it discloses data provenance (own survey of 15 provinces and 52 zones, cross-referencing appraisers, published series, cadastral records, and sale listings) and states there is no quota or cost ('GRATIS, sin cupo'). It does not detail coverage limits or how partial data is handled when a zone is unknown.

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?

Purpose is front-loaded, but the body is padded with marketing questions, a 'GRATIS, sin cupo' pitch, a recitation of parameters already fully described in the schema (including an omission of qq_soja_ha_anio while listing the others), and then an English restatement. Several sentences do not earn their place.

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

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

For a read-only lookup with a fully documented schema and no output schema, the description supplies what is otherwise missing: data provenance, geographic coverage, dual valuation methodology, and the fact that results come with a source. The one thing an agent still cannot resolve from the description is when to prefer this tool over the rent-calculation siblings.

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 the schema already documents every parameter including the zona/partido flexibility and the kg/ha/month canon. The description reinforces the two canon regimes (kg of steer per ha per month vs. quintales of soy per ha per year) but adds little beyond what the schema states, and it recites parameters rather than enriching them.

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

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

The description states a specific resource and output: value of Argentine farmland per hectare in USD, per province and zone, with observed range, typical lease in kg of steer, and source per data point. It notes the cattle-vs-agricultural distinction and each one's unit. It never names the closely related siblings (value_farmland_rent, calculate_farmland_rent) that an agent would have to choose between, so it stops short of a 5.

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

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

Use context is only implied through rhetorical questions ('¿Cuánto vale la hectárea en Corrientes?'), which sketch a scenario but give no explicit when-to-use/when-not or alternative. With overlapping siblings like value_farmland_rent and calculate_farmland_rent in the same namespace, the absence of any routing rule is a meaningful gap.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower; the description nonetheless adds real context: the index source by code, the fact it is free and uncapped, the currency and period granularity of the answer, and fallback behavior when a parameter is absent. It does not describe response shape in detail, but the added behavioral traits are substantive.

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

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

It is front-loaded with a concrete user question that anchors the use case, followed by method, units, and parameter behavior in a compact sequence. The [EN] translation and the explicit 'Params:' enumeration duplicate what follows in the schema, costing a little economy, but overall it is dense rather than padded.

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

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

With no output schema, the description carries the return-value burden and does so: it specifies annual and monthly figures, ARS and USD, exact canon versus scenarios, and names the official index used. The only remaining ambiguity an agent must resolve is the overlap with the closely named 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?

Schema coverage is 100%, so the baseline is 3; the description earns one more by explaining the consequence of each optional parameter — kg_ha_anio switches from exact canon to 40–100 kg/ha/year scenarios — which sharpens what the schema only sketches ('se responden escenarios'). The restated param list is redundant but the scenario range adds genuine meaning.

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

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

The description states a concrete verb and resource — valuing farmland rent against the official MAG index (haciinfo000013) — with concrete output units (ARS/USD, annual/monthly). It is clear on its own, but it never differentiates itself from the sibling 'calculate_farmland_rent', which sounds functionally identical, nor from 'value_farmland' (land value vs. rent).

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

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

It gives an explicit branch condition: providing kg_ha_anio yields the exact canon, omitting it returns 40–100 kg/ha/year scenarios. That is clear usage context. However, there are no exclusions or sibling routing (e.g., when to prefer 'calculate_farmland_rent' or 'value_farmland' instead), so the guidance stops short of the top band.

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