Skip to main content
Glama

bildata

by io.bildata
OverviewDiscussionsAdmin

forecast_registreringsafgift

Project DANISH registration tax for a NEW vehicle across rules-years 2026–2029 (the EV/plug-in phase-in schedule changes the tax each year). Returns per-year results and deltas vs 2026. Amounts in DKK. Estimates, not official valuations. NEW vehicles only, and always the whole 2026-2029 span: for a USED import, or for a single year, use calculate_registreringsafgift instead. Send every number as a JSON number (300000, not "300000").

Input Schema

TableJSON 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 behaves differently on THIS tool: an explicit co2=0 counts as electric, but an OMITTED co2 does NOT - the bike is priced as fuel-burning and the tax comes out far too HIGH. Declare an electric motorcykel with isElectric=true.
aabenNoVarebil only: open cargo bed (ladvogn)
nyprisYesPrice as new in DKK (taxable value)
isElectricNoMOTORCYKEL: the EV switch for that vehicle type, and on this tool the only reliable way to declare one - leave it unset with co2 omitted and the bike is priced as fuel-burning. For personbil and varebil the drivetrain comes from co2 (0 or absent = electric), so this flag does not change the tax.
totalvaegtNoVarebil only: total weight in kg
vehicleTypeYesVehicle category under Danish law
electricRangeNoElectric range km
batteryCapacityNoBattery kWh (used with electricRange to derive Wh/km)
electricConsumptionNoElectric consumption Wh/km (overrides battery/range derivation)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / aaben / description
      Added value: +"Varebil only: open cargo bed (ladvogn)"
    • changedInput schema / properties / co2 / description
      Previous value: -"WLTP CO2 g/km (0 for EVs)"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 behaves differently on THIS tool: an explicit co2=0 counts as electric, but an OMITTED co2 does NOT - the bike is priced as fuel-burning and the tax comes out far too HIGH. Declare an electric motorcykel with isElectric=true."
    • addedInput schema / properties / isElectric / description
      Added value: +"MOTORCYKEL: the EV switch for that vehicle type, and on this tool the only reliable way to declare one - leave it unset with co2 omitted and the bike is priced as fuel-burning. For personbil and varebil the drivetrain comes from co2 (0 or absent = electric), so this flag does not change the tax."
    • addedInput schema / properties / totalvaegt / description
      Added value: +"Varebil only: total weight in kg"
    • addedInput schema / properties / vehicleType / description
      Added value: +"Vehicle category under Danish law"
  2. First observed

TDQS

A4.4/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 behavioral burden. It discloses that results are per-year with deltas vs 2026, amounts are in DKK, outputs are estimates rather than official valuations, and that the tool always returns the full span. This is strong, though it could go further on response structure or edge-case behavior.

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

Conciseness5/5

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

Every sentence earns its place: purpose, reason for multi-year scope, return shape, currency, estimate caveat, usage exclusion, and serialization requirement. Information is front-loaded and nothing is redundant.

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 complex 9-parameter tool with no output schema, the description covers the essential operational context: scope, return content, currency, estimate status, and when to use a sibling. It could be slightly more specific about the exact shape of the returned per-year results/deltas, but it is otherwise complete enough to call correctly.

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 the schema already documents each parameter in detail, including type-specific caveats. The tool description adds the cross-cutting instruction that numbers must be sent as JSON numbers, but it does not add per-parameter meaning beyond the schema.

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 states a specific operation ('Project DANISH registration tax') on a specific resource ('a NEW vehicle') with a clear time scope (2026–2029). It also explicitly distinguishes itself from the sibling calculate_registreringsafgift by naming when that alternative applies.

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?

The description provides explicit when-to-use guidance: NEW vehicles and the whole 2026–2029 span. It also names the exact alternative for excluded cases: 'for a USED import, or for a single year, use calculate_registreringsafgift instead.' This leaves no ambiguity.

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

All bildata toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources