Skip to main content
Glama

United States Salary Calculator

Net salary: United States vs the Netherlands

compare_with_netherlands
Read-onlyIdempotent

Take-home pay of a job in United States (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.
hsaNoHSA contribution. Health Savings Account, 2026 limit $4,400 self-only, $8,750 family. Free of income tax and FICA through payroll. ($ / year). Default 0.
stateNoState: none = No state income tax (TX, FL, NV, TN, SD, WY, AK, NH); CA = California; NY = New York (outside NYC); NYC = New York City; IL = Illinois (4.95% flat); MA = Massachusetts (5%, 9% above $1.08M); PA = Pennsylvania (3.07% flat); NJ = New Jersey; CO = Colorado (4.4% flat); NC = North Carolina (3.99% flat); GA = Georgia (4.99% flat); AZ = Arizona (2.5% flat); WA = Washington (no income tax, WA Cares + PFML). Default none.
filingNoFiling status (unmarried). Married people file jointly here; switch on "Married" above.: single = Single; hoh = Head of household (with a qualifying child). Default single.
pretaxNoOther pre-tax deductions. Employee share of health premiums, FSA, commuter benefits (section 125): free of income tax and FICA. ($ / year). Default 0.
marriedNoMarried or registered partner. Default false.
childrenNoNumber of dependent children. Default 0.
fx_per_eurNoExchange rate: 1 euro = this many USD, for the euro amounts. Default 1.08 (indicative).
pension_pctNoVoluntary employee pension contribution through payroll, % of salary. Default 0.
bonus_annualNoYearly bonus in USD. Default 0.
spouse_incomeNoPartner's gross yearly income in USD, for joint taxation and spouse allowances. Default 0.
nl_gross_annualYesGross yearly salary in the Netherlands, in euros, without holiday allowance
home_gross_annualYesGross yearly salary in United States, in USD
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

B3.4/5.0
Behavior3/5

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

Annotations already establish the safety profile: readOnlyHint, idempotentHint, non-destructive, and closed-world. The description adds genuine context beyond that — the 2026 tax year, that amounts are reported in euros, that Dutch holiday allowance and the 30% ruling are optional inputs, and that the result is an annual difference. It still says nothing about how the per-country breakdown is presented or whether the exchange rate distorts the comparison, so it goes beyond annotations but not far.

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 sentence, front-loaded on the outcome, with the currency and the comparison metric placed early. The nested parentheticals ('with the situation options of net_salary', '2026, optionally with...') make it denser than necessary, but no sentence is wasted.

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?

With 15 parameters and no output schema, the description does the minimum: it names the two required salaries, the currency convention and the headline output. It leaves open what the response actually contains (per-country net figures, the delta, effective rates) and how the fx_per_eur default affects the euro amounts. Adequate but thin for a tool of this complexity.

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 one of the 15 parameters is already documented in the schema with defaults, ranges and enum meanings. The description only echoes the holiday allowance and 30% ruling options and refers the reader to net_salary for the shared situation parameters. That is baseline-level value, appropriate for a fully annotated 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 description states a concrete outcome: take-home pay for a US job beside a Dutch job, expressed in euros, with the annual difference. That is a specific verb-plus-resource framing that an agent can distinguish from net_salary (single country) and employer_cost. Sibling differentiation is implicit rather than spelled out, which keeps it short of a 5.

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 comparison framing — an agent can infer this is the tool for cross-country US/NL net pay. However, there is no explicit when-to-use statement, no when-not-to-use, and no direct pointer telling the agent to use net_salary for single-country questions. The reference to 'the situation options of net_salary' hints at shared parameters but does not route the agent.

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