nestegg-calculators

German Net Salary (exact, by tax year)

de-net-salary

Read-onlyIdempotent

Exact German net (Netto) salary from annual gross (Brutto) for tax years 2023-2026. Income tax and Soli follow the official BMF Programmablaufplan for the year (to the euro; 2024 uses the retroactive December tariff), church tax comes from the PAP's Kirchensteuer base, and employee social insurance uses that year's ceilings and rates (KV Zusatzbeitrag defaults to the year's average). Earlier years are rejected - use de-gross-to-net with self-supplied figures instead.

Input Schema

TableJSON Schema

Name	Required	Description
`age`	No	Optional. Age in years - under 23 skips the childless care surcharge.
`year`	Yes	Tax year: 2023, 2024, 2025 or 2026.
`faktor`	No	Optional. Tax-class-4 Faktorverfahren factor, default 1.0 (no factor). Only the small minority of married IV/IV couples who applied for it have one; it is assigned by the Finanzamt and printed on the payslip / ELStAM (e.g. 0.921, always <= 1). Leave unset unless the payslip shows a Faktor.
`children`	No	Kinderfreibetrag counter (ZKF), halves allowed (default 0). Also drives the care-insurance child discounts.
`taxClass`	No	Steuerklasse 1-6 (default 1).
`bundesland`	No	Optional. State code (BW, BY, BE, ... SN, TH). Drives the Saxony care-insurance split and the pre-2025 East pension ceiling.
`grossAnnual`	Yes	Annual gross salary (Brutto) in EUR.
`kvZusatzPct`	No	Optional. The Krankenkasse's own Zusatzbeitrag in percent — pass the actual rate for exact results (rates change yearly, e.g. TK 2025: 2.45, 2026: 2.69). Defaults to the year's official average, which is only right for generic estimates.
`churchTaxPct`	No	Church tax rate: 8, 9, or 0 for none (default 0).
`privateHealth`	No
`childrenUnder25`	No	Optional. Children under 25 for the care-insurance discounts, when it differs from `children`.

Output Schema

TableJSON Schema

Name	Required	Description
`net`	No	{ annual, monthly }.
`soli`	No	Solidaritätszuschlag.
`year`	No	Tax year.
`gross`	No	{ annual, monthly }.
`totalTax`	No	All taxes.
`churchTax`	No	Kirchensteuer.
`incomeTax`	No	Lohnsteuer (annual).
`assumptions`	No	Inputs as applied (tax class, Zusatzbeitrag, PAP basis, ...).
`contributions`	No	{ pension, unemployment, health, care, total, rates, ceilingsApplied }.
`totalDeductions`	No	Taxes + contributions.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJul 6, 2026

changedInput schema / properties / faktor / description

Previous value: -"Optional. Steuerklasse-4 Faktorverfahren factor (e.g. 0.921)."New value: +"Optional. Tax-class-4 Faktorverfahren factor, default 1.0 (no factor). Only the small minority of married IV/IV couples who applied for it have one; it is assigned by the Finanzamt and printed on the payslip / ELStAM (e.g. 0.921, always <= 1). Leave unset unless the payslip shows a Faktor."

Changed1 schema field changedJul 3, 2026

changedInput schema / properties / kvZusatzPct / description

Previous value: -"Optional. Your Krankenkasse's Zusatzbeitrag in percent; defaults to the year's official average."New value: +"Optional. The Krankenkasse's own Zusatzbeitrag in percent — pass the actual rate for exact results (rates change yearly, e.g. TK 2025: 2.45, 2026: 2.69). Defaults to the year's official average, which is only right for generic estimates."

AddedJul 2, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already mark the tool as read-only and idempotent. The description adds valuable behavioral details beyond annotations: the official BMF Programmablaufplan, 2024 retroactive tariff spec, church tax base, social insurance ceilings, and the Zusatzbeitrag default. It also notes rejection of earlier years. This goes beyond the annotation basics, though it doesn't detail output structure (covered by output schema).

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?

The description is a single dense sentence with a follow-up sentence for the alternative tool. It front-loads the main purpose and packs in crucial details without waste. It's slightly longer than ideal but every clause carries information, earning a 4.

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?

Given the tool's complexity (11 parameters, nested object, output schema), the description covers the essential context: tax year range, official method, regional/status defaults, and the rejection of out-of-range years. The output schema covers return values, so the description needn't explain those. It could mention a few more edge cases, but overall it's complete enough.

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

Parameters3/5

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

Schema description coverage is 91%, so the schema already documents most parameters thoroughly. The description mentions one parameter default (KV Zusatzbeitrag average) which is already in the schema, but does not add significant extra meaning beyond schema. Baseline 3 is appropriate.

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?

The description states the tool computes exact German net salary from annual gross for tax years 2023-2026, using specific official methods. It clearly distinguishes from the sibling de-gross-to-net by noting that earlier years are rejected and directing users to that tool with self-supplied figures.

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

Usage Guidelines5/5

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

Explicitly states when to use (for exact official calculations in 2023-2026) and explicitly names the alternative (de-gross-to-net) for rejected years. This provides clear when-to-use and when-not-to-use guidance.

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

All nestegg-calculators tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.