Pensão alimentícia em atraso (art. 528 CPC): por mês do período calcula o devido (% do salário mínimo do mês, valor fixo ou % da remuneração), subtrai pagamentos e aplica correção (INPC) + juros 1% a.m. desde cada vencimento.
| Name | Required | Description | Default |
|---|---|---|---|
| forma | Yes | ||
| juros | No | ||
| indice | No | ||
| fim_atraso | Yes | ||
| pagamentos | No | ||
| referencia | Yes | ||
| data_calculo | No | ||
| remuneracoes | No | ||
| inicio_atraso | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable algorithmic detail: per-month calculation based on % of minimum wage/fixed value/% of remuneration, subtraction of payments, INPC correction, and 1% monthly interest from each due date. Minor transparency gap: it presents INPC and 1% as fixed while the schema exposes juros and indice parameters, which could mislead an agent into thinking they are not configurable.
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 with no filler. It front-loads the purpose and each clause adds necessary algorithmic information: what is calculated, what is subtracted, and what correction/interest is applied. Every part 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?
Given the tool's complexity (9 parameters, arrays, enums, no output schema), the description provides the core algorithm but is incomplete. It does not describe the return value structure, the meaning of data_calculo/referencia, or how competencia strings in the arrays are formatted. These gaps could leave an agent unsure how to correctly populate all 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 0%, so the description must compensate, and it does substantially. It explains the meaning of forma (the three modes), pagamentos (subtracted), indice/juros (correction + interest), and the period (inicio/fim). However, it does not explain referencia, data_calculo, or how remuneracoes array is used in detail, leaving some parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it calculates overdue alimony (pensão alimentícia em atraso) per month, subtracts payments, and applies correction and interest. It clearly distinguishes itself from sibling tools by subject matter and legal basis (art. 528 CPC), leaving no ambiguity about what it 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 provides clear context: this tool is for alimony arrears calculation. It does not explicitly name alternatives or when-not-to-use, but the specific legal article and subject make the appropriate use case evident. This meets the 'clear context, no exclusions' threshold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The 16 calculo_* tools are each tied to a specific legal area and are generally easy to distinguish. However, the platform tools overlap: marketplace bundles discovery, auth, listing, and bug-report flows that also exist in authenticate, connect, toolkit_info, and report_bug.
The calculo_* group is highly consistent and readable. The six platform tools follow a different, more mixed English convention with bare verbs, noun phrases, and snake_case names, so the set as a whole has two naming schemas rather than one.
22 tools is in the heavy 16-25 range and feels excessive for a server titled 'Reajuste de Aluguel'. Some legal calculators are useful in a broader legal-calculation platform, but the title and the actual scope are mismatched.
For a broad Brazilian legal-calculation toolkit, coverage is quite wide: rent, monetary updating, criminal sentencing, FGTS, INSS, labor, and banking calculations are present. Still, there are notable gaps for a general legal surface, such as other INSS benefit calculations or civil compensation estimates, and the rent-adjustment title does not represent the full set.