Skip to main content
Glama
dk-tax
by mikaelbdj

estimate_payslip

Estimate Danish take-home pay for normal and bonus months, skattekort trækprocent, månedsfradrag, and year-end restskat from salary, bonus, and shares (2026 onward).

Instructions

Predict the skattekort (trækprocent, månedsfradrag) and what is actually paid out in a normal month and in the bonus month, plus the year-end restskat, from 2026 onwards.

Use this for questions about monthly take-home pay or what to enter in the
forskudsopgørelse. One scenario per call: the include_*_in_forskud flags say whether the
bonus and the shares are entered in the forskudsopgørelse; call twice to compare.
monthly_salary: DKK per month INCLUDING the employee's own pension share.
pension_*_pct: percent of monthly_salary (e.g. 4 and 8).
bonus: the year's total bonus in DKK, paid in bonus_payments equal parts (4 = quarterly). share_compensation: the year's RSU vest value in DKK.
  Shares are B-income: the employer withholds nothing, so if they are left out of the
  forskudsopgørelse the tax comes as restskat (year_end.restskat > 0); paying it
  voluntarily before 31 December avoids interest.
share_withholding: "none" = shares are B-income, nothing withheld (skat.dk's general rule);
  "traekprocent" = the employer keeps back shares to cover the tax at the skattekort's
  percentage (withhold-to-cover, common in private companies); "fixed" = at
  share_withholding_rate percent. Ask the employer which applies; see share_vest.
Cite the sources with the income year and flag any figure that is not 'verified'.
Assumptions are listed in dk_tax.calc.payslip. Not tax advice.

Input Schema

NameRequiredDescriptionDefault
yearYes
bonusNo
kommuneYes
atp_full_timeNo
bonus_paymentsNo
monthly_salaryYes
vests_per_yearNo
pension_own_pctNo
other_deductionsNo
bonus_has_pensionNo
folkekirke_memberYes
share_withholdingNonone
net_capital_incomeNo
share_compensationNo
pension_employer_pctNo
share_withholding_rateNo
include_bonus_in_forskudNo
include_shares_in_forskudNo
within_15_years_of_pensionNo

Output Schema

NameRequiredDescriptionDefault
kommuneYes
payslipYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it explains that shares are B-income with nothing withheld, the resulting restskat and the 31 December voluntary-payment interest consequence, the three withholding models, that assumptions live in dk_tax.calc.payslip, and that it is not tax advice. It does not explicitly state that the call is side-effect-free (an estimate), though the verb and output framing imply it.

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?

Purpose and usage lead, then a compact semi-colon separated parameter glossary; dense but nearly every clause carries tax-domain information an agent could not infer. Minor waste: the pointer 'see share_vest' references a tool that is not among the listed siblings, which adds ambiguity rather than clarity.

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?

Output schema exists, so return values need not be described, and the assumptions pointer plus the 'cite sources with income year / flag unverified' instruction are valuable. Against 19 parameters and 0% schema coverage, however, roughly half the inputs remain opaque, and the relationship to estimate_salary_tax is never resolved.

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 0% across 19 parameters, so the description must compensate. It does explain the highest-risk ones well (monthly_salary includes the employee's own pension share; pension_*_pct is a percentage of monthly_salary; bonus spread over bonus_payments; the share_withholding enum values), but leaves kommune, folkekirke_member, atp_full_time, other_deductions, bonus_has_pension, net_capital_income, vests_per_year, share_withholding_rate and within_15_years_of_pension entirely unexplained in both schema and prose.

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?

States a specific verb and a well-defined output set: predicts skattekort (trækprocent, månedsfradrag), normal-month and bonus-month payout, and year-end restskat from 2026 onwards. That is far more specific than the name alone. It does not, however, distinguish itself from the sibling estimate_salary_tax, which an agent could plausibly confuse with this tool.

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?

Gives a clear use context ('questions about monthly take-home pay or what to enter in the forskudsopgørelse') and an operational rule: one scenario per call, call twice to compare when the include_*_in_forskud flags differ. Missing an explicit when-not / use-estimate_salary_tax-instead statement against the sibling tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.