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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral detail: per-month calculation of the amount due, subtraction of payments, INPC correction, and 1% monthly interest from each due date, plus the legal basis. No contradiction with annotations was found.
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 purpose and legal reference, followed by the calculation steps. Every phrase adds information, with no filler, though its compactness contributes to the parameter ambiguity.
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 tool with 9 parameters and no output schema, the description details the calculation methodology but omits the response format, date formats, how optional parameters (juros, indice, data_calculo) interact with defaults, and what 'referencia' means. It is not fully complete for an agent to invoke without further assumptions.
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. It explains the three 'forma' modes ('% do salário mínimo do mês, valor fixo ou % da remuneração') and the role of payments and remuneracoes, but it leaves the required 'referencia' parameter undefined and doesn't mention that 'indice' and 'juros' are configurable. It adds useful semantic context but incompletely maps to the 9-parameter 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 'Pensão alimentícia em atraso (art. 528 CPC)', identifying a specific legal scenario and calculation type. It states a concrete verb ('calcula') and outlines the monthly computation, payment subtraction, and index/interest application, making it easy to distinguish from sibling calculators like calculo_aluguel or calculo_trabalhista.
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 clearly identifies the target use case (arrears alimony under art. 528 CPC), so an agent knows when to select it. However, it does not explicitly name sibling tools or state when not to use it, so the guidance relies on the specificity of the legal domain rather than explicit alternatives.
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 calculation tools are each tied to a distinct legal scenario (rent, criminal sentencing, FGTS, labor severance, etc.), so misselection is unlikely. However, the platform meta-tools overlap: connect, toolkit_info, and authenticate all deal with connection/auth state, and marketplace's list_tools/describe overlaps with toolkit_info.
The legal calculators use a consistent calculo_<domain> prefix, which is highly predictable. But the six meta-tools use standalone English names (connect, marketplace, report_bug) and the prefix itself mixes nouns (calculo_aluguel) with a verb (calculo_atualizar), so the overall convention is not uniform.
22 tools is on the heavy side for a server claiming to be about 'juros e multa', especially since six tools are unrelated platform administration features. The 16 legal calculators are arguably well-scoped, but the meta-tool wrapper inflates the count and blurs the server's purpose.
The legal calculation surface is unusually broad: civil, criminal, labor, social security, banking, and family law are all represented, and the calculo_atualizar tool provides the generic debt-update/interest/fee calculation implied by the server name. Minor gaps exist—there is no dedicated simple-interest-only calculator or court-fees/custas calculator—but no obvious dead-end workflows remain.