Skip to main content
Glama

Poland Salary Calculator

Net salary in Poland (2026)

net_salary
Read-onlyIdempotent

Take-home pay for an employee in Poland from a gross yearly salary in PLN, with 2026 rules: every tax and contribution itemised with its local name, the effective and marginal rate, employer cost and the step-by-step workings. Covers: PIT 12%/32% with the 30,000 zł tax-free amount; Zero-PIT reliefs: under 26, return relief, families with 4+ children; Joint return with a spouse; Child relief with the refundable part; PPK, 50% author costs, higher commuting costs; ZUS up to the 2026 cap, 9% health contribution.

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_annual": "<gross_annual>"
    },
    "name": "net_salary"
  }
}

Input Schema

NameRequiredDescriptionDefault
ageNoAge; changes the result here (young-worker reliefs, senior slabs, surcharges). Default 35.
ppkNoEmployee Capital Plan (PPK). You pay 2%, the employer 1.5% (taxable for you). Default false.
jointNoJoint return with spouse Default true.
authorNoShare of pay under copyright. Creative work (software, design, writing): 50% costs on that part, up to 120,000 zł of costs. (%). Default 0.
marriedNoMarried or registered partner. Default false.
childrenNoNumber of dependent children. Default 0.
commuterNoLive outside the town where you work. Standard costs of 300 zł instead of 250 zł a month. Default false.
fx_per_eurNoExchange rate: 1 euro = this many PLN, for the euro amounts. Default 4.25 (indicative).
bonus_annualNoYearly bonus in PLN. Default 0.
gross_annualYesGross yearly salary in PLN, without bonus
return_reliefNoReturn relief (ulga na powrót). For 4 years after moving to Poland, for Polish citizens or people with Polish roots who lived abroad for 3+ years. Default false.
spouse_incomeNoPartner's gross yearly income in PLN, for joint taxation and spouse allowances. Default 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish this as a safe, idempotent, closed-world read, so the bar is lower, and the description still adds meaningful output disclosure: itemised tax and contribution lines with local names, effective and marginal rate, employer cost, and step-by-step workings. That is valuable because no output schema exists. It stops short of stating rounding, assumptions about default residence, or the currency of returned figures.

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 purpose is front-loaded in the opening clause and the long 'Covers:' list is dense with real content rather than filler. It is a single heavy sentence, though, and the feature enumeration could be trimmed or broken up without losing information.

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?

For a 12-parameter calculator with no output schema, the description does the important work: it spells out the return contents and the tax/relief scenarios the parameters activate. Missing are the assumptions an agent would want before trusting the number, such as residency status, rounding, and whether the euro rate affects only display amounts.

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 coverage is 100% and each parameter already carries a detailed description, including defaults, so the baseline of 3 applies. The description's rule list (30,000 zł tax-free amount, 4+ children relief, ZUS cap, 50% author costs) gives domain context that helps an agent decide which optional flags to set, but it does not add per-parameter syntax or behaviour beyond the schema.

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

Purpose4/5

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

The first clause states a precise transformation — gross yearly PLN salary to take-home pay for a Polish employee under 2026 rules — which an agent can map directly to a calculation request. It never names the inverse sibling gross_for_target_net or compare_with_netherlands, and by advertising 'employer cost' as part of the output it slightly blurs the line with employer_cost.

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?

Usage is implied by the input framing ('from a gross yearly salary'), so an agent can infer it handles gross-to-net only. There is no explicit when-to-use versus when-not guidance and no pointer to gross_for_target_net for the reverse direction or employer_cost for a cost-only view, which is a real gap given four siblings.

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