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

No annotations exist, so the description carries the full behavioral burden, yet it says nothing about time coverage, units, frequency, data vintage, or whether results are static or historical. The output schema covers the return shape, but the operational traits an agent needs before calling are absent.

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?

Short and front-loaded, with the core purpose stated before the supporting product list. The 'Args:' block is slightly redundant boilerplate but costs little.

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

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

For a one-parameter tool with an output schema, most of the definition is sufficient, but critical context for a supply-and-demand balance — the period covered, units, and update frequency — is missing from both the description and the structured fields.

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

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

Schema coverage is 0% and the parameter has no enum, but the description compensates by listing all six accepted product values and giving examples. That is meaningful added meaning beyond the bare 'Produto' string field 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 names a specific resource and enumerates its dimensions (stock, consumption, exports), which distinguishes it reasonably well from siblings like producao_anual or exportacao that cover only one slice. It is not a tautology, though it never explicitly contrasts itself with those siblings.

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?

There is no statement of when to use this tool versus producao_anual, exportacao, serie_historica_safra, or the other agricultural-data siblings. The list of valid products is data validation, not usage guidance, so the agent must infer the selection criterion.

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

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

No annotations are provided, so the description carries the burden. It describes the data fields and parameters but does not disclose whether the operation is read-only, any limitations on data range, or error behavior. It is minimally transparent.

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

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

The description is concise and well-structured: one line for purpose, a bulleted list of valid states, and a clear parameter section. Every sentence adds value with no redundancy.

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

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

Given the presence of an output schema, the description does not need to detail return values. It covers purpose, parameters, and valid inputs adequately. Could mention data coverage (recent years) or output format but overall complete for a simple retrieval 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?

With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning, including a list of valid state abbreviations, default values, and allowed values for 'agregacao'. This adds significant value beyond the schema.

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

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

The description clearly states 'Recent climate data by state' with specific data types (temperature, precipitation, radiation, humidity, wind), providing a specific verb (retrieve) and resource (climate data) that distinguishes it from siblings.

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 lists valid states and default values but does not explicitly mention when to use this tool versus alternatives (e.g., 'desmatamento' or 'balanco'). It implies use for climate queries but lacks exclusions or 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?

No annotations, so the description carries the full burden, and it does so well: it discloses the 2000-record cap with a reported cut, and the PRODES fallback year behavior. Missing auth/permission notes and any note on latency or quota, 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?

Front-loads purpose, then fine-grained mode details before the args list. Efficient overall, though 'Default: see above' is a slightly awkward cross-reference and the docstring formatting adds minor bulk.

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 described. Parameters and behavioral caps are covered; the remaining gap is the vague 'Default: see above' for ano and the absence of any pitfalls around the record cap truncation.

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

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

Schema coverage is 0%, so the description must compensate, and it documents all four params: bioma with enumerated examples, sistema with prodes/deter semantics, ano with distinct PRODES vs DETER meaning, and uf with empty=whole-biome behavior. This goes well beyond the bare 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 resource and scope: 'Deforestation polygons and alerts by biome.' It is clearly distinct in subject matter from siblings like queimadas or clima, though it never explicitly names an alternative tool. The verb/resource are concrete enough that an agent knows what it fetches.

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 two modes and when each applies: 'prodes' = polygons for the previous calendar year, 'deter' = alerts of the last 15 days. This gives clear selection context but no explicit when-not-to-use or sibling 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?

No annotations are provided, so the description carries the full burden: it does not state whether this is a read-only query, whether any auth or rate limits apply, or how large the per-state response is. It discloses the output dimensions (area/production/yield by state), but that overlaps with the output schema and adds little behavioral context.

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 purpose in the first line, then lists products and parameters compactly with no filler. The Args block is a bit boilerplate but each entry carries 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?

An output schema exists, so return values needn't be explained, and both parameters are documented. However, for a tool sitting among five other safra/production-related siblings, the absence of any disambiguation guidance leaves a real gap for an agent choosing between them.

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

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

