Skip to main content
Glama

FalaZuki Finance BR

check_payslip

Confere um holerite de empregado CLT contra as tabelas vigentes NA COMPETÊNCIA (INSS desde ago/2006, IRRF desde jan/2007), item a item, com veredito global em três estados (conferido completamente, parcialmente, não foi possível concluir). Regras: o documento manda na base (informe inss_base/irrf_base impressas no holerite quando existirem; o salário bruto é contexto e insumo do redutor da Lei 15.270); com irrf_base declarada, pensão alimentícia deixa de bloquear a conferência do IRRF; o IRRF é conferido contra a base efetivamente usada (INSS informado como dedução) e um INSS divergente gera a segunda análise exposta, nunca falso positivo em cascata. Verbas declaradas em declared_items que o motor não audita viram 'informado, não conferido' e impedem conclusão sobre o total. Com total_earnings e net_received (e todos os descontos declarados com valor), roda a reconciliação aritmética como afirmação SEPARADA: fechar na soma não promove verba a correta. Parâmetros obrigatórios: gross_salary, informed_inss, informed_irrf, reference_date. Opcionais: inss_base, irrf_base, dependents, total_earnings, net_received, declared_items. Use exatamente estes nomes, em inglês.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inss_baseNoA 'Base INSS' / 'Salário de contribuição' impressa no holerite, em R$. Sem ela, o bruto entra no lugar com a hipótese declarada
irrf_baseNoA 'Base IRRF' impressa no holerite, em R$. Ela já embute pensão e demais deduções, e destrava a conferência do IRRF quando existem
dependentsNoDependentes declarados na fonte pagadora
gross_salaryYesSalário bruto do mês, em R$. Contexto: a base quem manda é o documento
net_receivedNoValor líquido recebido, em R$ (habilita a reconciliação aritmética)
informed_inssYesO INSS descontado no holerite, em R$
informed_irrfYesO IRRF retido no holerite, em R$
declared_itemsNoOutras verbas do holerite, com valor quando disponível. Proventos: overtime, commissions, bonuses, night_shift, unhealthy_pay, hazard_pay, other_earnings. Descontos: transport_voucher, meal_voucher, health_plan, alimony, absences, other_deductions. Declará-las evita conclusão ingênua sobre o total
reference_dateYesQualquer dia dentro da competência do holerite, aaaa-mm-dd
total_earningsNoTotal de proventos do documento, em R$ (habilita a reconciliação aritmética)

TDQS

A4.2/5.0
Behavior5/5

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

Sem anotações, a descrição carrega todo o ônus — e o faz com riqueza: veredito em três estados, precedência da base impressa sobre o bruto (com papel do redutor da Lei 15.270), irrf_base destravando pensão, prevenção de falso positivo em cascata, verbas 'informado, não conferido' bloqueando conclusão sobre o total, e a reconciliação aritmética como afirmação separada. Nenhuma contradição.

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

Conciseness3/5

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

O propósito é front-loaded, mas o texto é um bloco único e denso de regras sem estrutura (sem bullets, sem separação). Todo o conteúdo é relevante e merece espaço, mas o formato de parede de texto dificulta a leitura rápida. É compreensível e completo, mas não conciso.

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

Completeness4/5

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

Para um ferramenta complexa (10 parâmetros, regras interligadas), a descrição é bastante completa: lista obrigatórios/opcionais, dá os nomes exatos dos parâmetros, explica os estados do veredito. Sem output schema, a menção ao veredito de três estados cobre o retorno. Faltam detalhes explícitos sobre erros (ex.: datas inválidas) e a estrutura exata da 'segunda análise', mas o conjunto é robusto.

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

Parameters4/5

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

A cobertura do schema é 100% e as descrições do schema já são ricas, então a linha de base é 3. A descrição da ferramenta agrega além disso: explica as interações entre parâmetros (inss_base/irrf_base mandam sobre gross_salary; total_earnings/net_received habilitam a reconciliação; declared_items com itens não auditados impedem conclusão sobre o total). Isso adiciona semântica cruzada que o schema não captura.

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

Purpose5/5

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

A descrição é específica: 'Confere um holerite de empregado CLT contra as tabelas vigentes... item a item, com veredito global em três estados'. Verbo + recurso + escopo claros, distinguindo-se dos irmãos check_inss_deduction/check_irrf_deduction (que conferem dedução única) por auditar o holerite completo com veredito global. Não é tautologia nem vago.

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

Usage Guidelines3/5

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

O contexto de uso é claro (verificação de holerite CLT completo), mas não há orientação explícita de exclusão ou roteamento para alternativas — não diz quando usar check_inss_deduction ou check_irrf_deduction em vez desta ferramenta, nem lista condições de quando não usar. As regras internas são detalhadas, mas o 'quando usar vs. quando não' fica implícito.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation2/5

Many tools are clearly distinct, but the set contains several near-identical clusters: calculate_dividend_income_goal and calculate_dividend_yield both answer 'how much capital is needed to reach a dividend income target', and calculate_real_salary, calculate_raise_vs_inflation, and calculate_salary_time_value overlap heavily on salary/inflation comparisons. Generic tools like compare_investments and compare_with_cdb also blur the boundary with the many specific yield calculators.

Naming Consistency3/5

Most tools follow a clear verb_noun snake_case pattern with verbs like calculate_, get_, check_, compare_, and advise_. However, the object language is inconsistent (calculate_ganho_capital_imovel alongside calculate_car_affordability), and can_i_quit_job breaks the command-style pattern with a question.

Tool Count1/5

At 114 tools, the server is extremely over-scoped for an MCP surface; an agent cannot reasonably hold all these options in context. The inclusion of a search_calculator tool to route among the others is a strong signal that the tool set itself needs partitioning.

Completeness4/5

The surface is very comprehensive for Brazilian personal finance: employment, taxes, investments, debt, real estate, vehicles, small business, insurance, and market-data queries are all covered. A few minor gaps exist, such as no dedicated generic boleto-fine calculator or consolidated investment comparison engine, but no core workflow feels badly stranded.

Resources