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

With no annotations, the description carries the behavioral burden, and it clearly states the operation is a calculation. The verb 'Calcula' and the explicit rule indicate a pure, side-effect-free computation, though it does not describe the exact return shape or rounding 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 one compact sentence that front-loads the action and rule, then adds the output categories and input basis. Every phrase contributes meaning, and there is no filler or 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?

For a simple one-parameter calculator, the description covers the calculation rule, the input basis, and the three output categories, which is sufficient to invoke it correctly. It does not specify the exact output format or whether values are amounts or percentages, but the 50/30/20 rule implies the allocation.

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

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

Schema coverage is 100%, and the schema already documents the single parameter as 'Renda líquida mensal em R$' with a required flag and exclusiveMinimum. The description only reinforces the net-income input without adding new parameter-level detail.

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 verb and resource ('Calcula orçamento') and pins down the exact method ('regra 50/30/20') with the categories produced ('necessidades, desejos e investimentos'). This makes it clearly distinguishable from the many sibling calculator tools, even without an explicit 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?

The description gives clear context for when to use it: when the user wants a 50/30/20 budget allocation based on net income. It does not explicitly mention alternatives or exclusions, but the rule and the 'a partir da renda líquida' prerequisite make the intended use 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?

With no annotations, the description carries the burden of behavioral disclosure. It names a formula, but the formula as written does not actually incorporate monthly deposits, which is misleading. It also does not explain output format, rounding, handling of zero rates, or whether the result is total accumulated value or just interest.

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 and front-loaded with the core purpose. No filler words are present. However, the formula is incomplete/misleading, so the conciseness comes at some cost to accuracy.

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?

The tool has four parameters and no output schema, so the description should explain what the returned value represents and how monthly deposits affect the calculation. It does neither, and the formula given is insufficient to guide correct usage. Important context such as currency, rounding, and edge cases 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%, and the schema already documents each parameter, its type, defaults, and constraints. The description adds some value by mapping principal, rate, months, and deposits into a formula, but this mapping is somewhat inaccurate and does not go beyond what the schema already conveys.

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

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

The description clearly identifies the operation: calculating compound interest with monthly deposits, and includes the formula. However, it does not explicitly differentiate this tool from closely related siblings like calculate_investment_return or calculate_financing, so it is clear but not fully differentiated.

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 when to use the tool—when compound interest with monthly contributions is needed—but provides no explicit guidance about when not to use it or which sibling tool should be chosen instead. Given the large set of calculator siblings, this lack of routing guidance is a notable gap.

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

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

With no annotations, the description carries the behavioral disclosure burden. It transparently says the tool computes a payoff plan, implements two named strategies, and compares them, which is meaningful for a calculator. It does not disclose the exact output shape or assumptions such as fixed rates, so one point is withheld.

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 entire description is one focused sentence that front-loads the action and object before specifying the methods. There is no repetition of schema information and 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?

The description is adequate for selecting the tool because the input schema is fully documented. However, there is no output schema and the description does not state what the returned 'plano' contains, such as a payment schedule, totals, or payoff time, leaving the agent to discover the return shape.

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

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

