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.