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

With no annotations, the description carries the full burden and does well: it discloses the side effect (writes to the local database), that data comes from the official site, and rough performance costs (SINAPI ~1 minute, ORSE a few minutes). It omits whether existing data is overwritten or what happens on failure, 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?

Purpose is front-loaded in one sentence, followed by tight per-parameter lines with no filler. Every statement carries information the caller needs, and the size is well matched to a three-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 need not be explained, and the description covers parameters, side effect, and timing well for a mutation tool with no annotations. The remaining gap is failure/overwrite behavior, which keeps it short of fully complete.

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

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

Schema coverage is 0%, so the description must compensate, and it does thoroughly: it enumerates the valid base values (SINAPI, SICRO, ORSE, SEINFRA) that the schema lacks as an enum, states the conditional ufs requirement per base and the 27-UF default, and gives competencia's format plus the SEINFRA version exception and empty-means-latest behavior.

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 opening sentence gives a concrete verb and resource: downloads a base from the official site and writes it into the local database. The role is distinguishable from siblings like buscar_precos or orcar, though the description never explicitly names an alternative tool, so it falls just short of full sibling differentiation.

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 rather than stated: it is clearly the download/update operation, and the per-parameter rules (SICRO requires ufs, SINAPI filters them) are given. However, there is no explicit when-to-use vs when-not guidance, e.g. checking bases_disponiveis first or preferring this over querying the current local base.

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 that the response combines two things (supported bases and already-downloaded state), which is behavioral context beyond the name, but it never states that the call is read-only, local, side-effect free, or whether it hits the network.

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?

A single front-loaded sentence with no filler; the output dimensions (UF, regime, competência) are parenthesized at the end where they belong. Every word 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?

An output schema exists, so return values need not be spelled out, and the description still names the key fields the result exposes. For a zero-argument listing tool this is nearly sufficient; only the read-only/local nature and its role relative to atualizar_base are left unstated.

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 the baseline is 4; there is nothing for the description to disambiguate. Schema coverage is reported at 100% but the object is empty.

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 ("Lista") and two concrete resources: the supported price bases and what is already downloaded in the local database, further scoped to UF, regime and competência. It does not name a sibling explicitly, but the read/list framing distinguishes it cleanly from atualizar_base (write) and buscar_precos (lookup).

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 only implied: an agent can infer this is the preflight/discovery call before atualizar_base or buscar_precos, but the description never states when to use it instead of those siblings, nor any prerequisites. No exclusions or alternatives 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?

With no annotations, the description carries the full burden and delivers: it documents the env-var default for uf, that an empty base means 'todas as que estiverem baixadas', that an empty competencia selects the most recent, and that empty tipo returns both. It does not mention pagination/limite behavior, which is a notable gap for a search tool.

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

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

Purpose is front-loaded in one sentence, followed by a compact parameter-by-parameter list with no filler. Each line earns its place; only the missing 'limite' line hints at incompleteness rather than verbosity.

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 description compensates well for the 0% schema coverage on inputs. The only material gap is the undocumented 'limite' parameter, but otherwise an agent has enough 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 0%, so the description must compensate, and it does for 6 of 7 parameters, giving format examples ('AAAA-MM'), allowed values (SINAPI/SICRO/ORSE/SEINFRA, sd/cd, composicao/insumo) and empty-value semantics. The 'limite' parameter is left entirely undocumented, which keeps this from a 5.

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: it searches 'serviços (composições) e insumos' by 'descrição ou pelo código'. This clearly distinguishes it from siblings like detalhar_item (which presumably details a single known item). It does not explicitly name a sibling, but the purpose is unambiguous.

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

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

Conditional usage is embedded in the parameters (uf mandatory for SINAPI/SICRO, regime only for SINAPI/SEINFRA, empty base = all downloaded), which the agent can infer. However, there is no explicit routing guidance about when to use this versus detalhar_item, orcar, or comparar_ufs.

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 bears the full disclosure burden. It usefully discloses that the tool compares each component against the acórdão's faixas and that cprb is regime-dependent (4.5 desonerado, else 0), but it does not state that this is a pure read-only computation, that no auth/writes occur, or how out-of-range components are reported.

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/source, then gives a compact parameter glossary and the tipo_obra enumeration. Dense but every line earns its place; 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?