Schema coverage is 0%, so the description must compensate, and it does: produto is explained as the crop name with six concrete examples, and safra is given the 'YYYY/YY' format plus its default behavior. The only gap is that the crop list is not framed as a closed enum despite being presented as a fixed set.

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 ('crop season estimate by state') and names the three measures returned (area, production, yield). The word 'Current' implicitly separates it from serie_historica_safra and producao_anual, but it never names a sibling explicitly.

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

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

No statement of when to use this versus progresso_safra, serie_historica_safra, or producao_anual, and no exclusions or prerequisites. The only usage-ish hint is that safra defaults to the latest season with data, which is a parameter default rather than routing guidance.

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

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

With no annotations, the description carries the full behavioral burden and partially meets it: it discloses the data-source fallback chain (Comex Stat with ABIOVE fallback) and a latency warning of roughly one minute. It says nothing about permissions, rate limits, or whether results are cached, and never explicitly frames the operation as a read-only 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?

Purpose is front-loaded in the first line, followed by a compact product list, a latency note, and three short arg lines. The docstring-style 'Args:' block is slightly formal overhead but nothing is padded or 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?

An output schema exists, so return structure needn't be described. Combined with the product enumeration, geography semantics, source fallback, and latency caveat, an agent has enough to invoke this correctly; only the ano default discrepancy leaves a small ambiguity.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it enumerates the seven valid produto values, gives the 'MT' style for uf, and explains that empty uf means all of Brazil. The only weak spot is ano, where it says 'default: current year' while the schema default is 0.

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 transformation: 'Brazilian agricultural exports summed by month', plus the upstream sources (Comex Stat, ABIOVE fallback). An agent can distinguish it from producao_anual or preco_diario by the export/monthly framing, though it never names a sibling explicitly.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. The product list defines scope implicitly, but an agent gets no help deciding between this and the production, balance, or price tools in the sibling set.

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

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

With no annotations, the description carries the full burden. It usefully discloses the default behavior (latest published session), the exact contract list, and the date format, but says nothing about permissions, whether the date must be a valid trading session, or error behavior for invalid contracts.

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 purpose in the first line, then the contract list, then parameter semantics. Compact and well-structured, with only minor redundancy from the docstring-style Args block.

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, and the parameters are covered. However, for a two-parameter tool with no annotations, the definition omits usage context relative to sibling price tools and validation/edge-case behavior.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it names both parameters, gives example contract values, enumerates the seven valid contracts, and specifies the YYYY-MM-DD format and default for data.

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: daily settlement prices for agricultural futures on the B3 exchange, plus the exact contract universe. An agent can identify what it retrieves, though it does not differentiate itself from sibling price tools like preco_diario or serie_historica_safra.

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

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

No when-to-use guidance and no exclusions. Given siblings such as preco_diario and serie_historica_safra, the agent is left to infer which price endpoint applies; the description only notes the default date behavior.

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

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

With no annotations, the description fully conveys that it is a read-only diagnostic tool that returns status information, which is sufficient for its simple purpose.

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

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

The description is extremely concise with two sentences that front-load the purpose and provide immediate value, with no redundant phrasing.

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

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

Despite no parameters or annotations, the description fully covers what the tool does and when to use it, which is adequate for a simple health check tool with an output schema.

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

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

There are no parameters, and the schema coverage is 100%, so the description does not need to add parameter information beyond what is already clear.

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

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

The description clearly states the verb 'Check the status' and the resource 'agrobr data sources', distinguishing it from sibling tools that provide specific data.

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

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

It provides explicit guidance that the tool is useful for diagnosing when other tools return errors, but does not mention when not to use it or provide 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?

No annotations are provided, so the description carries full burden. It implies a read-only listing operation but does not explicitly state safety, rate limits, or other behavioral traits. It discloses the basic behavior but lacks depth.

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

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

The description is short, with front-loaded purpose and no unnecessary words. It achieves clarity in two sentences and a concise parameter description.

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

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