Schema description coverage is 100%: debts and extra_payment are already documented, including the monthly_rate format and defaults. The description adds no parameter-level detail, which is acceptable because the schema carries the burden, yielding the baseline of 3.

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 ('Calcula plano de quitação de dívidas') and clearly names the two methods (avalanche and snowball) plus the comparison behavior. This distinguishes it from sibling financial calculators such as calculate_financing or calculate_installment.

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 establishes an unambiguous use case: debt payoff planning with a choice between highest-interest-first and smallest-balance-first strategies. It does not explicitly name alternative tools or exclusion conditions, so it stops short of a 5, but the context is clear enough for an agent to select it.

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 provided, the description carries the full burden of behavioral disclosure, but it only states the high-level inputs and outputs. It does not disclose the underlying assumptions (e.g., that each profile maps to a different expense multiplier), what happens when monthly_saving or current_savings are 0 (e.g., undefined time-to-build), or whether this is a pure deterministic calculation.

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 names both outputs before the inputs, with zero filler words. Every word earns its place, and the structure makes the tool's purpose immediately scannable.

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 and no annotations, yet the description does not cover the return format, the role of optional saving parameters, or the profile-specific assumptions. For a 4-parameter financial calculator, the absence of edge-case and assumption disclosure leaves meaningful gaps in what an agent needs to invoke and interpret the result correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description confirms that monthly_expenses and profile drive the ideal value, which slightly reinforces the enum's role, but it adds no real semantic detail beyond the schema—monthly_saving and current_savings are only implied through 'quanto tempo leva para montar.'

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 ('Calcula'), a specific resource ('reserva de emergência'), and the two concrete outputs (ideal value and time to build). The domain is distinct enough among the sibling calculators that an agent would not confuse it with most of them, though it doesn't explicitly differentiate from the adjacent calculate_financial_independence.

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 guidance is given on when to use this tool versus alternatives such as calculate_financial_independence or calculate_budget. There are no stated conditions, exclusions, or prerequisite inputs, so the agent must infer the usage context entirely from the tool name and domain.

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 disclosure burden. It reveals the 4% rule / custom withdrawal rate approach, but it does not state what the output contains, whether current_savings and monthly_investment are used to project time-to-independence, or what assumptions apply to the calculation.

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 that states the verb, the goal, and the calculation method with no redundant words. Every phrase earns its place.

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

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

With five parameters and no output schema, the one-sentence description leaves important invocation context unstated: what the returned value looks like, whether it also projects years to independence, and how optional savings/investment inputs interrelate. It is sufficient for tool selection but not for confident invocation and interpretation.

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 parameters are already well documented; the baseline is 3. The description adds minimal value by mentioning the custom withdrawal rate, but it does not clarify how current_savings and monthly_investment affect the result.

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 the specific verb 'Calcula' with a clear object: how much money must be accumulated to live on investment income. It also names the central methodology (4% rule or custom rate), which clearly separates it from sibling calculators like calculate_emergency_fund or calculate_investment_return.

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 guidance on when to use this tool versus alternatives such as calculate_emergency_fund, calculate_budget, or calculate_investment_return. The intended use is only implied by the phrase 'para viver de renda'; no explicit selection criteria, exclusions, or alternative routing are provided.

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 of behavioral disclosure. 'Calcula' conveys a pure calculation with no mutation, which is useful, but the description does not mention rounding, precision, whether the result is an amortization schedule or aggregate values, or any edge-case behavior. Some context is given, but richer behavioral detail is missing.

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 filler. Every clause earns its place by specifying the financing types and the key outputs.

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 relatively simple calculator with five straightforward parameters and no output schema, the description names the relevant outputs and domain. It could be more complete by describing the return format or the relationship between property value and down payment, but the essential information for invoking the tool correctly is 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 100%, with every parameter documented: months, amortization system, annual rate, down payment, and property value. The description adds no additional meaning beyond the schema, so it sits at the baseline for parameter semantics.

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 calculates real estate financing (financiamento imobiliário), explicitly supports the SAC and Price systems, and lists the outputs: installments, total interest, and total amount paid. This differentiates it from generic sibling calculators like calculate_installment or calculate_debt_payoff.

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 domain and system options imply when the tool should be used, but the description provides no explicit when-to-use guidance, no exclusions, and does not direct the agent toward or away from adjacent siblings such as calculate_installment or calculate_compound_interest. Usage context is present but only by implication.

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?

There are no annotations, so the description bears the full burden of disclosing behavior. It does reveal that the tool uses IPCA and reports purchasing-power impact, but it does not disclose the underlying formula, constant-rate assumption, or the fact that future projection is possible via the direction parameter. This leaves important behavioral ambiguity for a financial calculator.

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 compact and front-loaded: the first sentence names the core action and resource, the second clarifies the two possible outputs. Every word earns its place, and there is no redundant restatement of parameter names or schema details.

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?

