Lauda - IA jurídica

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds real domain context beyond that — the calculation is deterministic ('feita por código'), carries legal grounding and premises, and separates the two procedural rites. It says nothing about the shape of the returned calculation (no output schema exists), which leaves 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?

Two tight sentences with no filler, and the differentiating prison/penhora split is front-loaded. It is efficient, though the closing clause about legal grounding and premises is abstract rather than operational.

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

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

For a 10-required-parameter computation with no output schema, the description should explain at least the period/payment inputs and what the result contains (the two-rite breakdown). It hints at the result structure but leaves the agent unable to populate most required fields 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 only 10% (just filingDate), so the description must carry the burden for 10 required parameters — and it does not. 'Correção e juros' loosely gestures at correctionIndex and interest, and 'três últimas parcelas' at the period bounds, but monthlyAmount, minimumWagePercent, dueDay, payments and referenceDate are entirely unaddressed.

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 the resource (alimony debt / débito de pensão alimentícia) and its defining feature: the split between the imprisonment rite (last three installments) and the attachment (penhora) rite, with correction and interest. That detail implicitly separates it from siblings like alimony_value_calculate and debt_calculate, though no sibling is named explicitly and the verb 'calculate' only appears in the tool name.

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 never says when to pick this over alimony_value_calculate or the generic debt_calculate, nor what preconditions exist (e.g. whether the execution must already be filed). The agent must infer routing from the prison/penhora split 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?

Annotations already declare a read-only, idempotent, closed-world calculation, so the safety profile is covered. The sentence 'a conta é feita por código, com fundamento e premissas' adds some behavioral context (the result carries a legal basis and stated premises), but it doesn't say what the return looks like or that mode drives which inputs matter. With annotations carrying the main burden, this is an adequate 3.

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-loaded with what is calculated and then the calculation basis. No filler, though the second sentence is vague enough that it earns only partial credit.

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 5-parameter, all-required calculator with no output schema and zero schema descriptions, the description should explain the mode switch and the income/percent interaction. Instead it leaves the agent to guess which parameters apply in which mode, making miscalls likely.

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

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

Schema description coverage is 0% across 5 required parameters, including an enum for mode, a percent, an income that appears nullable, and two YYYY-MM month fields. The description says nothing about any of these - not that mode selects between minimum_wage and income, not that income is irrelevant in minimum_wage mode, not the meaning of firstMonth/lastMonth. The description fails to compensate for the coverage gap.

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 the resource (alimony value) and the two bases (minimum wages or percentage of income), which is clear enough. However, it does not explicitly separate itself from the sibling alimony_debt_calculate, so an agent must infer that this computes the ongoing obligation rather than arrears.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as alimony_debt_calculate for overdue amounts. The agent is left to infer the call context from the 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds that the computation is code-based and returns with legal foundation and premises ('com fundamento e premissas'), which hints at output content beyond a raw number, but it omits return structure and how regime choices affect the result.

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, front-loaded with the core action and scope, no filler. Slightly terse given the complexity it must support.

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?

Five required parameters, an unlabeled enum, nested arrays, no schema descriptions and no output schema. The description leaves the agent unable to map regime values or understand the returned structure, which is a significant gap for a domain-specific legal calculation tool.

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

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

Schema description coverage is 0%, so the description carries the burden and fails to compensate. It only gestures at 'regime' without explaining the four enum values (partial, universal, separation, final_participation) or the owner enum (common/a/b) on assets and debts.

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 action (division of assets) conditioned on the property regime and that each party's share is computed. This is clearly distinguishable from sibling calculation tools like alimony_value_calculate or debt_calculate, though it doesn't explicitly name alternatives.

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

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

No guidance on when to use this vs the many sibling calculators, no prerequisites, and no exclusions. The mention of 'conforme o regime de bens' implies the regime choice matters but never explains which situations call for 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world — so the safety profile is fully covered. The description adds that the result is computed 'por código' (i.e., against codified CPC brackets) and that it carries 'fundamento e premissas' (legal basis and stated premises), which is genuine added context about the nature of the output, but it does not describe rounding, ranges of the fee brackets, 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?

