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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds useful operational context: no authentication and a 60 requests/minute limit. It also indicates the comparative output nature, though it does not detail response structure 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?

The description is three tight sentences. It front-loads the core comparison purpose, then adds rate-limit context and sibling-tool routing without unnecessary repetition.

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 rich annotations and a fully described schema, the description is largely complete for selecting and invoking the tool. A minor gap remains around how the indicador values correspond to the advertised fuels, LPG, and food-basket comparisons.

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 already documented. The description adds that origem_uf and destino_uf are Brazilian state codes and points to brazil_list_states, but it does not map the indicador enum values or clarify how the food basket fits with the available enum options.

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

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

The description uses a specific verb and resource: it compares weighted average prices and percentage deltas for fuels, LPG, and food baskets between two Brazilian states. It clearly distinguishes itself from sibling tools by naming drilldown alternatives for single-state analysis.

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

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

It explicitly routes the agent to brazil_list_states for valid UF codes and to brazil_fuel_prices and brazil_grocery_basket for single-state drilldowns. This makes the comparison use case and alternatives clear without requiring 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 declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely new operational context: daily refresh cadence and an unauthenticated rate limit of 60 req/min, which an agent must know for batching decisions. It stops short of describing the returned index composition or rounding/units, keeping it at a 4.

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

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

Three sentences, all front-loaded: what it computes, freshness/auth/limits, then the routing alternatives. No sentence is redundant and nothing is buried; every clause carries distinct 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?

With no output schema and only two optional parameters, the description covers everything an agent needs: what the index aggregates, freshness, auth and rate limits, the default-to-national-average behavior (also in schema), and clear sibling routing. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 100% — both 'uf' (two-letter state code, defaults to national average) and 'comparar_com_dolar' (BRL→USD conversion) are fully documented in the schema. The description reinforces the aggregation inputs but adds no parameter syntax or format detail beyond what the schema already supplies, 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: 'Computes a consolidated regional cost-of-living index and purchasing power parity (PPP) in Brazil', then names the exact inputs it aggregates (fuel expenditure, food basket, USD/BRL). It explicitly distinguishes itself from siblings brazil_fuel_prices, brazil_grocery_basket, and brazil_compare_regions, so 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?

Gives explicit when-not guidance: use brazil_fuel_prices or brazil_grocery_basket for item-level breakdowns, and brazil_compare_regions for two-state side-by-side comparisons. The condition selecting this tool (a consolidated index/PPP view) versus each alternative 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered; the description adds the non-authentication requirement and the data provenance (official ANEEL) plus default behaviors. It does repeat the read-only claim, but the auth and source context are genuine additions. It stops short of describing output shape or cost/rate-limit 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?

A single dense paragraph that front-loads the data source and coverage before the computations. Every clause is relevant, though the concessionaire enumeration (Light, Enel, Cemig, Copel, Equatorial, Celesc) is slightly verbose for an agent that only needs the scope.

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 must convey what is returned, and it does explain the three outputs (tariffs, estimated bill, thermal parity) along with defaults and the read-only/no-auth profile. It does not describe the response structure or units, which is the main remaining 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 100% and all three parameters (uf, consumo_mensal_kwh, incluir_paridade_termica_gas) are fully documented with defaults, so the schema does the heavy lifting and baseline is 3. The description largely restates the 150 kWh default and parity definition already present in the schema, adding little beyond that.

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

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

States specific verbs and resource: provides official ANEEL residential tariffs (B1) across 27 UFs, computes estimated monthly bills, and calculates LPG-vs-induction thermal parity. The scope (residential B1, state concessionaires like Light/Enel/Cemig) clearly distinguishes it from siblings such as brazil_lpg_gas_prices or brazil_fuel_prices.

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 described computations but there is no explicit when-to-use, when-not-to-use, or named alternative among the many Brazil siblings. An agent can infer it is for electricity-tariff/bill questions, but nothing routes it against brazil_lpg_gas_prices even though both touch cooking-fuel cost.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description usefully adds that no authentication is required and that outputs include a diesel expense ratio and per-kg logistical cost impact, which is behavior beyond the annotations.

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

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

Three dense sentences, front-loaded with the core purpose and regulation, then scope, then derived outputs. Little waste, though the regulatory citation is verbose.

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

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

With no output schema, the description compensates by naming derived outputs (diesel fuel expense ratio, cost impact per kg). Combined with full schema coverage and annotations, this is largely complete, though exact return fields remain unspecified.

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 two enums, so the schema already documents all five parameters including defaults. The description adds domain framing (axle classes, cargo types) but omits the 'perigosa' cargo enum value, so it adds only marginal value.

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 (calculates) and resource (official ANTT minimum road freight rates) with regulatory citation, and the scope (vehicle classes 2-9 axles, cargo types). Distinct from siblings like brazil_fuel_prices and brazil_compare_regions without needing their 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?

