Skip to main content
Glama

Obolus.berechne - Calculate payroll

berechne
Read-only

Calculate detailed payroll and net salary for one country and person. Use this for tax class, region, health insurance, pension, deductions, or other country-specific inputs. For the same gross salary across two or more countries, use taxcompare. Use semantic fields where available; legacy fields remain REST compatibility inputs. Monetary fields in the legacy request are minor units and period-specific.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
LZZNoPayroll period identifier for the calculation. Values: 1=year, 2=month, 3=week, 4=day. All salary and payroll monetary inputs must be for this period, not automatically annualized.
ageNoAge in the selected tax year. If omitted, the calculation reports the standard age-35 assumption instead of silently hiding the default.
taxNoPreferred high-level tax assumptions for MCP calls. The adapter maps these to Steuerklasse, Kirche, and Kinderfreibetrag.
LandNoCountry code for the calculation.
ModusNoCalculation mode. Use 1 for one person, 2 for two persons, and 3 for the German TaxSim capped real-splitting simulation.
FaktorNoGlobal factor for factor-based tax class handling.
StjahrNoTax year.
countryNoPreferred high-level country code for MCP calls. For German payroll use DE. The adapter maps this to legacy Land.
CurrencyNoDisplay currency / calculation currency code.
PersonenNoOne or two payroll person records. Each person contains salary, tax class, region, insurance, child, and optional special-income inputs.
locationNoPreferred high-level location input. For Germany, federal_state may be a state code such as BE or a full Obolus state name such as Berlin.
tax_yearNoPreferred high-level tax year for MCP calls. The adapter maps this to legacy Stjahr.
KinderFRBNoTop-level child allowance, child count, dependent count, or child-credit factor for the calculation. DE uses allowance-style factors; AT/CH/US and other systems use country-specific child/dependent meanings where supported.
KinderPVANoTotal child count relevant for German long-term care insurance contribution logic. Leave 0 outside German care-insurance scenarios unless a country-specific child workflow explicitly requires it.
KindergeldNoChild benefit amount in minor units for the selected calculation context. Leave 0 for standard payroll estimates unless explicitly modeling child benefit or a country-specific dependent benefit.
gross_salaryNoPreferred high-level gross salary input. Amount is in major currency units, not cents. The adapter maps it to legacy Gehalt_ct minor units and LZZ.
employee_typeNoPreferred high-level German employee type. Use standard_statutory_employee for the common statutory pension, unemployment, health, and care insurance case.standard_statutory_employee
payroll_presetNoPreferred high-level payroll preset. Use DE_STANDARD_EMPLOYEE_STATUTORY for a normal German employee with statutory pension, unemployment, health, and care insurance.DE_STANDARD_EMPLOYEE_STATUTORY
social_securityNoPreferred high-level German social-security assumptions. Use enums instead of raw Obolus flags. The adapter maps statutory/exempt/private choices to the legacy payroll-engine fields.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
faktorNoTax factor used for German tax class IV factor workflows when applicable.
gesamtNoCombined payroll result across all persons in the calculation. Uses the same country-specific output-code meanings as person1 and person2.
person1NoPayroll result for the first person. Interpret stable output codes with the original request Land and the output country-specific usage notes.
person2NoPayroll result for the second person. Values are zero or empty when the calculation mode uses only one person. Interpret stable output codes with the original request Land.
summaryYesNormalized major-unit amounts for gross income, net income, taxes, social contributions, and total deductions. Use this stable summary for display; raw payroll fields remain available for country-specific detail.
warningsYesNon-blocking warnings about suspicious inputs, such as annual gross sent with monthly LZZ, scaled German Zusatzbeitrag values, or raw German insurance combinations that may be intentional for non-standard cases.
source_urlYesCanonical Obolus URL for the matching interactive calculator.
assumptionsYesNormalized user-facing assumptions used for the payroll calculation, including country, salary period, location, tax class, church tax, and German social-security choices. Use this to explain what the calculation assumed without exposing raw payroll-engine flags.
calculated_atYesUTC timestamp when this response was assembled.
localized_ctaYesLocalized call-to-action labels for opening the visual Obolus report link.
visual_reportYesDeep link to the interactive report or calculator view.
method_versionYesCalculation method or benchmark method version used for this response.
contract_versionYesObolus public contract version used to shape this response.
orientation_noteYesReminder that the result is an orientation estimate, not professional advice.
tax_data_versionYesTax-data or backend-engine revision used for this response.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the 'Calculate' wording is consistent. The description adds beyond annotations by revealing that legacy fields are 'REST compatibility inputs' and warning that 'Monetary fields in the legacy request are minor units and period-specific,' which is important behavioral context for constructing requests.

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

Conciseness5/5

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

Five sentences with no filler: action and scope are front-loaded, sibling routing comes second, and the remaining sentences cover field families and unit conventions. Every sentence earns its place.

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

Completeness3/5

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

The description is a good high-level orientation, but it says 'one country and person' while the schema supports up to two Personen records (maxItems 2, Modus 2). It also doesn't enumerate the recommended semantic fields, though the schema's own description does. For a tool with this complexity, those are notable completeness gaps despite the rich schema.

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?

Schema coverage is 100%, so the baseline is 3. The description adds cross-cutting semantics by distinguishing semantic vs. legacy fields ('Use semantic fields where available; legacy fields remain REST compatibility inputs') and by flagging minor-unit/period conventions, which is not fully captured by individual parameter descriptions.

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 opens with a specific verb and resource: 'Calculate detailed payroll and net salary for one country and person.' It also names the sibling differentiator by saying 'For the same gross salary across two or more countries, use taxcompare,' so an agent can distinguish this tool 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 Guidelines5/5

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

It explicitly lists when to use the tool: 'Use this for tax class, region, health insurance, pension, deductions, or other country-specific inputs.' It also gives a clear exclusion rule by routing multi-country comparisons to taxcompare, leaving no ambiguity about the main alternative.

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