Two short sentences, front-loaded with the object of calculation, no filler or repetition. Slightly terse to the point of obscurity in 'por código', which costs it the top mark.

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 three required parameters, no output schema, and low schema coverage, the description should do more: it omits how base and party interact, which CPC bracket applies to public_treasury versus labor, and what the 'premissas' actually contain. What it does say (CPC percentages, code-driven, returns basis and premises) is directionally complete for a read-only calculator, but leaves meaningful gaps for correct invocation.

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

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

Schema description coverage is only 33%: fewer than half the parameters are documented, and the description mentions no parameter at all. It never explains what 'base' is (condemnation amount? post-liquidation value?), what the 'party' enum values private/public_treasury/labor imply for the applicable CPC bracket, or why 'date' is mandatory only against the Fazenda — the very thing that decides which regime 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 legal computation: 'Honorários advocatícios de sucumbência pelos percentuais do CPC' — verb (calculate), resource (loser-pays attorney fees), and governing standard (CPC percentage brackets). It is clearly distinguishable from siblings like claim_value_calculate or alimony_value_calculate, though it never names an alternative explicitly.

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

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

There is no explicit when-to-use/when-not guidance and no reference to any sibling calculator, despite a large family of overlapping 'calculate' tools. The only usage signal is implicit domain framing ('sucumbência', 'CPC percentages'), which an agent must infer.

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=false, so the safety profile is covered. The description adds that results come 'with fundamento e premissas' (grounds and premises), hinting at a legally-sourced output, but provides no detail on precision, rounding, or what the response contains.

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 two-sentence format is front-loaded and waste-free, but the brevity borders on under-specification given the tool's 8 required parameters and legal domain complexity.

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 8 required parameters, 25% schema coverage and no output schema, the description needed to carry significant explanatory weight about inputs and result shape. Instead it remains at a marketing-level summary, leaving an agent unable to confidently populate fields like referenceDate or citationDate.

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 only 25%: just startDate (DIB) and endDate (DIP) are documented in the schema. The description explains none of the 8 parameters, leaving monthlyBenefit, benefitType, payments, filingDate, citationDate and referenceDate entirely undefined in both schema and prose.

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 legal-financial resource (INSS benefit arrears, month by month, with correction and interest) and states the computation is code-based. The implicit verb 'calculate' plus the resource makes it distinguishable from siblings like initial_benefit_calculate and retirement_rules_calculate, though it doesn't explicitly contrast with them.

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

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

There is no indication of when to choose this tool over neighbors such as initial_benefit_calculate, dosimetry_calculate, or undue_charges_calculate, and no prerequisites or exclusions are given. The agent must infer usage from the title 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value is in disclosing the backing service (Correios via ViaCEP) and the fallback resolution rule: if the street has no CEP of its own, the general district/locality CEP is returned. That fallback is behavior an agent cannot infer from annotations or schema. Minor gap: no mention of failure modes or what happens with partial/ambiguous address input.

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?

Four sentences with no filler, and the source and the two modes are front-loaded ahead of the fallback rule and the privacy warning. Slightly dense in the third sentence, but every clause carries information an agent needs.

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 takes on the burden of explaining returns and does so ('o CEP do logradouro ou, se a rua não tiver CEP próprio, o CEP geral do distrito ou da localidade'). The address-mode return value is only implied ('obter o endereço'), and error/empty-result behavior is unaddressed, which keeps it short of a 5 for a six-parameter open-world lookup.

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 83%, so the baseline is 3 and the schema already documents cep, city, number, street, and neighborhood. The description nonetheless adds the crucial semantic the schema does not express: the parameters form two mutually exclusive modes rather than one combined query (notable because the schema marks all six as required, which would otherwise mislead an agent into always sending everything).

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 ('Consulta a base de CEPs dos Correios') and immediately clarifies that the tool is bidirectional: CEP in → address out, or address fields in → CEP out. That bidirectional framing separates it cleanly from the only nearby sibling, cnpj_lookup, without the agent needing to open either schema.

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

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

Explicitly names both invocation modes ('Informe cep para obter o endereço, ou uf, city, street, neighborhood e number para obter o CEP'), so an agent knows which parameter set to populate for each goal. It also adds a hard exclusion — 'Nunca envie nome, CPF ou outro dado da pessoa' — which is exactly the when-not guidance that prevents misuse.

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 the tool as readOnly, idempotent and non-destructive, so the safety profile is clear. The description adds some context by noting the calculation is code-based and includes legal basis and premises, but it does not explain the return format 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?

