Skip to main content
Glama

finwire.pl - Polish financial data

Take-home pay in Poland for any form of work

calc_net_income
Read-onlyIdempotent

Use for take-home pay from an employment, mandate or work contract or B2B self-employment. Give the inputs and the assumptions with the result. The result is a calculation from statutory rates. It is not advice. Monthly take-home pay in Poland from: employment contract (uop: umowa o pracę, standard costs, PIT-2 filed, no reliefs), mandate contract (zlecenie: ZUS, health, 20% costs, PIT-2), contract for specific work (dzielo: no ZUS, 20% costs) or B2B self-employment of a sole proprietor (b2b: tax scale, flat 19% tax or lump-sum ryczałt on revenue, chosen ZUS scheme). Returns social security (ZUS), health contribution, income tax, net, yearly totals, effective rate and, for uop and zlecenie, the cost to the payer. Rates of the Polish tax year, switching on 1 January. For one person choosing between business forms use compare_business_forms.

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": {
      "form": "<form>",
      "monthly_amount": "<monthly_amount>"
    },
    "name": "calc_net_income"
  }
}

Input Schema

NameRequiredDescriptionDefault
ppkNouop: employee saves in PPK (workplace pension), default false.
taxNob2b: tax form, default liniowy (flat 19%).
zusNob2b: social security scheme, default pelny (full).
formYesForm of work: uop employment, zlecenie mandate, dzielo specific work, b2b self-employment.
yearNoPolish tax year; default the current one.
lump_sum_rateNob2b ryczalt: rate in percent for the activity, e.g. 12 for IT services.
monthly_costsNob2b: monthly business costs, PLN net.
monthly_amountYesPLN per month: gross pay (uop, zlecenie), contract amount (dzielo) or net revenue without VAT (b2b).
student_under_26Nozlecenie: pupil or student under 26 (no ZUS, no PIT).

Output Schema

NameRequiredDescriptionDefault
urlYes
asOfNo
dataNo
titleYes
sourceYes
docsUrlYes
licenseYes
summaryYes
citationYes
datasetIdYes
sourceUrlNo
truncatedNo
serverDateYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / form / description
      Added value: +"Form of work: uop employment, zlecenie mandate, dzielo specific work, b2b self-employment."
  2. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real context: the result is derived from statutory rates, it is explicitly not advice, assumptions must accompany the result, and rates switch on 1 January of the Polish tax year.

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 first clause and the long form enumeration is dense rather than padded. Minor waste remains in re-listing the returned fields, which the output schema already covers, and the Polish-term glossary is bulky though useful for term mapping.

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 9-parameter calculator with full schema coverage, an output schema and rich annotations, the definition covers the assumptions and the statutory basis that an agent needs. It need not explain return fields further, and the only soft gap is that it does not spell out what changes when year is omitted beyond the default.

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, but the description adds genuine meaning by disclosing the baked-in assumptions per form (uop: standard costs, PIT-2 filed, no reliefs; zlecenie: 20% costs; dzielo: no ZUS; b2b: tax scale/flat/lump-sum with chosen ZUS scheme). Those assumptions are not in the schema and affect how the agent frames the call.

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 opening sentence names a specific resource (take-home pay / net income in Poland) and enumerates the exact four work forms it handles (uop, zlecenie, dzielo, b2b). This separates it cleanly from calc_zus_contributions and calc_employer_cost, which cover only slices of the same domain.

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 states when to use it (take-home pay for any of the four forms) and explicitly routes the comparison case elsewhere: "For one person choosing between business forms use compare_business_forms." The per-form parentheticals also tell the agent which inputs apply to which scenario.

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.