With an output schema present, return values need not be explained, and the description supplies the otherwise-absent parameter semantics for a 10-parameter tool. The main gaps are usage guidance and the percent-vs-fraction convention, but it is substantially complete for a calculator with no annotation coverage.

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: it expands all ten parameter abbreviations (ac, sg, r, df, lucro, iss, pis, cofins, cprb) and lists the valid tipo_obra values. It also clarifies the unit ('Valores em %'), though it leaves ambiguity about whether values are percentages or fractions and omits the schema defaults.

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 ('calcular BDI') and names the exact formula source (Acórdão 2622/2013-TCU), plus the extra behavior of comparing components against the acórdão's faixas. This clearly distinguishes it from siblings like orcar, buscar_precos, and comparar_ufs, which deal with pricing rather than BDI computation.

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 this is the tool for computing BDI once indirect-rate components are known, but it never states when to use it versus siblings like orcar, nor any prerequisites (e.g., needing a base loaded via atualizar_base). Usage is inferable from the parameter context 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?

No annotations are provided, so the description carries full behavioral burden. It discloses the scope (all downloaded UFs) and ordering (cheapest to most expensive), but does not state that it is a read-only operation, nor does it mention error handling or permission requirements.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's core output and ordering.

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 four parameters with no schema descriptions, no annotations, and an output schema that only covers returns, the description is incomplete. It does not explain input semantics (especially base) or provide usage context, leaving significant gaps for correct invocation.

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

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

With 0% schema description coverage, the description must explain all four parameters. It references the item (codigo), competence (competencia), and regime, but completely omits the base parameter and provides no format or allowed values for any parameter.

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

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

The description clearly states the tool returns the price of an item across all downloaded UFs, sorted from cheapest to most expensive under the same competence and regime. It is specific about scope and ordering, but does not explicitly differentiate itself from sibling tools like buscar_precos.

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 the scope—comparing prices across UFs—but there is no explicit guidance on when to use this instead of alternatives such as buscar_precos. No exclusions or prerequisites are mentioned.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose that the response is scoped by UF, regime and competência and covers historical stored prices. It says nothing about permissions, error behavior, or result size for a potentially large historical dump, so it only partially meets the heavier no-annotation bar.

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?

A single, front-loaded sentence that leads with what is returned before the goal clause; nothing is padded. It is slightly dense with parenthetical qualifiers but no sentence is wasted.

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 format needn't be explained, but the combination of zero annotations and 0% parameter coverage leaves the agent without guidance on the required codigo, the base options, or valid regime/UF values. For a four-parameter tool this is a material gap.

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% across four parameters, so the description must compensate and largely does not. It hints at 'uf' and 'regime', but never explains the required 'codigo', the 'base' default of SINAPI, or accepted values for any of them, and it mentions 'competência', which is not even a parameter.

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 verb+resource (detail an item) and enumerates what is returned: full description, group, and all stored prices broken down by UF, regime and competência. That is more than a tautology. It does not, however, distinguish this tool from close siblings such as buscar_precos or comparar_ufs, 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?

The only usage signal is the trailing clause 'para ver a evolução do preço no tempo', which describes the goal rather than when to pick this tool over buscar_precos or comparar_ufs. No prerequisites, no exclusions, no named alternatives 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 disclosure burden. It usefully reveals the pricing model (code × quantity × base price, BDI over direct cost) and the per-item base override rule, but says nothing about missing codes, invalid base/uf combinations, permissions, or failure behavior.

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

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

Compact and front-loaded: the purpose leads, followed by a concrete item example and the base fallback rule. Every sentence adds value, with only minor terseness in the item example syntax.

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 6-parameter, 0%-coverage tool this leaves substantial gaps: uf, regime (default "sd"), and competencia are undocumented both in the schema and the description, so an agent cannot reason about what they control. An output schema exists, so return values need no explanation, but the unexplained input params are a real deficiency.

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% across 6 params, so the description must compensate. It does document the itens structure with a concrete example and clarifies base as the fallback when an item omits its own; however uf, regime, and competencia are left entirely unexplained, including their defaults.

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 ("Monta um orçamento rápido") and spells out the computation as código × quantidade × preço da base with BDI applied over direct cost. This clearly distinguishes it from siblings like calcular_bdi or buscar_precos, though it never names those alternatives.

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

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

The description explains the mechanics of the calculation but gives no when-to-use guidance, no prerequisites, and no exclusions relative to calcular_bdi, buscar_precos, or bases_disponiveis. Usage is only implied by the word "rápido".

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