Two tightly written sentences, front-loaded with the core purpose and output. No wasted words, though the second sentence about code, basis and premises could be more informative.

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 calculation tool with five required parameters, a ten-option enum and no output schema, the description is incomplete. It states the output in broad terms but leaves critical parameter semantics and usage conditions unexplained.

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 only 20%, and the description does little to compensate. It mentions interruptions and suspensions but does not explain the 'kind' enum values, the role of 'referenceDate', or the expected format for the date fields.

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: calculates civil prescription, the applicable deadline and the date the claim prescribes, including interruptions and suspensions. It distinguishes itself from criminal prescription by the word 'civil', though it does not explicitly name the sibling tool.

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 instruction on when to use this tool versus alternatives such as prazo_calculate or criminal_prescription_calculate. Usage is only implied from the tool name and the mention that interruption and suspension causes should be informed.

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 closed-world behavior. The description adds that the calculation is done by code and returns legal basis and assumptions, which is useful behavioral context, but it does not disclose output format, input limits, or error 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?

Two sentences, front-loaded with the purpose and legal basis, followed by a brief behavioral note. No wasted words; 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 tool with a complex nested array and legal calculation, the description gives the legal foundation and notes that the calculation is code-based with assumptions, but it omits details on how to structure requests, what combination values mean, and what the output contains. Annotations cover safety, but the domain complexity still leaves 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?

Schema description coverage is only 33% (only declaredValue is described). The description names some request categories and combination types, but does not explain the fields within each request (amount, monthlyAmount, overdueTotal, dueInstallments) or the meaning of the combination enum values. It does not compensate for the low 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 states a specific verb ('calcular'), resource ('valor da causa'), legal basis ('art. 292 do CPC') and input source ('a partir dos pedidos'). It distinguishes this general claim-value aggregator from the more specific sibling calculators, but does not explicitly name an alternative tool.

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 phrase 'a partir dos pedidos' and the legal context, but there is no explicit when-to-use guidance, no exclusions, and no named alternatives among the many sibling calculation tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered by structured data. The description adds genuine context beyond that: the data source is the public Receita Federal base and the output is already qualified for use in a legal document. It does not say what happens with an invalid/not-found CNPJ, latency, or rate limits.

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

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

Two compact sentences that front-load the returned fields and then state the input requirement. Nothing is redundant, though 'com a qualificação pronta para a peça' is slightly vague about what the output actually contains.

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 read-only, single-parameter lookup with no output schema, the description does the important work: it lists the data returned, which substitutes for a missing output schema, and names the authoritative source. The remaining gap is CNPJ input formatting and not-found 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?

One parameter with 0% schema description coverage, so the description must compensate: 'Leva só o número do CNPJ' does establish that only the CNPJ number is needed, no extra filters. However, it never specifies the accepted format (14 raw digits vs. the 18-character masked form implied by minLength 14 / maxLength 18), which is the single most useful detail an agent needs here.

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: fetches company registration data from Receita Federal's public CNPJ database, and enumerates the returned fields (razão social, situação, endereço, atividade, sócios). It is clearly distinguishable from siblings like cep_lookup or oab_processes_lookup, though it never explicitly contrasts itself with them.

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

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

Usage is only implied — an agent infers it should call this when it needs company registration data for a legal filing, reinforced by 'pronta para a peça'. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., cep_lookup for address-only needs).

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 establish that the tool is read-only, idempotent, closed-world, and non-destructive. The description adds that the calculation is code-based and returns legal basis/premises, but it does not explain assumptions, limitations, output shape, or parameter dependencies beyond that.

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 sentences, front-loaded with the core purpose and method, and contains no unnecessary repetition. It is appropriately sized for a concise tool description.

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

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