The tool has four parameters, no output schema, and no annotations, yet the description only addresses the past-to-present scenario and the general output type. It omits the present_to_future direction, the calculation assumptions, and the return format, leaving gaps for an agent that needs to invoke the tool correctly in all supported modes.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, including defaults and units. The description adds minimal extra meaning beyond contextualizing the inflation index, so the baseline of 3 is appropriate; it neither conflicts with nor substantially enriches 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 the verb ('Corrige'), the resource ('um valor pela inflação (IPCA)'), and the expected output ('quanto um valor do passado equivale hoje, ou quanto o poder de compra diminuiu'). This distinguishes it from the many other calculation tools in the sibling list, such as compound interest or real salary.

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 the tool is for inflation-adjusted value comparisons but gives no explicit guidance on when to use it versus alternatives like calculate_real_salary or get_current_rates. No when-not-to-use cases or sibling references are provided, so an agent must infer suitability from the tool name alone.

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 behavioral burden. It does disclose that the calculation uses the Price system and produces fixed installments, which is useful. However, it does not mention the output format, zero-rate behavior, rounding, or whether it only returns the installment 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?

The description is a single, focused sentence that leads with the action and includes the key method detail. There is no redundant information or 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?

The tool is simple and the schema covers all parameters, but with no output schema and no usage guidance, the description leaves some ambiguity about the exact return value and when to select this tool over similar siblings. It is minimally viable but not 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 100%, so all three parameters are already well described in the schema. The description adds the broader method context but does not elaborate on parameter meaning or relationships beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states a specific action ('Calcula parcelas') on a specific resource ('financiamento/empréstimo') and adds the precise method ('sistema Price'). This differentiates it from broader siblings like calculate_financing by emphasizing fixed installments under the Price system.

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 gives no guidance about when to use this tool versus alternatives. With siblings like calculate_financing, calculate_compound_interest, and calculate_debt_payoff, an agent would not know which calculation context selects this tool.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the core behavior: simulating fixed-income yield, calculating regressive income tax, and comparing with savings. However, it does not clarify key assumptions such as whether returns are gross or net, whether contributions are made over time, or how the comparison is presented.

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 dense sentence that front-loads the main purpose and packs in useful specifics about tax and savings comparison. It is appropriately short, though it tries to cover several instruments in a compact list and includes the problematic LCA mention.

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?

This is a four-parameter simulation tool with no output schema and no annotations, so the description must do more. It does not describe the return value format, explain whether the calculated return is net of tax, or reconcile the missing LCA enum value. An agent would be guessing about important aspects of the call and result.

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

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

Schema coverage is 100%, so the baseline is 3. But the description explicitly lists 'LCA' as a supported instrument while the schema enum only allows cdb, lci, tesouro_selic, and poupanca. This can mislead an agent into sending an invalid type value, which is a meaningful semantic inconsistency beyond what the schema describes.

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: it simulates fixed-income returns in Brazil and names the covered instruments (CDB, LCI, Tesouro Selic, Poupança). It also distinguishes itself from generic siblings like calculate_compound_interest by mentioning Brazilian-specific tax treatment (IR regressivo) and comparison with savings.

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 when to use the tool: when modeling Brazilian fixed-income investments and comparing them to savings. However, it does not explicitly state when not to use it or name alternatives such as calculate_compound_interest or get_current_rates, so the guidance is left mostly 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?

With no annotations, the description carries full responsibility for behavioral disclosure. It states that the tool calculates a value and performs a check, but does not explain whether it uses current tax rates, how the revenue limit is annualized, or what the response contains. This leaves important assumptions and behaviors undisclosed for a financial calculation 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?

A single sentence that front-loads the primary action and then adds the secondary check. Every word earns its place, with no filler or 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?