Implies usage context (freight rate computation correlated with diesel prices), but gives no explicit when-to-use or when-not-to-use guidance relative to siblings such as brazil_fuel_prices or brazil_cost_of_living. The agent must infer the scenario.

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 disclosing operational constraints an agent cannot infer: 60 req/min rate limit, a hard cap of 50 stations returned per call, weekly refresh cadence, SEFAZ NFC-e cross-validation, and that no authentication is needed at standard limits. The readOnlyHint/idempotentHint annotations only cover the safety profile, so this added context is genuinely valuable.

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?

Strongly front-loaded: the core action and resource come first, then coverage scope, then constraints, then routing guidance. It is dense—three long sentences packed with stats—but essentially every clause carries decision-relevant information, with only minor density cost.

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, three-parameter tool with no output schema, this covers everything needed to invoke it correctly: prerequisites, valid code discovery path, rate limits, result cap, refresh cadence, and when to prefer a sibling. Nothing an agent needs before calling 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%, so the baseline is 3, but the description adds a useful mapping from human-readable fuel names (Regular Gasoline, Additive Gasoline, Hydrous Ethanol, Diesel S10, CNG) to the Portuguese enum values an agent must actually pass. It also reinforces the 'omit cidade for statewide summary' behavior from the schema, though it adds no syntax detail for uf beyond what the schema already states.

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 (queries), resource (real-time audited retail fuel prices in Brazil), the exact fuel categories covered, the data source (ANP), and the geographic scope (4,750+ stations, 27 states). An agent can immediately distinguish this from brazil_lpg_gas_prices and brazil_grocery_basket without opening a 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 routes the agent: 'Use brazil_list_states first to discover valid state codes (uf), or brazil_compare_regions to compare averages between two states.' Both the prerequisite step and the alternative tool for a different intent are named, so there is nothing 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description still adds meaningful context beyond that: the data provenance (NFC-e SEFAZ invoices, DIEESE methodology), daily refresh cadence, and a concrete rate limit (60 req/min) with no auth needed. It does not describe return shape or pagination, but with no output schema and rich annotations, this is close to fully 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?

