Skip to main content
Glama

JobCrawls

Calculate net salary in Finland (gross to net, employer cost)

calculate_net_salary_finland
Read-onlyIdempotent

Gross-to-net salary calculator for Finland, from the JobCrawls tax iceberg calculator. Example queries: "what is 4000 gross net in Finland", "paljonko jää käteen 4200 euron bruttopalkasta Helsingissä", "vad blir nettolönen på 3800 brutto i Helsingfors". Inputs: a gross salary (EUR per month by default, or per year), or a target net to solve the gross it takes, and optionally the municipality, employer size, age, dependent children, commuting costs and investment income. Church membership and union fees are not inputs. The linked page is in the language detected from "municipality" when locale is omitted, else English, or in the given locale. Returns monthly and annual breakdowns: employee pension and unemployment contributions, state, municipal, church and Yle taxes, net pay, employer contributions and the true cost of employment, plus the effective tax rate, the assumptions used and a link to the same scenario on jobcrawls.com. Uses the current tax year's official Finnish parameters; an estimate, not tax advice. Reuse: figures may be quoted with a visible link to the jobcrawls.com page in the result (or "JobCrawls (jobcrawls.com)" where a link is impossible); each result repeats this in dataUse.

Input Schema

NameRequiredDescriptionDefault
ageNoAge in years, affects pension and unemployment contributions.
netNoTarget net pay in euros (same period): the tool solves the gross salary that leaves this in hand. Either gross or net is required.
grossNoGross salary in euros, per month unless period is "year". Either gross or net is required.
localeNoLanguage of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), including when job titles or place names in it are English. Language of the result notes, the inline card and the linked page. When omitted, detected from "municipality" if it is given in Finnish or Swedish form; otherwise defaults to en.
periodNoPeriod of every money amount given. Default month.
dividendsNoListed-company dividends in the same period (capital income).
includeVatNoAlso subtract the VAT paid when the net is spent (an estimate). Default false.
capitalGainsNoCapital gains net of acquisition cost in the same period.
employerSizeNoEmployer payroll size for the unemployment-insurance rate (large = payroll above about EUR 2.5 million). Omit for a blended average.
municipalityNoFinnish municipality, by its Finnish or Swedish name, e.g. "Helsinki", "Helsingfors" or "Espoo". Omit for the national-average municipal tax rate.
commutingCostsNoCommuting costs in the same period; deductible above the own-liability share, capped.
isSoleGuardianNoSingle parent with dependent children (child deduction).
dependentChildrenNoNumber of dependent children, affects the child tax deduction.
unlistedDividendsNoDividends from the person's own unlisted company in the same period (8% yield rule).
unlistedNetAssetsNoMathematical value of the person's shares in that company, EUR (a stock, not per period).

Output Schema

NameRequiredDescriptionDefault
inputYesThe inputs the calculation used, after defaults.
ratesYes
annualYesBreakdown per year, EUR.
localeYes
methodYes
monthlyYesBreakdown per month, EUR.
pageUrlYesThe same scenario on jobcrawls.com, where church tax and union fees can be set privately.
taxYearYes
currencyYes
assumptionsYes
investmentsYesCapital income breakdown, or null when no investment income was given.
destinationsYesWhere the taxes and contributions go, EUR per year.
icebergSvgUrlYesImage illustrating the breakdown.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / municipality / description
      Previous value: -"Finnish municipality name, e.g. \"Helsinki\" or \"Espoo\". Omit for the national-average municipal tax rate."New value: +"Finnish municipality, by its Finnish or Swedish name, e.g. \"Helsinki\", \"Helsingfors\" or \"Espoo\". Omit for the national-average municipal tax rate."
  2. Changed3 schema fields changed
    • changedInput schema / properties / gross / description
      Previous value: -"Gross salary in euros, per month unless period is \"year\". Give either gross or net."New value: +"Gross salary in euros, per month unless period is \"year\". Either gross or net is required."
    • changedInput schema / properties / locale / description
      Previous value: -"Set this to the language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), even when the job titles or place names in it are English. Language of the result notes, the inline card and the linked page. When omitted, detected from \"municipality\" if it is given in Finnish or Swedish form; otherwise defaults to en."New value: +"Language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), including when job titles or place names in it are English. Language of the result notes, the inline card and the linked page. When omitted, detected from \"municipality\" if it is given in Finnish or Swedish form; otherwise defaults to en."
    • changedInput schema / properties / net / description
      Previous value: -"Target net pay in euros (same period): the tool solves the gross salary that leaves this in hand. Give either gross or net."New value: +"Target net pay in euros (same period): the tool solves the gross salary that leaves this in hand. Either gross or net is required."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses the estimate caveat ('an estimate, not tax advice'), that parameters are the current tax year's official figures, the return contents (breakdowns, assumptions), and reuse/licensing terms repeated in dataUse.

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?

Front-loaded with purpose, then examples, inputs, outputs, and terms in a logical order. It is long but dense, and the length is justified by 15 parameters and a licensing requirement; a few clauses (e.g. the reuse sentence) could be tightened.

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 complex 15-parameter calculator with an output schema, the description covers purpose, inputs, defaults, return contents, assumptions, and legal reuse terms. Nothing an agent needs to invoke it correctly is missing.

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 and the schema carries most burden. The description still adds meaning: it summarizes the key inputs, flags the per-month-by-default or per-year period behavior, and explicitly states what is NOT an input (church membership, union fees), which the schema cannot express.

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+resource ('Gross-to-net salary calculator for Finland') and immediately scopes the domain, so an agent can distinguish it from the sibling job-search tools without any schema inspection. Example queries reinforce the exact intent in three languages.

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?

It gives concrete example queries and clarifies that the tool accepts a gross salary OR a target net to solve for gross, which is clear usage context. It also notes scope exclusions ('church membership and union fees are not inputs'), but it never explicitly states when to avoid the tool or name an 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