This is a complex calculation tool with eight required parameters, low schema description coverage, and no output schema. The description does not explain how the parameters interact, what inputs are expected for key dates and arrays, or what the resulting legal basis and premises will contain, leaving too much for the agent to infer.

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 only 38%, so the description should compensate. It mentions the official average rate and overcharged discounts, which loosely map to referenceRate and discounts/refund, but it gives no meaning for most required parameters such as contractDate, referenceDate, citationDate, withdrawals, or informedMonthlyRate.

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: recalculating consigned credit card debts (RMC/RCC) as consigned loans using the Brazilian Central Bank official average rate, including overcharged amounts. It is clear what the tool does, but it does not explicitly differentiate itself from nearby siblings such as loan_review_calculate or undue_charges_calculate.

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—recalculating RMC/RCC charges via the Central Bank average rate—but gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. With many calculation siblings, this is a meaningful gap, though the implied context is adequate for a minimum-viable score.

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?

The description is excellent for behavioral transparency because it specifies that it runs two different core logic paths: one using the 'pena máxima em abstrato' and another using the 'pena aplicada.' This is crucial behavioral context that goes beyond the listed parameters and 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?

The definition is highly concise and efficient. Both sentences are front-loaded with core logic (methods of calculation and included components) without unnecessary 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?

While it explains the method of calculation, it lacks practical context such as jurisdictional scope, specific legal criteria used for 'interruptive milestones,' or constraints on the input values (e.g., maximum days for a specific jurisdiction). It is sufficient to define the operation but insufficient for expert-level implementation.

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

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

With schema description coverage at 0%, the description provides no semantics or hints regarding the meaning of any specific input fields. Given the 10 required parameters and complex nesting, the description fails to add any meaningful value beyond the title and general purpose.

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 tool's function as calculating criminal prescription. It distinguishes between two calculation methods (maximum abstract penalty vs. applied penalty) and highlights the inclusion of interruptive milestones, providing high specificity.

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 tool description does not explicitly state when this tool should be preferred over other similar calculation tools in the sibling list. However, it defines the specific types of calculations it handles, which provides some contextual guidance.

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

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

The description goes beyond the readOnly/idempotent annotations by disclosing the return payload (per-installment memória de cálculo, totals, premises) and a conditional warning in 'notice' when due dates are missing after the last installment. It also states that partial and late payments are handled, which affects the calculation behavior. No error or rate-limit behavior is described, but the safety profile is already fully covered by 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?

Four dense sentences, front-loaded with the core action and regime scope, followed by accepted input cases and the return shape. The legal citations are heavy but functional; nothing is gratuitous padding.

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 14 required parameters, seven enums and no output schema, the description compensates by describing the output (memória de cálculo, totals, premises, notice), which is otherwise unavailable to the agent. Combined with 93% schema coverage, an agent has what it needs to construct a call, though the routing against overlapping siblings remains 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 description coverage is 93%, so nearly every parameter already carries its own enum/meaning documentation, and the description adds little parameter-level detail beyond the regime list. The baseline of 3 applies: the schema, not the description, does the semantic work.

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 ('Atualiza um débito parcela por parcela') and enumerates the legal regimes it handles (contract, art. 406 CC, labor/TST, Fazenda Pública, art. 523 CPC), so an agent knows exactly what calculation it performs. It does not, however, name or distinguish itself from close siblings such as sentence_execution_calculate or labor_calculate, which overlap with the regimes it lists.

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?

'Aceita pagamentos parciais ou em atraso' plus the regime list gives clear context for when the tool applies, and the per-regime framing signals which inputs select which branches. There are no explicit exclusions or pointers to alternatives, so the agent must infer routing against siblings like sentence_execution_calculate.

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/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real value by saying the computation is performed 'por código, com fundamento e premissas', hinting the result includes the legal basis and premises — but it says nothing about how repeatOffender or baseMethod affect the outcome, or what the returned figures look like.

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 front-loaded sentences with no filler: the first states the operation and its phases, the second states how it is computed and what accompanies the result.

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 9 required parameters, zero schema coverage and no output schema, the description carries the burden of explaining inputs and results and does not. An agent can tell roughly what the tool is for but not how to populate the parameters or interpret the phases 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 description coverage is 0%, and the description only loosely maps its three phases onto aggravating/attenuating/increases/decreases. It gives no meaning for minPenaltyMonths, maxPenaltyMonths, unfavorableCircumstances (0–8), repeatOffender, or the baseMethod enum choice between eighth_of_range and sixth_of_minimum — a serious gap for 9 required parameters.

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 computation (arithmetic of sentence dosimetry) and enumerates the three phases it covers (base penalty, aggravating/attenuating, increase/decrease causes), which concretely scopes it against generic calculators. It does not explicitly contrast with close siblings like criminal_prescription_calculate or sentence_execution_calculate, but the domain phrase is distinctive enough to orient an agent.

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

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