There is no output schema and no annotations, so the description must explain return format and edge cases, but it does not. It fails to mention what the tool returns (e.g., an amount, a boolean for limit compliance), which revenue limit is used, or how activity affects the calculation. For a two-parameter tool this is incomplete.

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 input schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds minimal semantic value by linking monthly_revenue to the revenue-limit check, but it does not clarify how activity influences the DAS value beyond the enum's 'Tipo de atividade' label. No compensation is required given full schema coverage.

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 specifies a clear verb ('calcula') and resource ('DAS MEI mensal'), plus a secondary behavior (verifying revenue limit). It is easily distinguished from sibling calculators like calculate_net_salary or calculate_vacation_pay because MEI is a unique Brazilian tax regime. No ambiguity about what the tool does.

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 the use case: calculating the monthly MEI tax and checking revenue compliance. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or prerequisites. The context is clear but the guidance is left implicit.

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 exist, so the description must carry the full behavioral burden. It does disclose that the tool applies INSS and IRRF discounts and that the tables are updated for 2026, which is useful. It does not, however, disclose limitations (e.g., other deductions excluded) or the exact shape of the result, leaving some behavioral ambiguity.

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 two short sentences with no filler; the main action is front-loaded, and the '2026 tables' note is a valuable differentiator. Every word contributes to understanding or trust in the calculation.

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 straightforward 2-parameter calculator with complete schema documentation, the description covers the essential purpose and behavior. Since there is no output schema, mentioning the return format (e.g., a single net value or a breakdown) would have made it fully complete, but the description already implies the result is the net salary.

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 parameters already documented clearly in the input schema. The description only adds context by naming the deduction types, which reinforces the role of the parameters but does not add new syntactic or formatting detail beyond the schema baseline.

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

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

The description uses a specific verb ('Calcula') and a clear resource ('salário líquido CLT no Brasil') while naming the two deduction types (INSS and IRRF). This makes the tool's function unmistakable and distinguishes it from siblings like calculate_severance or calculate_real_salary without needing the schema.

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

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

The description gives no explicit when-to-use guidance, exclusions, or mentions of alternatives. However, the tool name and CLT-specific phrasing imply the intended use case, so an agent can infer when to call it, but it would not know why to choose it over, for example, compare_clt_vs_pj or get_inss_table.

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?

Sem anotações, a descrição carrega o peso de explicar o comportamento. Ela informa que a ferramenta converte um gasto recorrente em valor futuro investido, com exemplo, mas não detalha premissas como frequência de capitalização, se considera aportes mensais ou diários, ou a fórmula usada. Para uma calculadora sem efeitos colaterais, isso é adequado, mas não vai além do básico.

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?

Duas frases curtas e sem ruído: definição clara seguida de exemplo ilustrativo. A informação principal vem primeiro e o exemplo ocupa a segunda frase.

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?

Ferramenta simples, com 3 parâmetros totalmente documentados no schema e sem output schema. A descrição, junto ao schema, dá ao agente o suficiente para invocar: explica propósito, entradas e exemplo. A única lacuna é a não distinção entre ferramentas irmãs, mas isso já é tratado na dimensão de uso.

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?

A cobertura do schema é 100%, então o baseline é 3. A descrição adiciona um exemplo que mapeia daily_expense (R$10/dia) e years (10 anos), mas não agrega significado novo sobre annual_return ou formatos. O schema já documenta todos os parâmetros com descrições.

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?

A descrição usa verbo específico 'Calcula' + recurso claro ('gasto recorrente') e resultado ('quanto viraria se investido'), com exemplo concreto (café de R$10/dia → 10 anos). Isso diferencia o propósito de ferramentas irmãs como calculate_compound_interest, pois foca no custo de oportunidade de um gasto recorrente, não em um principal único.

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?

A descrição define o que a ferramenta faz e dá um caso de uso no exemplo, mas não explicita quando usá-la em vez de alternativas como calculate_compound_interest ou calculate_investment_return, nem fornece exclusões. O contexto de uso é implícito, não declarado.

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 behavioral disclosure burden. It does communicate the core calculation behavior: overtime is valued at 50% for weekdays and 100% for Sundays/holidays. However, it does not mention the underlying formula (e.g., salary divided by monthly_hours), possible rounding behavior, or what happens when both extra-hours inputs are zero.

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 efficient sentence that front-loads the core purpose and then adds the key rate distinction. Every phrase carries meaningful information and there is no filler or 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?

For a simple calculator tool with 100% schema coverage, the description covers the essential computation context. There is no output schema, so return-value format is not documented anywhere, and the description does not clarify whether the result is a single total or an itemized breakdown. Overall it is adequate but leaves minor gaps around output and 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?

