Skip to main content
Glama

Calculate German net salary

calculate_net_salary
Read-onlyIdempotent

Calculate German take-home pay from gross pay for the current tax year (2026), using the official German wage-tax calculation program and the statutory social-insurance rates for that year. Use it when the user gives a gross salary and wants to know what arrives in their account, or wants to compare two offers net. The result breaks out wage tax, solidarity surcharge, church tax and each social-insurance contribution, monthly and annually.

tax_class is the German Steuerklasse 1 to 6 and is the single largest driver of the result; ask the user for it rather than guessing, and note that class 3 and 5 only make sense for married couples and class 6 only for a second job. bundesland is needed because church tax is 8 percent in Bavaria and Baden-Württemberg and 9 percent elsewhere, and because employees in Saxony pay a different care-insurance share. child_allowances is the Kinderfreibetrag count, which is 0.5 per child for each parent when the allowance is split, not the number of children.

For a privately insured employee set health_insurance to 'private' and pass the monthly basic-cover premiums from the insurer's contribution statement: health in private_health_premium_eur_per_month and care (Pflegepflichtversicherung) in private_care_premium_eur_per_month; ask the user for both rather than guessing. The employer subsidy is computed by law for each part (half the premium, each with its own cap) and only the employee's share is deducted. Without the care premium the amount counts as health cover only.

For civil servants (Beamte) set employment to 'civil_servant'. Most are privately insured: then set health_insurance to 'private' and pass the monthly premium they pay after Beihilfe in private_health_premium_eur_per_month, and ask the user for it rather than guessing. Civil servants pay no pension or unemployment contributions; a civil servant in statutory health insurance pays the full contribution at the reduced rate, without pauschale Beihilfe, and you must pass children_for_care_insurance and childless_over_23 for the care rate. The calculation uses the same engine as JobJump's civil-servant pay calculator. get_tariff_pay returns the gross pay for a civil-servant grade.

This is a deterministic calculation from the values you pass, not tax advice and not a payslip. It does not model other people exempt from statutory pension insurance, family supplements, Lohnsteuerjahresausgleich, one-off payments, company pension schemes, capital income, or any individual allowance entered on a tax card. The figures are approximate and the user should confirm them with their employer or a tax adviser before relying on them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "gross_amount_eur": "<gross_amount_eur>",
      "gross_period": "<gross_period>",
      "tax_class": "<tax_class>",
      "bundesland": "<bundesland>"
    },
    "name": "calculate_net_salary"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNoTax year. Only 2026 is implemented.
tax_classYesGerman Steuerklasse. 1 single, 2 single parent, 3 married higher earner, 4 married equal earners, 5 married lower earner, 6 second and further jobs.
bundeslandYesFederal state the person lives in, as its two-letter code. Sets the church-tax rate (8 percent in BY and BW, 9 percent elsewhere). For employees in statutory insurance it also sets the Saxony care-insurance split; civil servants pay the same half care rate in every state.
church_taxNoWhether the person is liable for church tax.
employmentNo'employee' for employees in the statutory pension scheme. 'civil_servant' for Beamte: no pension or unemployment contributions. With private insurance the premium paid after Beihilfe is deducted; with statutory insurance the full health contribution at the reduced rate plus the full Zusatzbeitrag and care insurance at the half rate for Beihilfe recipients.employee
gross_periodYesWhether gross_amount_eur is an annual or a monthly figure.
child_allowancesNoKinderfreibetrag count (ZKF), in steps of 0.5. Each parent normally carries 0.5 per child; a single claimant carries 1.0 per child. This is not the number of children.
gross_amount_eurYesGross pay in euros, before any deduction.
health_insuranceNoStatutory (gesetzlich) or private (privat) health insurance.statutory
childless_over_23NoWhether the person is 23 or older and has no children, which adds the care-insurance surcharge. Treated as false for employees when omitted; required for a civil servant in statutory insurance.
children_for_care_insuranceNoNumber of children under 25 for the care-insurance reduction. Counted separately from child_allowances because the two rules differ. Treated as 0 for employees when omitted; required for a civil servant in statutory insurance.
statutory_additional_rate_percentNoThe health fund's Zusatzbeitrag in percent. 2.9 is the 2026 average and is used when the user does not know theirs. Only applies with statutory insurance.
private_care_premium_eur_per_monthNoMonthly private care premium (Pflegepflichtversicherung) in euros, as on the insurer's contribution statement. Only used when health_insurance is 'private'. For an employee the employer pays half of it up to its own cap; when it is omitted, private_health_premium_eur_per_month counts as health cover only. For a civil servant it is added to the premium paid after Beihilfe.
private_health_premium_eur_per_monthNoMonthly private health premium (Krankenversicherung) in euros for basic cover, as on the insurer's contribution statement, greater than 0. Required when health_insurance is 'private'. For an employee, the full premium before the employer subsidy; the subsidy is computed and only the employee's share is deducted. For a civil servant, the amount paid after Beihilfe, for health and care together unless private_care_premium_eur_per_month is passed.

Output Schema

NameRequiredDescriptionDefault
deductionsYes
provenanceYes
assumptionsYes
disclaimersYes
net_per_yearYes
net_per_monthYes
calculator_urlYes
gross_per_yearYes
gross_per_monthYes
effective_deduction_rate_percentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description goes well beyond them: a deterministic calculation, the statutory basis, approximate output, and a concrete list of what is excluded (Lohnsteuerjahresausgleich, one-off payments, company pensions, tax-card allowances). It also discloses the branch logic for private insurance and civil servants that changes the result materially.

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

Conciseness4/5

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

Purpose and trigger are front-loaded, then parameter guidance, then limits, which is the right ordering. It is long for a description and repeats 'ask the user for it rather than guessing' three times, and restates the 8/9 percent church-tax rule already in the schema, so a few sentences could be trimmed.

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

Completeness5/5

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

For a 14-parameter tool with four enums and branching paths, the description covers the two hardest branches (private insurance, Beamte) and points out which optional fields become mandatory there. An output schema exists, so the brief note that the result breaks out wage tax, solidarity surcharge, church tax and each social contribution monthly and annually is sufficient without describing return values in detail.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real decision guidance the schema lacks: ask for tax_class rather than guessing, classes 3/5 apply to married couples and 6 to a second job, child_allowances is 0.5 per child per parent and not a child count, and church tax varies 8 vs 9 percent by Bundesland with a Saxony care-insurance exception. It also explains the interaction between private_health_premium_eur_per_month and private_care_premium_eur_per_month and the civil-servant requirement for children_for_care_insurance and childless_over_23.

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?

States a specific verb and resource (calculate German take-home pay from gross pay) plus the engine and year, which no sibling duplicates. It also names the boundary against get_tariff_pay (gross pay for a civil-servant grade) and against a payslip or tax advice, so the agent can place it in the toolset without opening the schema.

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

Usage Guidelines4/5

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

Gives concrete trigger conditions: the user supplies a gross salary and wants the amount that arrives in their account, or wants to compare two offers net. It also routes gross-pay lookup to get_tariff_pay and lists cases it does not model. It never explicitly distinguishes itself from evaluate_salary_offer, a close sibling on the 'compare offers' use case, so the routing is clear but not exhaustive.

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.

Resources