bildata

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses that omitted co2 silently reads as battery-electric and produces an implausibly low tax with no error, that motorcykel co2 does not select drivetrain, and that the result is an estimate, not an official Motorstyrelsen valuation.

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

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

The description is dense but every sentence earns its place, with critical requirements front-loaded and clearly labeled via REQUIRED PAIRS and ALWAYS. Uppercase callouts and short clauses make the long text scannable without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 17 parameters, conditional dependencies, and no annotations or output schema, the description is remarkably complete for safe invocation. It covers all significant cross-field requirements and silent failure modes; the expected result is clear from the tool name and the statement that amounts are in DKK.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds cross-parameter semantics that the schema does not: required condition/price pairs, the meaning of nypris as the used vehicle's own original new price, the severe co2 pitfall, and the rule to send numbers as JSON numbers and omit unknown fields rather than sending null.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action and resource: calculate Danish registration tax for personbil, varebil, or motorcykel under registreringsafgiftsloven. It does not explicitly name or contrast sibling tools like forecast_registreringsafgift, but the scope is precise enough that an agent can distinguish it from rate-lookup and market-stat tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong operational guidance: required pairs for new vs. used, mandatory co2 for fuel-burning personbiler/varebiler, motorcykel drivetrain selection, JSON number formatting, and omitting unknown optional fields. It does not explicitly state when to prefer forecast_registreringsafgift or other siblings, so it misses the when-not-to-use alternative.

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

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.

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.

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.

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.

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.

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.

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It usefully discloses machine-readability, the 2026–2029 range, and that 2027–2029 rates are provisional. However, it does not describe the response format, update cadence, or any access considerations, though the operation is clearly a simple read.

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

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

Two dense sentences with no filler. The core content is front-loaded, the API equivalence is a useful single clause, and the provisional-data caveat is included without extra wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only rates endpoint, the description is nearly complete: it identifies the data domain, years, categories, and provisional status. The absence of an output schema means the description could have specified the exact return shape, but 'machine-readable' plus the field list is adequate for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters and the input schema is empty, so the baseline is 4. The description adds meaningful context by describing the payload of returned data (brackets, tiers, percentages) even though no parameters need explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource ('Danish vehicle registration tax rates'), defines the scope ('2026–2029'), and enumerates the contained data categories (brackets, CO2 tiers, bundfradrag, EV phase-in). This clearly differentiates it from calculation, forecasting, and market/model stats siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied through the resource type: it is the raw rates dataset, as opposed to calculate_registreringsafgift or forecast_registreringsafgift. However, the description never explicitly says 'use this when you need raw rates' or names alternatives, so the agent must infer usage from context.

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

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

With no annotations, the description carries full behavioral burden and meets it: it discloses weekly DMR data source, as_of cutoff semantics with PARTIAL months, top-20 brand limitation, no per-model breakdown, and default kind=all. It also surfaces truncation behavior in the sibling tool, preventing misinterpretation. No annotation contradiction.

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

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

Dense but well-organized; the core purpose is front-loaded, and each subsequent sentence adds a necessary caveat or usage rule. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter stats tool with no annotations or output schema, the description covers data source, parameter semantics, defaults, partial-data behavior, and boundary conditions with sibling tools. An agent has everything needed to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds real meaning: kind=all vs Personbil is defined, and each dimension enum value receives context (e.g., brands top 20, monthly_totals last 12 months incl. leasing). It goes well beyond the schema's 'Which slice to return.'

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete resource: Danish new-vehicle registration statistics from bildata.io, and lists the available dimensions. It also explicitly distinguishes itself from get_model_stats by noting this is market-level only, so an agent can select it correctly among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit routing guidance: 'for a named MODEL use get_model_stats' and warns it is NOT a way to get a brand total outside top 20, explaining the sibling's default and truncation behavior. This gives both when-to-use and when-not-to-use guidance.

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

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

Although no annotations are provided, the description thoroughly discloses behavior: it differentiates active vs. inactive models, explains that absent period figures are missing data 'NOT zero sales', states that results appear in unavailableFields, and warns that spelling is forgiving and the response indicates how it matched. It even instructs the agent to verify the name field before quoting numbers. This is exceptional transparency for a tool with zero annotations.

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

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

Every sentence earns its place: purpose and scope first, then routing guidance, then return behavior for both active and inactive models, then matching/verification caveats. It is long but information-dense with no repetition or filler. The critical edge-case semantics are clearly front-loaded near the relevant behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description carries the full burden and succeeds. It explains what figures are returned for active models, what an inactive model returns, how missing data is represented, and how matching works. It gives an agent enough to select, invoke, and interpret the tool's response correctly, including a caution to verify the matched name.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful value beyond the schema by explaining query semantics: examples of valid queries, forgiving spelling normalization ('ID.4 = ID 4 = id4'), and the need to verify the returned name. It does not elaborate on kind, limit, or grouped, but the schema already covers those fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Look up Danish registration numbers for a SPECIFIC car model by name'. It gives concrete examples and explicit scope ('Covers every model since 2018'), and distinguishes itself from get_top_models and get_market_stats. An agent can immediately tell what this tool does and how it differs from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it: 'Use this when the question names a model or brand'. It also states alternatives and why they are not suitable: get_top_models covers only top sellers of one month and get_market_stats only top 20 brands. No ambiguity about routing.

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

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

With no annotations, the description carries full burden and meets it: it discloses partial-month cutoff semantics, 12-month rolling-window bounds, ranking nature, and absence behavior. It also notes rolloff behavior for older months across all tools, which is valuable operational context.

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

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

The description is dense and front-loaded with its core purpose in the first sentence, and every sentence contributes. It is a bit longer than necessary and repeats the 12-month-window idea, so it narrowly misses a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter list tool with no annotations and no output schema, the description covers source, scope, ranking, window bounds, partial-month behavior, default behavior, and cross-tool routing. Nothing critical is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description adds meaning by explaining that the month is a data cutoff with partial-month consequences and by confirming default limit/top-10 behavior. It slightly confuses by using the term 'as_of' for the 'month' parameter, which is the only notable gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Top-selling car models (and variants) in Denmark for a given month' from bildata.io's monthly top-50 passenger-car statistics. It also names the sibling it is not, saying a model outside the top 50 must be handled by get_model_stats, so an agent can disambiguate immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states default usage ('Default: latest month, top 10'), gives an alternative for out-of-top-50 lookups ('look that one up by name with get_model_stats'), and rules out arbitrary past months ('A month OLDER than the window cannot be answered by any tool on this server'). This is explicit when-to-use and when-not-to-use guidance.

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