Given the simplicity of the tool and the presence of an output schema (not shown), the description covers the main purpose and usage. Missing error handling or result details, but it is largely complete for a discovery 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?

The description adds significant meaning beyond the schema, explaining the 'tool' parameter with an example and default behavior. Since schema coverage is 0%, this compensation is valuable and clear.

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

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

The description clearly states the tool lists valid products/parameters for each tool, which distinguishes it from sibling data tools. However, the phrase 'products/parameters' is slightly ambiguous, preventing a top score.

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

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

The description mentions it is useful for discovering values before calling another tool, providing clear context. It does not explicitly state when not to use it or name alternatives, but the guidance is sufficient.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the data source, the default (5) and the hard cap (60 days), but says nothing about units/currency, whether non-trading days are skipped, error behavior for an unlisted product, or any rate limits.

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 source, followed by a compact product list and a short Args block. Every line is informative; the docstring-style formatting is slightly verbose but not wasteful.

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 no explanation, and the description covers both parameters plus the valid product set. Minor gaps remain around units/currency and invalid-product behavior, but the essentials for a correct call are present.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains that 'produto' is a commodity name with examples and that 'dias' is the number of recent days with a default of 5 and max of 60. It adds real meaning beyond the bare schema, though it doesn't state case-sensitivity or what happens on invalid input.

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 (daily spot prices for Brazilian agricultural commodities), names the data source (CEPEA/ESALQ), and enumerates the eight valid products. This distinguishes it from siblings like futuros_b3 (futures) and serie_historica_safra (historical series) without needing to open 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?

Usage is implied by 'daily spot prices' and the product list, but there is no explicit statement of when to use this versus siblings such as futuros_b3 or serie_historica_safra, and no exclusions or prerequisites are given.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses little beyond the topic and default year behavior. It says nothing about data granularity (state-level only?), geographic filtering, permissions, rate limits, or freshness of the historical series.

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 in the first line, followed by the useful enumerated product list and a compact Args section. Every line earns its place, though the inline bullet-style product list makes it slightly longer than strictly necessary for a two-parameter 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?

An output schema exists, so return values do not need explaining, and both parameters are documented. However, for a tool sitting among many crop-related siblings, the missing differentiation and absence of any behavioral or access context leaves gaps relative to the complexity of the surrounding tool set.

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 0% schema description coverage, the description compensates well: it enumerates the eleven accepted crop names for 'produto' and explains that 'ano' is the reference year defaulting to the previous year. One inconsistency remains — the schema declares ano default as 0 while the description says 'previous year' — but the value added over the bare schema is substantial.

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: historical annual crop production by state, sourced from IBGE PAM. It is clear what the tool returns, though it does not explicitly distinguish itself from siblings like estimativa_safra, progresso_safra, or serie_historica_safra that inhabit the same crop-data domain.

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

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

No when-to-use or when-not-to-use guidance is given, and no sibling is named as an alternative. An agent must infer from the phrase 'historical annual' that this is retrospective annual production rather than the forecast/progress data offered by other crop tools.

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

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

No annotations are provided, so the description carries the burden. It adds useful cadence ('weekly') and enumerates valid products, which functions as an inline enum since the schema has none. It omits any statement about read-only semantics, data source, or coverage limits, so the disclosure is only partial.

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 in the first sentence, followed by a products list and per-argument notes. The docstring formatting with indentation is slightly padded, but every element 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?

With an output schema present, return values need no explanation, and both parameters are documented plus the valid product set. The remaining shortfall is the absence of routing context against near-duplicate safra siblings, which matters given this tool family's complexity.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it names both parameters, gives examples for produto ('soja', 'milho_1') and uf ('MT', 'PR'), and explains that empty uf means all states. The only gap is that it does not resolve the produto/uf interaction or confirm the product list is exhaustive.

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 gives a specific verb+resource+scope: 'Weekly planting and harvesting progress by state.' An agent knows exactly what data this returns. However, it never distinguishes itself from close siblings such as estimativa_safra or serie_historica_safra, which likely cover related safra data.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternatives despite a crowded set of safra-related siblings (estimativa_safra, serie_historica_safra, producao_anual, listar_produtos). The agent must infer routing purely from the tool name.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely valuable behavioral trait: counts come from the AQUA_M-T reference satellite because other satellites double-count the same fire. It omits permission requirements, rate limits, and error behavior, so the disclosure is partial.

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 purpose, followed by the satellite caveat and a compact Args block. The satellite explanation earns its space by clarifying what the numbers mean; 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?