The input schema provides full documentation for all four parameters, including defaults and descriptions, so the description does not need to restate them. The description's mention of 50% and 100% maps naturally to extra_hours_50 and extra_hours_100. There is no additional semantic value over 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?

The description names a specific verb and resource: 'Calcula valor de horas extras CLT' — calculating overtime value under Brazilian CLT rules. It also distinguishes the domain by mentioning the 50% and 100% multipliers for weekdays vs Sundays/holidays. However, it does not explicitly differentiate itself from siblings like calculate_severance or calculate_vacation_pay, 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 CLT reference clearly implies the intended use case: Brazilian labor-law overtime calculations. No alternative tools are named, and there is no guidance on when not to use this tool or which sibling would be more appropriate for related calculations. This is implied usage rather than explicit 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that the tool computes a comparison and indicates the financial outcome, which conveys a read-only, non-destructive calculation. However, it does not describe the return format (e.g., a number, a message, a report) or any assumptions/limitations beyond the schema.

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

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

The description is two short sentences with no unnecessary words. The primary action is front-loaded ('Calcula o salário real...'), and the second sentence adds value by explaining the output's meaning. Every sentence earns its place.

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

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

For a simple calculator with three clearly schematized parameters and no output schema, the description is nearly sufficient. It explains the purpose and the decision-oriented output. It could go slightly further by noting that the result is a comparison or by clarifying how inflation is measured, but these are minor gaps.

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?

All three parameters have schema descriptions covering 100% of the input properties, so the baseline of 3 applies. The description does not add parameter-level detail beyond what the schema already provides, such as the fact that inflation_period is a percentage.

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 ('Calcula') with a clear resource ('salário real') and states the exact analytical goal: discounting inflation and showing whether the raise followed IPCA or lost purchasing power. This clearly distinguishes it from sibling calculators like calculate_net_salary or calculate_inflation_adjustment by focusing on real salary 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?

The description implies the need for previous salary, current salary, and inflation data, but does not explicitly state when to use this tool versus alternatives such as calculate_inflation_adjustment or calculate_net_salary. There are no exclusions or conditional routing instructions, so usage context is only implicit.

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 of disclosing behavior. It does list the included components, but it overgeneralizes by stating 'multa FGTS' is included without qualifying that it applies differently by termination type — resignation typically has no FGTS penalty, and agreement has a different rate. It also omits type-specific calculation differences and does not clarify whether values are gross or net.

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 captures the tool's purpose, supported termination types, and included components with no filler. Every part of the description 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?

This is a legally and financially complex calculation with multiple parameters, no annotations, and no output schema. The description does not state what the tool returns, how fgts_balance and days_worked_in_month are used, how the three termination types alter the calculation, or whether the result is a breakdown or a total. Too much is left to inference for an agent to call it confidently.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only high-level conceptual connections (e.g., 'saldo de salário' relates to days worked, '13º' relates to months worked), but it does not explain parameter roles or formatting beyond what the schema already documents.

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 verb ('calcula'), a concrete resource ('rescisão trabalhista CLT'), and enumerates the supported termination types ('demissão sem justa causa, pedido de demissão ou acordo'). It also lists the components included, making the tool's purpose unmistakable and clearly distinct from sibling calculators that handle only one component.

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 context is implied by the description: it is for full CLT severance calculations across three dismissal types. However, it does not explicitly say when to prefer this over siblings like calculate_vacation_pay or calculate_thirteenth_salary, nor does it provide exclusions or alternative routing.

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

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

There are no annotations, so the description carries the full behavioral burden. It does disclose that the tool calculates both the first installment and the second installment with INSS and IRRF deductions, which is useful. But it omits important behavioral details such as which tax tables are applied, rounding behavior, and what exactly is returned.

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 filler. Every phrase—'1ª parcela', '2ª parcela', 'descontos de INSS e IRRF'—adds meaningful information without 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?

