Brazilian 2026 payroll and MEI estimates. 50 free calls/day/IP; optional paid annual key.
Scored across 8 tools
Each tool maps to a clearly distinct Brazilian payroll/accounting calculation type: 13o, DAS-MEI, férias, FGTS, horas-extras, INSS, IRRF, and rescisão. Although descriptions are terse and follow the same phrasing, the domain terms are specific and do not overlap in practice.
All tool names follow a consistent lowercase, hyphenated noun pattern tied directly to the calculation domain. There are no mixed verb styles or casing conventions.
Eight tools is well-scoped for a focused payroll/accounting calculation API. Each tool represents a distinct calculation type and none appears redundant.
The surface covers many common Brazilian payroll calculations, including taxes, benefits, vacation, termination, and overtime. Minor gaps may exist around generic salary/net-pay simulation or broader accounting operations, but core workflows appear covered.
Cálculo informativo 13o 2026
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | ||
| salary | Yes | ||
| advance | No | ||
| dependents | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool claims to be 'informational,' which is helpful, but since there are no annotations and zero contextual detail, the agent has no information regarding the calculation methodology. It fails to disclose behavioral traits like how 'dependents' or 'advance' specifically impact 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?
The description is extremely concise, serving primarily as a title/label for the tool. Every word is focused on the topic of 13o calculation. While brevity is good, its extreme lack of information prevents a higher score in this category.
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 that there are four complex input parameters and the description adds zero semantic value or operational context, the definition is critically incomplete. An agent cannot reliably know how to format or interpret the necessary inputs for this payroll function.
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?
Since schema description coverage is 0%, the description was expected to define its 4 input parameters, yet it does so nowhere. The agent must rely entirely on guessing what 'salary', 'months', 'advance', and 'dependents' mean within the context of 13o without any definition from the description.
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 resource and action as an 'Informational 13th salary calculation.' The inclusion of the year '2026' provides a useful scope marker. However, because there are many sibling tools (e.g., 'fgts', 'irrf'), it does not explicitly state why this specific calculation is necessary over others.
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 offers no usage guidance whatsoever. It does not explain whether this tool should be used at the start of a fiscal year, if it requires specific payroll data, or how it relates to other calculation tools available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cálculo informativo das-mei 2026
| Name | Required | Description | Default |
|---|---|---|---|
| activity | Yes | servicos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The word 'informativo' hints that this is an informational rather than official or transactional calculation, but it does not state side effects, assumptions, permissions, or whether the result is merely illustrative.
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 very short and front-loaded with no wasted words. However, it is too terse to function well as task guidance for a calculator with no annotations or output 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?
Given zero annotations, no output schema, and 0% schema description coverage, the description should clarify what is calculated and how the activity parameter affects the result. It only names the calculation and year, leaving key invocation context implicit.
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 0% and the single required 'activity' parameter is not mentioned at all. The description does not explain the enum values comercio, servicos, or ambos, nor how activity changes the DAS-MEI 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?
The description states a specific action and resource: an informational calculation for DAS-MEI 2026. The domain-specific resource distinguishes it from siblings such as inss, irrf, or ferias, though it does not explicitly contrast 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?
There is no explicit guidance on when to use this tool versus the many sibling calculators. The name and year imply the DAS-MEI context, but the description does not state conditions, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cálculo informativo ferias 2026
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| salary | Yes | ||
| dependents | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The word 'informativo' faintly implies an estimate rather than an official payroll figure, which is useful, but there is no disclosure of determinism, rounding, what the result contains, or whether inputs like dependents affect the outcome — gaps that matter for a calculation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single five-word phrase is not padded, but it is under-specified rather than concise — there is no front-loaded statement of inputs, outputs or scope to justify the brevity. Brevity here costs the agent necessary 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?
For a 3-parameter calculation tool with no annotations and no output schema, the description provides essentially nothing an agent needs: not what the result represents, not what each parameter means, not how it differs from the other seven payroll calculators. Grossly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: 'days', 'salary' and 'dependents' have only types, defaults and ranges. The description supplies no meaning at all — it does not say that 'days' is vacation days (capped at 30), that 'salary' is gross monthly pay, or that 'dependents' feeds a deduction. It completely 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?
Names a specific domain (vacation/ferias pay) and a year, and the verb 'Cálculo' signals a computation tool. However, it never says what is actually computed — gross vacation pay, the constitutional 1/3 bonus, net after INSS/IRRF — so it is only distinguishable from siblings like 'rescisao' or '13o' by the tool name itself. Adequate but vague on scope.
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 indication of when to use this instead of the sibling calculators (inss, irrf, fgts, rescisao), nor any prerequisites such as whether salary is gross or net. The agent must infer usage purely from the tool name in the context of a payroll-calculator family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cálculo informativo fgts 2026
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | Alíquota: 8 comum ou 2 aprendiz (%) | |
| months | No | Meses futuros de depósitos a projetar | |
| salary | Yes | Remuneração sujeita ao FGTS (R$) | |
| balance | No | Base rescisória para multa, não saldo após saques (R$) | |
| current | No | Saldo atual total das contas FGTS (R$) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it only signals that the result is informational. It does not say the calculation is a simulation not valid for official filing, whether the current-year rate is assumed, or anything about deterministic vs projected outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short phrase with no wasted words, but it is under-specified rather than concise — the year "2026" is the only distinctive information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, a required salary, a fine-base vs current-balance distinction, and no annotations or output schema, the description should explain what the tool returns and how the two balance inputs are used. It provides none of that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each of the five parameters (rate 8/2, months, salary, balance, current) is already documented with units and ranges in the schema. The description adds no interpretation, such as how 'balance' versus 'current' interact, so this sits at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Cálculo informativo fgts 2026" names a verb (cálculo) and a resource (FGTS) and adds a year, but it never says what is actually computed — deposit projection, rescission fine, or both. This matters because the schema exposes both salary/monthly-deposit parameters and balance/current (fine-base) parameters, and the sibling 'rescisao' also touches FGTS.
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 versus alternatives such as 'rescisao' (which computes the 40% FGTS fine on termination) or 'ferias'. The word "informativo" hints at a simulation, but no conditions, prerequisites, or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cálculo informativo horas-extras 2026
| Name | Required | Description | Default |
|---|---|---|---|
| rest | No | Domingos e feriados sem duplicidade | |
| salary | Yes | Base remuneratória (R$) | |
| divisor | No | Divisor mensal da jornada | |
| hours50 | No | Horas extras a 50% | |
| night50 | No | Horas de relógio extras noturnas a 50% (não repetir acima) | |
| hours100 | No | Horas extras a 100% | |
| night100 | No | Horas de relógio extras noturnas a 100% (não repetir acima) | |
| workdays | No | Dias úteis do mês (inclua sábados aplicáveis) | |
| nightHours | No | Horas de relógio noturnas regulares (sem extras) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Informativo' hints the output is non-binding, but nothing is said about what is returned (values breakdown, rounding, currency handling), whether there is any side effect, or how night hours must be entered to avoid double counting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short phrase with zero redundancy, but it is under-specified rather than efficiently concise. There is no sentence structure to front-load anything beyond the tool's topic.
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?
A 9-parameter calculation tool with no annotations and no output schema needs the description to explain inputs' interplay (night hours vs regular night hours, divisor, workdays) and what the response contains. Neither is addressed, leaving the agent to infer everything from the schema 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 100% with 9 parameters, each carrying its own Portuguese description (e.g. divisor mensal da jornada, horas de relógio noturnas). The description adds no additional meaning 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?
The phrase 'Cálculo informativo horas-extras 2026' names the resource (overtime hours) and the action (informational calculation) with a year qualifier, so an agent can broadly tell what it does. However it never states the scope of the calculation – base salary, 50%/100% multipliers, night premium or DSR – so the exact result produced remains ambiguous.
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 prefer this tool over the sibling payroll calculators (ferias, rescisao, inss, irrf), nor of prerequisites such as needing a salary base or the 2026 reference year. The word 'informativo' only faintly signals that the result is an estimate rather than an official payroll figure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cálculo informativo inss 2026
| Name | Required | Description | Default |
|---|---|---|---|
| salary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and it does very little: it does not state the calculation basis (progressive brackets vs flat rate), rounding, which 2026 table/version is used, or that results are estimates rather than official figures. 'Informativo' is the only behavioral signal.
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?
Extremely short and front-loaded with no filler, but the brevity comes from under-specification rather than efficiency — the single phrase omits what an agent needs to invoke the tool correctly.
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 annotations, no output schema, and undocumented parameters, the description is the only channel for explaining inputs and return values — yet it explains neither. An agent cannot tell what the returned figure represents or how it is derived.
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% for the single required 'salary' parameter, so the description must compensate and does not. It never clarifies whether salary is gross monthly salary in BRL, whether it should include other discounts, or how the default of 3000 and the 0–100,000,000 bounds relate to 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?
Names a specific domain calculation (INSS 2026), which distinguishes it from siblings like irrf, fgts and rescisao. However, 'Cálculo informativo' is vague about what is actually computed — contribution amount, rate, bracket — and 'informativo' is never explained.
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 versus irrf or the other payroll calculators, and no statement about input expectations or prerequisites. Only the word 'informativo' implies a non-official estimate, which is an indirect hint at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cálculo informativo irrf 2026
| Name | Required | Description | Default |
|---|---|---|---|
| salary | Yes | ||
| dependents | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. 'Informativo' hints that this is an informational estimate rather than an official filing, but the description does not explain assumptions, rate tables, output format, or whether results are estimates only.
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 short phrase with no wasted text and is front-loaded with the core purpose. It is appropriately sized in form, though the brevity contributes to the overall under-specification.
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 a tax calculator with no annotations, no output schema, and 0% parameter description coverage, the description is insufficient. It identifies the calculation and year but leaves out what the calculation returns, how dependents affect it, and what assumptions apply.
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 by explaining the two parameters, but it says nothing about salary or dependents. The parameter names and min/max values are intuitive in the schema, but the description adds no semantic meaning or clarification.
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 calculation resource (IRRF) and a specific year (2026), so the agent can tell this is an IRRF tax calculator. It does not explicitly differentiate from siblings such as inss or the other payroll calculators, but the resource acronym itself carries meaningful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like inss, 13o, or rescisao. It implies a calculation context but provides no explicit usage conditions, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cálculo informativo rescisao 2026
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| fgts | No | ||
| type | No | sem | |
| notice | No | ||
| salary | Yes | ||
| periods | No | ||
| months13 | No | ||
| monthsVacation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it discloses almost nothing. The word 'informativo' weakly signals that the output is informational rather than an official payroll figure, but there is no mention of return format, accuracy caveats, or how the termination-type enum affects behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single short phrase is not verbose but is under-specified rather than concise—there is no structure, no front-loaded explanation of inputs or outputs, and nothing that earns its place beyond a label.
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 an 8-parameter calculator with zero schema documentation and no output schema, the description is far too thin. An agent cannot determine which of the 8 inputs are required, what the enum choices mean, or what the calculation returns.
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 8 parameters, and the description adds no meaning for any of them. Critical semantics such as the 'type' enum values (sem, acordo, pedido, justa), 'notice', 'periods', and the 13th-salary/vacation month counts are left completely 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 resource (rescisao, i.e., severance calculation) and ties it to year 2026, which distinguishes it from siblings like ferias, fgts, and 13o. However, the verb is only implied by 'Cálculo' and the qualifier 'informativo' is left unexplained, so the exact purpose is vague beyond 'something about severance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when to use this tool versus the sibling calculators (fgts, ferias, inss, irrf), nor any mention of prerequisites or exclusions. An agent must infer entirely from the tool name what scenario triggers it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
13odas-meiferiasfgtshoras-extrasinssirrfrescisaoBrazil CNPJ, CEP, Selic/IPCA/PTAX, holidays, banks/ISPB for agents. Pay per call in USDC (x402).
Receita Federal: SIMEI (Declaração Anual), official-source lookup. Platform-hosted, pay per query wi
Receita Federal: Simples (Issuance de DAS de MEI), official-source lookup. Platform-hosted, pay per
Receita Federal: Simples (DASN SIMEI), official-source lookup. Platform-hosted, pay per query with p
Add one secure layer between your agents and this server.