Three dense sentences, front-loaded with what the tool returns and where the data comes from, followed by operational constraints, then sibling routing. No filler or repetition of the title.

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 no output schema, the description supplies everything an agent needs: data source, item coverage, geographic scope (59 hubs), update frequency, rate limit, auth requirement, and alternative tools. 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 coverage is 100% and each of the three parameters carries its own description with examples ('sp', 'arroz', 'cesta basica'). The description's mention of the 13 basket items loosely contextualizes the 'produto' parameter but adds no syntax, format, or defaulting detail beyond the schema, 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 pair ('Queries and compares') plus a precise resource ('real-time audited prices of Brazil's 13 Basic Food Basket items') with source attribution (NFC-e SEFAZ, DIEESE) and scope (59 regional hubs). This clearly separates it from siblings covering fuel, LPG, pharma, cost of living, or cross-region comparison.

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: 'Use brazil_list_states to check regional coverage, brazil_cost_of_living for full household budget synthesis, or brazil_compare_regions for cross-state comparisons.' Names three concrete alternatives and the condition that selects each, 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 safety profile (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for what it adds: no parameters, no authentication required, and the specific payload fields (state code, full name, station count, ICMS bracket, audit timestamp). It stops short of stating pagination or response size/format, but there is little else that could go wrong on a zero-argument read.

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, purpose front-loaded ahead of the routing instruction, with no filler or restatement of the title. The field enumeration is dense but each item conveys distinct metadata an agent would otherwise have to discover by calling the 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?

With no output schema, the description carries the burden of describing the return payload, and it does so field-by-field. Combined with the zero-parameter schema and full annotation coverage, nothing needed to invoke or interpret this tool 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?

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics to document. The description correctly confirms 'requires no parameters,' which is consistent with 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 verb and resource ('Returns the complete list of all 27 Brazilian Federative Units') with an explicit count and scope ('covered by the server'). It is immediately distinguishable from the six sibling tools, which are all price/data lookups rather than enumerations of the UF dimension.

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 sequencing rule: 'Call this tool first to validate UF codes before invoking brazil_fuel_prices, brazil_grocery_basket, brazil_lpg_gas_prices, or brazil_compare_regions.' It names the concrete alternatives and the condition that selects this tool over them, so the agent needs no 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 safety profile (readOnly, idempotent, non-destructive), and the description adds the operational details that matter: weekly refresh cadence, no authentication required, and a concrete rate limit of 60 req/min. That is exactly the value-add 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?

Three dense sentences, all of which earn their place, with the core purpose front-loaded. It is slightly packed into a single run-on paragraph rather than cleanly separated concerns, but there is 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?

With no output schema, the description carries the burden of explaining what comes back; it conveys that results are audited ANP prices per state/city but never states the response shape (aggregate vs per-reseller, currency, units). Otherwise complete for a two-parameter read-only query.

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 both 'uf' and 'cidade' documented in the schema, so the baseline is 3. The description references UF codes and state coverage but adds no format, casing, or filtering semantics beyond what the schema already states.

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 ('Queries official audited prices of residential cooking gas (13kg LPG cylinder)'), names the authoritative source (ANP), and quantifies scope (13,145+ resellers, 27 states). This is unmistakably distinct from siblings like brazil_fuel_prices and brazil_grocery_basket.

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 to alternatives with the condition that selects each: brazil_list_states for valid UF codes and brazil_compare_regions for cross-state LPG comparison. Nothing about tool selection 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?

Annotations already declare readOnly, idempotent, non-destructive, and openWorld behavior. The description adds meaningful operational context beyond annotations: no authentication required, a 60 req/min limit, monthly CMED updates, and a cap of 15 matching presentations per call. It does not explain pagination or no-result behavior, so it is not fully 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 description is front-loaded with the core resource and scope, followed by operational limits. It is fairly dense in the first sentence but contains no obvious filler, and every sentence contributes useful 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 read-only lookup with fully documented parameters and rich annotations, the description covers the data source, update cadence, rate limit, return cap, and included fields. It leaves pagination and exact no-match behavior unspecified, but overall it is sufficiently complete for correct invocation.

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

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

Schema description coverage is 100%, with all three parameters documented, including defaults, examples, and an enum. The description adds domain context but no parameter-specific meaning beyond what the schema already 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 verb ('Queries') and resource ('official Maximum Consumer Prices (PMC) and Factory Prices (PF) for ... regulated medicines in Brazil from CMED/ANVISA'), plus scope and included fields. This clearly distinguishes it from sibling fuel, grocery, LPG, cost-of-living, and regional comparison tools by 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?

Usage is implied by the medicine-price domain, but the description does not explicitly say when to use this tool versus sibling tools or when not to use it. It lacks named alternatives or exclusion conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by confirming 'zero authentication required' — an auth fact annotations do not carry — and by disclosing the data sources and correlation behaviors (BCB SGS, thermal parity, CONFAZ tax anatomy). It does not mention rate limits or output shape.

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 purpose is front-loaded in the first sentence, followed by scope, data sources, and safety. It is dense with parenthetical acronyms (SEFAZ NFC-e / DIEESE, ANP, ANEEL) but each sentence contributes scope rather than repeating the title, so the length is largely earned.

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 burden of explaining returns. It lists what gets computed (labor hours, correlations) but not the shape or structure of the response — how per-state results are organized or what fields come back. Adequate but leaves the agent guessing about the return format for a fairly complex oracle.

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 only two parameters, so the schema already documents uf and salario_mensal_brl, including defaults. The description adds no syntax or format detail beyond that, though its mention of the 220h CLT workload and 50L/150 kWh constants gives useful computation context. Baseline 3 applies 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?

The description states a specific verb and resource — calculating real PPP and labor-hour requirements across the 27 Brazilian states — and enumerates the inputs it aggregates (grocery basket, LPG, fuel, electricity). The derived metric (working hours to afford survival goods) distinguishes it from raw-price siblings like brazil_fuel_prices, but it never names an alternative, so the agent must infer 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?

There is no explicit when-to-use or when-not-to-use guidance. Given ten siblings including brazil_cost_of_living, brazil_grocery_basket, and brazil_tax_anatomy that heavily overlap this tool's stated scope, the absence of routing guidance is a real gap. Usage is only implied by the aggregation framing.

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), and the description reinforces this while adding genuine context: zero authentication required and the specific outputs decomposed (ICMS, PIS/COFINS, net physical values). It stops short of describing response format or edge cases, but against existing annotations it adds real value.

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 action and scope, then the legal basis and decomposition targets. The dense citation strings are heavy but earn their place by grounding the computation's authority; 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 no output schema, the description carries the burden of explaining what comes back, and it does name the decomposed outputs (state ICMS, federal PIS/COFINS, net physical product values). Combined with annotations covering safety and 100% schema coverage for inputs, it is nearly complete; only return formatting/pagination is unaddressed.

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 both parameters (uf, categoria) and the enum values are already documented. The description maps the categories to real-world meaning (retail fuels, 13kg cooking gas, basic food basket, CMED pharmaceuticals), which adds modest interpretation beyond the enum labels, but no syntax or default behavior 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?

States a specific verb (decomposes/performs tax decomposition) and resource (state ICMS, federal PIS/COFINS, net product values) with explicit scope across all 27 UFs. The legal framing (CONFAZ, EC 132/2023) distinguishes it from siblings like brazil_fuel_prices, which report prices rather than tax anatomy.

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 explicit when-to-use guidance, prerequisites, or routing to alternatives. An agent must infer from the topical scope whether this or brazil_fuel_prices / brazil_grocery_basket is the right call; nothing states exclusions or preferred contexts.

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