Without an output schema or annotations, the description gives a useful but minimal overview. It implies the two installment values are returned and that taxes are deducted, but it does not state assumptions about tax year, rounding, or how dependents affect the IRRF calculation.

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 schema already describes all three parameters with 100% coverage, so the baseline is 3. The description does not add parameter-specific meaning; it only references the overall salary calculation, while months_worked and dependents remain explained solely by 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 uses the specific verb 'calcula' and names the exact resource ('décimo terceiro salário'), including the two installment types. This clearly distinguishes it from sibling tools like calculate_vacation_pay or calculate_severance, and leaves little ambiguity about what the tool does.

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 use case is implied clearly: it is for Brazilian 13th salary calculations. However, there is no explicit guidance about when to use this tool versus alternatives, nor any exclusionary statements such as 'use calculate_net_salary for regular monthly salary.'

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 provided, the description carries the burden of disclosing behavior. It goes beyond a simple 'calculates vacation pay' by revealing the formula components and the INSS discount applied. It doesn't specify output format or rounding, but for a pure calculation tool the key behavioral facts are present.

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 sentence that front-loads the purpose and packs in the key calculation details with zero filler. Every term earns its place: the legal scope, the three components, and the INSS discount.

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

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

For a simple calculator with no output schema and no annotations, this description covers the calculation scope well. The main gap is that it doesn't explicitly state the return structure (e.g., whether the output is a breakdown or a single net amount), but the formula disclosure is sufficient for an agent to know what the tool does and which parameters matter.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds some context by linking 'abono pecuniário' to the sell_days parameter and '1/3 constitucional' to the calculation logic, but it doesn't provide syntax, defaults, or format details beyond what the schema already states. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Calcula férias CLT', immediately identifying the domain (Brazilian CLT vacation pay). It enumerates the exact components: vacation value, constitutional 1/3, abono pecuniário, and INSS discount, which clearly distinguishes it from sibling tools like calculate_thirteenth_salary or calculate_severance.

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 provides clear context for when to use the tool: whenever a CLT vacation payment calculation is needed. It doesn't explicitly name alternatives or exclusion conditions, but the strong domain-specific phrasing makes the intended use unambiguous among the 25 siblings.

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 burden of explaining behavior. It does disclose the comparison and the included factors (benefits/costs) and the tax regime (Simples Nacional), but it does not state assumptions such as which benefit values are used or the shape of the result. No contradictions with annotations exist because none are provided.

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 compact sentences deliver the core scope first and the inclusion criteria second, with no filler. It is easy to parse and front-loaded.

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?

The tool is a simple 3-parameter calculator and the schema documents all parameters, but there is no output schema and no annotations, so the description should clarify what the returned comparison contains and key assumptions. The current text is adequate for selection but leaves interpretation of the result partly to inference.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces the role of gross_value ('mesmo valor bruto') and hints that tax rate and accountant cost represent PJ costs, but it adds no syntax or calculation detail 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 opens with the specific verb 'Compara' and names the exact resource: net income under CLT vs PJ (Simples Nacional) for the same gross value. This scope clearly separates it from sibling single-route calculators like calculate_net_salary or calculate_mei_tax.

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 intended use is clear: choose this tool when the request is a same-gross comparison of CLT and PJ, and the mention of including CLT benefits and PJ costs sets expectations for the comparison scope. It does not explicitly name alternatives or when-not conditions, so it misses a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It adds useful context by naming the data sources (CAGED + Glassdoor) and year (2026), and it discloses the return values (minimum, median, maximum). However, it omits response format, error behavior for unknown professions, and whether the data is fetched live, leaving transparency 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?

Two short sentences front-load the core function and return metrics, then add data-source context in the second sentence. There is no redundant wording; every phrase 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?