For a two-parameter read tool with an output schema, the return structure needs no explanation, and both parameters plus the aggregation semantics are covered. Only usage guidance is missing, which is a minor gap given the tool's simplicity.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: 'uf' is defined as a state abbreviation with examples ("MT", "PA") and 'data' as a YYYY-MM-DD date with a default of yesterday. This resolves ambiguity the bare schema leaves (including the empty-string default on 'data').

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 (fire hotspots from INPE Queimadas) with a clear temporal scope (one day) and grouping (municipality and biome). It does not explicitly contrast itself with any sibling tool, but among agricultural/economic siblings its identity is unmistakable.

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 never says when to use this tool versus alternatives, nor any prerequisites such as needing a valid state abbreviation or coverage limitations. Usage must be inferred entirely from the tool name and data source.

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

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

No annotations are provided, so the description carries the burden, and it does disclose the data source (IBGE PPM), the geographic granularity (by state), and that 'ano' defaults to the latest published year. It does not describe validation of 'produto', error behavior, or pagination, and the stated default ('latest published') conflicts with the schema default of 0, which is a mild ambiguity an agent must resolve.

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 statement is front-loaded in the first sentence, and the long product enumeration earns its space by substituting for a missing enum. The 'Args:' block is slightly verbose but well structured and contains no filler.

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

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

An output schema exists, so return-value documentation is not required, and for a read-only data-retrieval tool the source, granularity, valid inputs, and default are the essentials. The only residual gap is the unexplained mismatch between the documented default and the schema's numeric default of 0.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it enumerates all 17 valid values for 'produto' (acting as an inline enum) and gives examples plus the default semantics for 'ano'. It adds meaning well beyond the bare schema, though it does not explain how the sentinel value 0 for 'ano' maps to 'latest published'.

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 concrete resource (livestock herds and animal products) and its granularity (by state) and source (IBGE PPM), so an agent knows exactly what dataset is returned. It does not explicitly differentiate itself from siblings like producao_anual or exportacao, but those cover clearly different datasets, so confusion is unlikely.

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?

There is no when-to-use guidance, no mention of prerequisites, and no pointer to alternative tools such as producao_anual or listar_produtos. Usage is only implied by the data domain, leaving the agent to infer the right context.

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

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

No annotations, so the description carries the full burden. It discloses the source (CONAB) and the returned measures (area, production, yield), which is useful, but says nothing about permissions, rate limits, or whether the series is point-in-time vs. continuously revised.

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 in the first line, but the 44-value product dump dominates the body, and the verbatim 'Args:' docstring style is slightly raw. The list is defensible since the schema lacks an enum, but the overall shape is list-heavy rather than 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?

For a 3-parameter read tool with an output schema, the description covers all parameters and the critical valid-value list, so return format need not be restated. The notable gap is the absence of any routing guidance against the many sibling series 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 0%, so the description must compensate, and it largely does: it enumerates 44 valid 'produto' values (absent from the schema as an enum), explains uf semantics ('Empty = Brazil, summed over the states'), and clarifies ano_inicio as the start year with a 10-years-ago default.

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 historical (seasonal) crop series from CONAB returning area, production and yield. This is clearly distinguishable from data-set siblings like producao_anual and progresso_safra, though the description never explicitly contrasts itself with them.

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

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

No when-to-use guidance at all: nothing says when to prefer this historical-series tool over estimativa_safra or producao_anual, and no prerequisites or exclusions are given. The Args block is parameter documentation, not usage guidance.

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