There is no statement of when to use this versus the sibling calculation tools, nor of any prerequisite (e.g., that it requires a legal penalty range in months). Usage must be inferred entirely from the phrase 'dosimetria da pena'.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the result includes a legal basis and premises (fundamento e premissas), which is useful, but it doesn't describe the return format or edge-case 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?

Two tight sentences lead with the core purpose and then note the calculation basis. Nothing is wasted, though the second sentence is somewhat vague.

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 tool with five required, undocumented parameters and no output schema, the description should clarify units, the fineRents vs fineAmount relationship, and validation constraints. None of that is present, so an agent could easily miscall it.

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

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

Schema description coverage is 0%, so the description carries the full burden for five parameters, yet it never explains them individually. It only implies that contractMonths and monthsFulfilled drive the proportionality, leaving the critical distinction between fineRents and fineAmount (two alternative ways to express the fine) undocumented.

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: it computes the penalty (multa) for early return of a leased property, proportional to remaining contract time. This clearly separates it from a plain adjustment tool, though it never explicitly names a sibling to contrast with.

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

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

There is no statement of when to use this versus alternatives like rent_adjustment_calculate or other calculate siblings, and no prerequisites or exclusions. The agent must infer the use case entirely from the purpose phrase.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful note that the result comes with a legal basis and premises ('fundamento e premissas'), which tells the agent the output is reasoned rather than a bare number. However, it discloses nothing about input validation, limits, or response shape beyond that hint.

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, front-loaded sentences with no filler. Sizing is appropriate for what little it says, though the brevity comes at the cost of the missing detail noted elsewhere.

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 tool with 5 required parameters, no output schema, and 20% schema coverage, the description leaves major gaps: how sex and contributionYears affect the RMI, what coefficientRule values mean, and what the returned 'fundamento e premissas' comprise. It is not sufficient for an agent to invoke the tool correctly without opening the schema.

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

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

Schema description coverage is only 20%, so the description needs to compensate and does not. It only maps the 'salaries' concept via 'salários de contribuição'; the required parameters sex, contributionYears, coefficientRule (with its general/full/null enum), and startDate (DIB) receive no explanation of their meaning or effect on the calculation.

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: computes the initial monthly benefit income (RMI) for an INSS benefit from contribution salaries. This clearly distinguishes it from siblings like retirement_rules_calculate or benefit_arrears_calculate. It is not tautological, though it stops short of explicitly naming the contrasting siblings.

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

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

There is no indication of when to use this versus alternative tools, no prerequisites (e.g., that the case data or salaries must already exist), and no exclusions. The agent must infer positioning from the name alone among 24 calculation 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?

Annotations already declare the safe read-only, idempotent, non-destructive profile, so the bar is lower; the description still adds the return shape (number, órgão, data, situação, texto/ementa, official link) and the non-obvious fallback that a court without native search returns an officialSearch link instead of results. It does not mention result limits, pagination, or latency, which for an open-world search tool would have been useful.

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, front-loaded with the verb and the "not web search" differentiator, then the source inventory. The long enumerated clause carries genuine routing information but is dense enough that it reads as a list dump; a small structural split would have helped.

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 correctly compensates by naming the fields each precedent returns, and all three required parameters are documented in the schema. The omission of result-count or pagination behavior for a search tool is the only material gap.

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

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