For a one-parameter lookup with no output schema, the description covers the essential return values (minimum, median, maximum) and data provenance. It is nearly complete, though it does not state limitations such as profession coverage breadth or whether the data is refreshed periodically.

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 input schema fully documents the single required parameter 'profession' with a description and examples, so schema coverage is 100%. The tool description adds no additional parameter guidance such as case sensitivity or accepted name formats, keeping it at the baseline score for fully covered schemas.

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 ('Retorna') and resource ('salário médio de uma profissão no Brasil') and lists the exact return metrics (mínimo, mediana, máximo). It clearly distinguishes this lookup tool from sibling calculators like calculate_net_salary or calculate_thirteenth_salary by stating it returns data rather than computes a value.

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: call this tool when you need average salary statistics for a Brazilian profession. However, it does not explicitly state when to prefer it over alternatives such as get_cost_of_living or calculate_net_salary, nor does it mention exclusions or prerequisites.

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 of behavior disclosure. It does add useful context by stating the estimate nature, the categories covered, and the data source (IBGE POF + 2026 estimates). However, it does not disclose what happens for unknown/unrecognized cities, whether values are returned as a breakdown or total, or any other operational 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 a single compact sentence that front-loads the main purpose, lists representative categories, and adds the data source. Every part contributes useful information, with no filler or 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?

For a simple one-parameter lookup with no output schema, the description covers the core behavior, the input scope, and the nature of the returned data. It could be slightly more complete by clarifying the expected response shape or behavior for invalid city names, but it is largely sufficient for an agent to call it correctly.

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

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

The single 'city' parameter is fully documented in the schema with an example, so schema description coverage is 100%. The tool description reinforces that the city must be Brazilian but does not add significant meaning beyond what the schema already provides, so the baseline score 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?

The description uses a specific verb ('Retorna') and names the resource: estimated cost of living in a Brazilian city, including concrete categories like rent, food, transport, and health. This clearly distinguishes it from the sibling calculators and table-lookup tools, which target different calculations or 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?

The description makes the intended context clear: use this tool when the agent needs an estimated cost of living for a Brazilian city. It does not explicitly name alternatives or state when not to use it, but the purpose is specific enough that confusion with sibling tools is unlikely.

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 of behavioral disclosure. It establishes this as a read-only data fetch and lists the exact data points, which is the core of the behavior. However, it does not disclose the return format/keys, units (e.g., annualized percentages, exchange-rate basis), freshness of the data, or data source — details an agent would want before relying on the output.

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 sentence that front-loads the main claim ('Retorna taxas econômicas atuais do Brasil') and then packs the list of specific rates into the remainder. Every item in the enumeration earns its place by telling the agent exactly what data is available; there is zero 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?

For a zero-parameter, no-output-schema fetch tool, the description is nearly sufficient: it names every data point returned and implies a read operation. The only gap is the absence of return-format/unit details, which would have helped since no output schema exists to carry that information. Overall selection and invocation (trivial with 0 params) are well supported.

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 has zero parameters, so per the rubric the baseline is 4 — there is nothing for the description to explain. Schema description coverage is trivially 100% on an empty schema, so no compensation is needed. The description's enumeration effectively tells the agent what payload to expect instead.

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 has a specific verb ('Retorna'), a clear resource (current Brazilian economic rates), and precisely enumerates the data points returned (Selic, CDI, IPCA, IGP-M, poupança, dólar, euro, salário mínimo). This enumeration inherently distinguishes it from the sibling calculators (calculate_net_salary, calculate_severance) and from get_inss_table / get_irpf_table, whose scopes are different tables.

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 context is only implied: an agent would use this when it needs current Brazilian rate values. There is no explicit when-to-use, when-not-to-use, or routing to an alternative (e.g., 'use calculate_inflation_adjustment when calculating over time rather than fetching current rates'). Given the large field of calculate_* siblings, an explicit contrast would materially help.

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?

Não há anotações, então a descrição carrega todo o peso. Ela informa o conteúdo retornado (preço, funcionalidades, como começar) e implica uma operação de leitura, mas não declara explicitamente que não modifica dados, nem menciona limitações, atualização das informações ou formato da resposta.

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 descrição é uma única frase compacta que coloca o assunto em primeiro lugar e já lista os três conteúdos principais. Cada palavra contribui; não há redundância ou informação irrelevante.

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?

Para uma ferramenta informativa, sem parâmetros e sem anotações, a descrição é suficiente para o agente decidir quando chamá-la e o que esperar. Uma lista mais detalhada da estrutura da resposta poderia melhorar a completude, mas os tópicos citados cobrem os usos principais.

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?

