Skip to main content
Glama

Romania Salary Calculator

Net salary: Romania vs the Netherlands

compare_with_netherlands
Read-onlyIdempotent

Take-home pay of a job in Romania (with the situation options of net_salary) next to a job in the Netherlands (2026, optionally with the 8% holiday allowance and the 30% ruling), in euros, with the difference a year.

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": {
      "home_gross_annual": "<home_gross_annual>",
      "nl_gross_annual": "<nl_gross_annual>"
    },
    "name": "compare_with_netherlands"
  }
}

Input Schema

NameRequiredDescriptionDefault
ageNoAge; changes the result here (young-worker reliefs, senior slabs, surcharges). Default 35.
marriedNoMarried or registered partner. Default false.
childrenNoNumber of dependent children. Default 0.
fx_per_eurNoExchange rate: 1 euro = this many RON, for the euro amounts. Default 4.97 (indicative).
bonus_annualNoYearly bonus in RON. Default 0.
spouse_incomeNoPartner's gross yearly income in RON, for joint taxation and spouse allowances. Default 0.
kids_in_schoolNoChildren are in education. Extra deduction of 100 RON a month per child enrolled in school. Default true.
nl_gross_annualYesGross yearly salary in the Netherlands, in euros, without holiday allowance
home_gross_annualYesGross yearly salary in Romania, in RON
nl_holiday_allowanceNoThe Dutch job pays 8% holiday allowance on top. Default true.
nl_thirty_percent_rulingNoThe 30% ruling applies in the Netherlands. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description adds real behavior beyond that: the 2026 tax year being modelled, the optional 8% holiday allowance and 30% ruling on the Dutch side, and that outputs are expressed in euros with an annual difference. It says nothing about rounding, which defaults are applied when fields are omitted, or how fx_per_eur drives the conversion.

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?

One dense sentence, front-loaded with the Romania-versus-Netherlands comparison and the euro/difference output before the optional modifiers. Every clause carries information; the only cost is that the nesting of parentheses makes it slightly harder to parse on a first read.

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?

With 11 parameters, full schema coverage and no output schema, the description does enough: it identifies the tax year, the currency of the result, and the annual-difference framing, which stands in for a missing output schema. The remaining gap is modest, mainly clarification of which parameters apply to which country and how defaults are applied.

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 100%, so every parameter is already documented and the baseline is 3. The description contributes only a light structuring hint, that the Romanian side inherits 'the situation options of net_salary' and that holiday allowance and the 30% ruling belong to the Dutch side; it gives no added detail on units, defaults, or the meaning of the exchange rate parameter.

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 description names both resources (a Romanian job and a Dutch job), the computed quantity (take-home pay, the yearly difference, in euros), and the tax year 2026. It also distinguishes itself from the sibling net_salary by framing this as the two-country comparison and pointing at net_salary for the underlying situation options, so an agent can tell the two apart without opening a schema.

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 rather than stated: the tool exists for cross-country net-pay comparison and the parenthetical 'with the situation options of net_salary' hints at which knobs carry over. There is no explicit when-to-use/when-not guidance (e.g. when to use this versus running net_salary twice), so the agent must infer the selection rule.

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