Schema coverage is 100% and the schema itself already documents the enum meanings, the sigla format, and the "Tema 929"/"Súmula 479" query pattern. The description restates the scope groupings and court behavior rather than adding syntax, limits, or examples the schema lacks, 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 ("Pesquisa") and resource (official Lauda jurisprudence databases) and enumerates exactly which corpora each scope covers, so the agent knows what will and will not be searched. It also distinguishes itself from the generic web search path ("sem passar pela busca web"), which is the only plausible alternative given the sibling tools are all calculators/lookups.

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 opening clause tells the agent this replaces a web search for case law, and the parentheticals map each scope value (qualified, stj, state) to the sources it covers, which is real routing guidance. It never states an explicit "do not use when" condition or a prerequisite (e.g., query must be anonymized — that only appears in the schema), so it stops short of 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds value beyond that by disclosing the output shape (foundation and formula for each parcel plus a total), which matters because there is no output schema, but it says nothing about how missing or null inputs (salary, FGTS balance, timecards) affect the result.

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, front-loaded with the operation and its scope; the mention of legal basis and formula is efficient. The trailing 'Use os valores devolvidos nos pedidos líquidos' is vague enough that it spends words without adding clarity.

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 complex 14-parameter calculation with no output schema, the description covers purpose and return content but omits parameter guidance and the timecards-versus-overtime dependency (left to the schema). It is minimally adequate: an agent knows what the tool produces but not how to prepare inputs.

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 only 57% across 14 required parameters, so the description would need to compensate for undocumented fields such as monthlySalary, terminationType, timecardDivisor, and the overtime sub-fields. It mentions none of them, and the one sentence it does contain ('pedidos líquidos') does not map to any parameter.

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

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

The description states a specific verb and resource: it calculates severance payments (verbas rescisórias) and overtime for an employment contract, and it says the result carries the legal basis and formula per line item plus a total. That is clearly distinct from siblings like early_termination_calculate or claim_value_calculate, though the description never names them.

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

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

The only usage instruction is 'Use os valores devolvidos nos pedidos líquidos', which is an ambiguous directive about downstream use rather than when to call this tool instead of one of the 20+ sibling calculators. There is no statement of prerequisites, data the user must supply, or conditions under which another tool fits better.

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=true, idempotentHint=true and destructiveHint=false, so the safe/read-only profile is clear. The description adds that the calculation runs 'por código, com fundamento e premissas', hinting the result carries legal basis and premises, but it does not describe the return structure or any methodology limits.

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

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

Two sentences that front-load the purpose and the refund modes without filler. Dense with legal jargon but no redundant phrasing.

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

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

For a 14-parameter, all-required financial calculation with no output schema, the description is too thin: it does not explain how the many date/rate/installment inputs interact or what the computed output contains. It conveys the concept but not enough to call the tool correctly without leaning on the schema.

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

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

With 14 required parameters and only 36% schema description coverage, the description must compensate, but it only touches on modality, contractDate and refund (simple/double). It says nothing about principal, installments, firstDueDate, paidInstallments, citationDate, referenceDate, informedMonthlyRate or informedRateLabel, leaving most of the input burden unexplained.

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+resource: 'Revisional de empréstimo ou financiamento' that 'recalcula o contrato e apura o que foi pago a mais', differentiating it conceptually from siblings like debt_calculate or over_indebtedness_calculate. It clearly conveys what the tool computes, though it doesn't explicitly name alternatives.

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

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

Usage is implied by the purpose: it applies when reviewing a loan/financing contract against the official Central Bank average rate. There are no explicit conditions for when to use this instead of sibling tools like undue_charges_calculate or over_indebtedness_calculate, and no prerequisites stated.

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/openWorld, so the description correctly focuses on substance: the official source (DJEN/CNJ), recency-first ordering, the official link per item, and that individual party names are abbreviated. It omits what happens with no matches and whether results are paginated or capped.

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

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

Front-loaded with the core action, then return fields, ordering, then usage. The opening sentence is long but every clause carries information; nothing is redundant with the title or schema.

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 returns and does so (fields, ordering, links, name abbreviation). Only edge-case behavior — empty result sets and volume limits — is left 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 description coverage is 100%, so both `uf` and `number` are already well documented with format examples. The description only implicitly links them to 'inscrição da OAB' and adds no extra syntax or constraint 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 and resource ('Lista os processos em que uma inscrição da OAB aparece') and pins down the data source (publicações do DJEN/CNJ). It also enumerates the returned fields, ordering, and privacy treatment, which clearly separates it from the sibling calculator tools.

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?