A ferramenta não possui parâmetros e a cobertura do schema é de 100%, portanto não há nada que a descrição precise adicionar sobre parâmetros. Como ferramenta sem parâmetros, a linha de base 4 é apropriada e a descrição não cria expectativas incorretas.

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?

A descrição identifica claramente o recurso-alvo (o assistente Fala Zuki) e o tipo de informação fornecida (preço, funcionalidades, como começar), distinguindo-o dos irmãos calculadores. Porém, usa a frase nominal 'Informações sobre' em vez de um verbo de ação explícito como 'obter' ou 'retornar'.

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?

Não há orientação explícita sobre quando usar esta ferramenta em vez das alternativas. No entanto, com zero parâmetros e um tema único entre os irmãos, o uso pretendido é implícito: qualquer pedido de informação sobre o Fala, Zuki!. Não há menção a exclusions ou casos em que outra ferramenta seria mais apropriada.

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 accurately discloses the core behavior as a read-only retrieval of a contribution table, but does not mention data currency, source, update behavior, or output format. This is adequate for a simple no-arg getter but not rich.

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 filler. Every word adds relevant meaning—tool subject, year, and content type.

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

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

For a zero-parameter tool with low complexity, the description is mostly complete: it states what is returned and the key contents. However, because there is no output schema, it does not specify the exact structure of the table, which leaves minor 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?

The tool has zero parameters and the schema description coverage is 100%, so there is no parameter information for the description to add. Baseline for zero parameters is 4.

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 ('Retorna') and resource ('tabela de contribuição INSS 2026'), and adds informative details about contents ('faixas e alíquotas progressivas'). This clearly distinguishes it from sibling tools like get_irpf_table and get_current_rates.

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 guidance about when to prefer this tool over alternatives such as get_current_rates or get_irpf_table. The usage context is only implied by the name and description, with no explicit exclusions or sibling comparisons.

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 indicates a read operation ('Retorna') and adds the specific year 2026, which is a useful behavioral constraint. However, it does not disclose the format of the returned table, whether it is static or computed, or any limitations.

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, efficient sentence that front-loads the action and resource, then lists the included components. There is no repetition of the tool name and no extraneous text.

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

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

With no parameters and no output schema, the description gives a reasonable summary of the return value ('faixas, alíquotas e parcelas de dedução') and specifies the year. It does not describe the exact structure of the table, but for a simple retrieval tool, the essential context is 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?

The tool has zero parameters, so the schema already covers all inputs trivially with 100% coverage. Per the baseline for 0-parameter tools, the description need not add parameter information, and it does not attempt to.

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 ('Retorna') and resource ('tabela do Imposto de Renda Pessoa Física 2026'), and it lists the expected content (faixas, alíquotas, parcelas de dedução). This is clearly distinguishable from sibling tools like get_inss_table or get_current_rates because it is explicitly the IRPF table for a specific year.

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 gives no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. While the name implies it is for retrieving IRPF tables, the description itself offers no contextual 'when to use' or 'use instead' cues among the many sibling calculators.

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 must carry the burden of disclosing behavior. It says 'finds' which implies a read-only search, but it does not describe the return format, whether multiple results are possible, or whether this tool only recommends a calculator versus calculating something. This is a meaningful gap.

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 focused sentence that front-loads the core action and object. There is no filler or redundant information, making it efficient for an agent to parse.

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?

The tool is simple, but with no output schema and no annotations, the description should clarify what the agent receives after calling it. It does not explain whether the output is a calculator name, a link, a list, or a confidence-ranked result. It also lacks routing guidance relative to the many sibling calculator 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?

The schema already fully documents the only parameter 'topic' with examples and a clear description. The description merely restates that the topic is a 'tema' and adds no additional semantic value. With 100% schema coverage, 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?

The description clearly states the tool finds the most relevant financial calculator on Falazuki for a given topic. It uses a specific verb ('Encontra') and resource ('calculadora financeira'), and it is naturally distinct from the sibling calculator tools. It could be stronger by explicitly naming what kind of result it returns.

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 purpose implies usage: when you have a topic and need to locate the right calculator, use this tool. However, it provides no explicit guidance about when to avoid it or when to call a specific sibling calculator directly. The context is implied, not stated.

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