Skip to main content
Glama

calculate_registreringsafgift

Calculate DANISH vehicle registration tax (registreringsafgift) for a new or used personbil, varebil or motorcykel under registreringsafgiftsloven. Same engine and validation as bildata.io's public calculator. Amounts in DKK; an estimate, not an official Motorstyrelsen valuation. A USED vehicle more than 35 years old (vehicleAgeYears over 35) is refused with error "Veteranbil": its tax follows the Danish veteran rules (registreringsafgiftsloven § 10, stk. 4), which this tool does not compute. REQUIRED PAIRS: condition="new" needs bruttovaerdi; condition="used" needs handelspris AND nypris (nypris is the used vehicle's own original price when new, not the new-vehicle price field). ALWAYS send co2 for a petrol, diesel or hybrid PERSONBIL or VAREBIL: an omitted co2 counts as 0 g/km, i.e. battery-electric, and makes the tax far too low with no error raised — zero on an ordinary car, and still only a fraction of the real figure on an expensive one. On motorcykel co2 does not select the drivetrain at all - isElectric does. Send every number as a JSON number (300000, not "300000"), use enum values exactly as listed, and OMIT an optional field you do not know rather than sending null.

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": {
      "vehicleType": "<vehicleType>",
      "condition": "<condition>"
    },
    "name": "calculate_registreringsafgift"
  }
}

Input Schema

NameRequiredDescriptionDefault
co2NoWLTP CO2 in g/km. PERSONBIL and VAREBIL: send it for any fuel-burning vehicle - an omitted value and an explicit 0 are BOTH read as battery-electric (EV phase-in and EV bundfradrag), which makes the tax far too low. Use 0 only for a pure EV. MOTORCYKEL: co2 does not select the drivetrain here; isElectric does, and a motorcykel sent with co2=0 and no isElectric is priced as fuel-burning.
aabenNoVarebil only: open cargo bed (ladvogn)
avgKmNoUsed: average odometer km of the comparable adverts. Part of the actualKm/avgKm/vehicleAgeYears set — a partial send is silently ignored.
nyprisNoUsed vehicles: REQUIRED when condition="used". The SAME vehicle's original price as new in DKK, incl. all taxes. Unused when condition="new" — for a new vehicle use bruttovaerdi.
actualKmNoUsed: actual odometer km. The km regulation is skipped entirely unless actualKm, avgKm, vehicleAgeYears AND handelspris are all present.
conditionYesnew = first registration of a new vehicle; used = import/revaluation of a used vehicle
elForbrugNoElectric consumption in Wh/km. Send WITH elRaekkevidde — the battery deduction is (elForbrug/1000) * elRaekkevidde, so either one alone is a no-op.
isElectricNoMOTORCYKEL: the EV switch for that vehicle type. For personbil and varebil the drivetrain comes from co2 (0 or absent = electric), so this flag does not change the tax — but DO send it for a battery-electric personbil or varebil: it is read as your declaration that the missing co2 is deliberate, and suppresses the warning that the answer looks too low.
targetYearNoRules year to calculate under (default: current). A year with no published table silently falls back to the current rates; the answer's rules_year says which table actually applied.
totalvaegtNoVarebil only: total weight in kg
handelsprisNoUsed vehicles: REQUIRED when condition="used". Current Danish trade price in DKK, incl. registration tax. Unused when condition="new".
vehicleTypeYesVehicle category under Danish law
bruttovaerdiNoNew vehicles: REQUIRED when condition="new" (unused when condition="used"). Taxable value in DKK, i.e. price incl. VAT and margin BEFORE registration tax. NOT the advertised Danish showroom price, which already contains the tax being calculated.
elRaekkeviddeNoElectric range in km (WLTP). Send WITH elForbrug — either one alone is a no-op.
condition_standNoUsed: maintenance condition (vedligeholdelsesstand)
vehicleAgeYearsNoUsed: vehicle age in years since first registration. Also used on its own for the under-6-months rule, so send it even when you cannot supply the km set. The km regulation additionally needs actualKm, avgKm and handelspris — that part is skipped unless all are present.
allDealerListingsNoUsed: true only if EVERY comparable advert is a dealer listing (enables annoncefradrag + leveringsomkostninger)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed1 schema field changed
    • changedInput schema / properties / co2 / description
      Previous value: -"WLTP CO2 in g/km. Send it for ANY fuel-burning vehicle: an omitted value and an explicit 0 are BOTH read as battery-electric (EV phase-in and EV bundfradrag), which makes the tax far too low. Use 0 only for a pure EV."New value: +"WLTP CO2 in g/km. PERSONBIL and VAREBIL: send it for any fuel-burning vehicle - an omitted value and an explicit 0 are BOTH read as battery-electric (EV phase-in and EV bundfradrag), which makes the tax far too low. Use 0 only for a pure EV. MOTORCYKEL: co2 does not select the drivetrain here; isElectric does, and a motorcykel sent with co2=0 and no isElectric is priced as fuel-burning."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden, and it does substantial work: it discloses a hard refusal branch with the exact error string, silent-fallback behavior for targetYear, silent ignoring of partial km sets, and that the result is an estimate rather than an official valuation. It stops short of describing response shape or units beyond DKK, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is high-value but the layout is dense and partly redundant: co2 omission is explained at length in the description and again in the schema, and required-pair rules appear in both prose and per-field descriptions. Front-loading the purpose and the veteranbil refusal works, but the middle sentences pack multiple distinct rules into single run-ons.

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 17-parameter tax calculator with no output schema, the description covers refusal paths, silent-failure modes and required pairings, which is nearly everything needed to call it correctly. Missing is any hint of the answer's structure or how rules_year comes back, so an agent cannot anticipate the response.

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 already 100%, so this is above baseline: the description adds cross-parameter semantics the schema can't express, notably the required pairs per condition, that nypris is the used vehicle's own original price rather than the new-vehicle field, and the co2/isElectric interaction on motorcykel versus personbil.

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?

States a specific verb+resource (calculate Danish vehicle registration tax) and scopes it by vehicle type, legal basis (registreringsafgiftsloven) and by new/used. It also distinguishes itself from the sibling forecast tool by noting it uses the same engine and validation as the public calculator.

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?

Gives explicit conditional routing: which field pairs are required per condition, which vehicle type is refused (veteranbil over 35 years), and the co2 caveat that silently understates tax. It also tells the agent to send enum values exactly and to omit unknown optional fields rather than sending null.

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