'Use quando a pessoa informar a OAB e quiser ver os processos dela' gives a clear triggering condition. It stops short of naming alternatives or exclusions (e.g., searching by party name or case number instead of OAB), so the routing guidance is good but not exhaustive.

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=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The line 'A conta é feita por código, com fundamento e premissas' hints that the result carries legal grounding and stated assumptions, but it does not say what the output contains, what assumptions are applied, or how nulls are treated beyond the one schema note.

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 that front-load the legal basis and purpose; little waste. The phrase 'A conta é feita por código' is slightly opaque but does signal a deterministic implementation.

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 legally-grounded calculator with six required inputs, no output schema and near-empty parameter documentation, the description leaves too much unstated: what the result looks like (ratio, plan proposal, fundamento), which assumptions are applied, and when null values fall back to decree defaults for fields other than existentialMinimum.

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 only 17% — only existentialMinimum is documented (null uses the decree value). The description does not explain debits, netIncome, essentialExpenses, planCapacity or date formats, so it fails to compensate for the coverage gap on a 6-required-parameter tool.

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 calculation tied to a statute (Lei 14.181/2021): the ratio of consumer debts to income for a payment plan. That is a clear verb+resource and is more specific than a generic debt calculator, though it never explicitly distinguishes itself from siblings like debt_calculate or undue_charges_calculate.

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?

'Para o plano de pagamento' implies the context of use (structuring a consumer insolvency payment plan), but there is no explicit when-to-use or when-not guidance and no mention of alternatives among the many sibling calculators. Usage has to be inferred from the legal 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 declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context: it runs on a local deterministic engine and returns the full premises, start term, final date, skipped days, and legal basis. The no-assumption rule is an additional operational constraint not captured by 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?

The description is two tight sentences with the core function front-loaded and the key guardrail second. Every sentence carries 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?

It names the returned elements and warns against filling missing bases, which helps for a calculation tool with no output schema. But with 9 required parameters and very low schema description coverage, the description is not complete enough to guide correct invocation in a complex legal-deadline domain.

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 only 22% for 9 required parameters. The description does not explain uf, mode, days, multiplier, multiplierBasis, customHolidays, or startBasis; it only vaguely references 'termo inicial' and 'bases', leaving most required inputs undocumented.

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: calculates a legal deadline in a local deterministic engine. It is clearly a deadline calculator, but it does not explicitly distinguish itself from sibling tools like civil_prescription_calculate or debt_calculate.

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 includes a meaningful guardrail: 'nunca preencha bases ausentes por suposição' (never fill missing bases by assumption). However, it does not say when to use this tool versus the many other calculation siblings, and 'Ferramenta de consulta R2' is not explained.

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, closed-world and non-destructive, so the safety profile is covered. The description's only behavioral claim is the vague 'com fundamento e premissas', which does not tell the agent whether a legal basis text or a list of premises is returned, nor what the calculation outcome looks like.

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 with no padding, and the purpose leads. However, one of the two sentences ('A conta é feita por código, com fundamento e premissas') is meta-commentary that consumes space without conveying usable 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, 0% parameter documentation, and a calculation whose correctness depends on index selection and date semantics, the description leaves critical gaps. An agent could invoke it but could easily pass the wrong date basis or index and never know what the result should contain.

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

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

Schema description coverage is 0%, so the description carries the full burden for three required parameters and it does not meet it. It loosely hints at 'índice' and 'período', but says nothing about 'rent' (is it the current rent? a base value?), the exact meaning of adjustmentDate versus the contract start date, or how to choose among IGP-M/IPCA/INPC/IPCA-E.

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 the resource (rent adjustment) and the mechanism (contract index over a period), which is better than a tautology. But it never distinguishes this tool from the many sibling calculate tools (debt_calculate, loan_review_calculate, undue_charges_calculate) that also take a value and an index, and 'a conta é feita por código' says nothing an agent can act on.

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

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

There is no statement of when to use this tool, what preconditions apply (e.g. an existing lease with a defined index), or which sibling to use for a different kind of monetary correction. The agent must infer everything from the tool name.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that results come 'por código, com fundamento e premissas', hinting the output carries a legal basis and assumptions — useful beyond the annotations, but it never says what the response actually looks like or how incomplete contribution data is handled.

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 with the scope and legal basis front-loaded and no filler. The second sentence is slightly vague ('feita por código, com fundamento e premissas') but earns its place by signalling output content.

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?

Five required parameters, 20% schema description coverage and no output schema: the description should explain the contribution-history input and the returned rule dates, but it only gestures at them. An agent could not confidently build a correct call from this text alone.

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 only 20%: only keepsContributing is documented, while sex, birthDate, contributions and referenceDate carry no descriptions. The description adds no parameter meaning at all — it does not explain the contribution intervals format, the role of referenceDate, or why sex matters (distinct male/female rule sets).

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

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

States a specific resource and regime (regras de transição da aposentadoria no RGPS, EC 103/2019) and what it produces (a data em que cada uma é cumprida). An agent can distinguish it from siblings like initial_benefit_calculate, though the boundary with dosimetry_calculate or prazo_calculate is not spelled out.

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

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

No statement of when to use this tool versus the many sibling calculators, no prerequisites (e.g., that a complete contribution history must be supplied), and no exclusions. The agent must infer applicability from the title 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?

Annotations already carry the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds one genuinely useful behavioral fact: the computation is performed by code rather than generated, and results come with legal grounding and stated premises. It does not say what the response contains (which dates, in which format), how invalid or incomplete inputs are handled, or what the null-tolerant params imply.

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 with no filler, and the scope enumeration is front-loaded. The second sentence earns its place by flagging code-based computation with legal basis. It is compact rather than padded, though the economy contributes to the parameter gap.

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 domain tool this complex — 9 required parameters, a nested penalty object, two enums, no output schema — the description is thin. The heavy lifting is done by the exceptional progressionPercent schema description, but the absence of any return-shape or edge-case statement leaves real holes. It is minimum-viable rather than 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 description coverage is only 11%: just progressionPercent is documented (and documented very richly, including the LEP fractions and the hediondo caveat). The description contributes no field-level meaning of its own; the mapping from 'remição' to workDays/studyHours/completedEducation, or from 'detração' to detractionDays, is only implicit. With 8 of 9 required parameters carrying no documentation anywhere, the description needed to compensate and does not.

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 the resource (datas da execução da pena) and enumerates the four outputs computed: progressão de regime, livramento condicional, remição and término. That is enough to distinguish it from most siblings such as criminal_prescription_calculate or dosimetry_calculate. It stops short of explicitly ruling out the closest neighbours, early_termination_calculate ('término') and prazo_calculate, which an agent could plausibly confuse it with.

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

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

There is no statement of when to use this tool, when not to, or which sibling to prefer for a related question. The only contextual sentence ('A conta é feita por código, com fundamento e premissas') describes how the result is produced, not when to invoke it. An agent must infer the use case entirely from the title and parameter list.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that the calculation is performed 'por código, com fundamento e premissas', hinting at deterministic, citation-backed output, but it does not describe what the result contains or how the correction/interest are derived from the two dates. Modest added value on top of 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?

Two compact sentences with the core definition front-loaded and no padding. The second sentence ('A conta é feita por código, com fundamento e premissas') is a bit vague and could have carried concrete parameter guidance instead.

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, all-required financial calculation tool with no output schema, so the description bears responsibility for explaining what comes back (e.g. corrected principal, interest, doubled totals). It says nothing about the result shape or how referenceDate drives correction, leaving a real gap for an agent that must report results to a user.

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 only 50%: the 'refund' enum and 'citationDate' are documented in the schema, while 'charges' and 'referenceDate' are not. The description restates the simple/double distinction already in the enum and alludes to 'correção e juros', but never explains referenceDate (the correction index date) or the charges array structure. It does not compensate for the uncovered half of the parameters.

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 legal computation – 'repetição de indébito', refund of amounts wrongly charged, simple or double, with correction and interest. That is a clear verb+resource pair an agent can match to a request. It does not explicitly contrast itself with compute-oriented siblings such as debt_calculate or loan_review_calculate, so it stops short of the top score.

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

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

The mention of 'simples ou em dobro' implies the two refund regimes the tool handles, and the schema enum carries the detailed branching rule. However, the description never says when to pick this tool over debt_calculate or loan_review_calculate, nor does it state prerequisites (e.g. that charges must be individually dated). Usage is only implied.

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