Factline Vehicles

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

Annotations already disclose openWorldHint=true and idempotentHint=false; the description adds the crucial business context they do not carry: the EUR 1.95 incl. VAT cost, the payment providers (iDEAL/card via Dodo Payments), and that the payload is a payment link rather than the report itself. It could go further on whether the link is single-use or time-limited, but the concrete financial behavior is well disclosed.

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 sentences, front-loaded with the return value and cost, then the usage condition. The report-contents enumeration is long but arguably earns its place by telling the agent what the purchase actually delivers.

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, the description must explain the return value — and it does, specifying a secure payment link. The single required parameter is fully covered by the schema, so nothing needed to invoke this tool correctly is missing.

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% for the single licence_plate parameter, and its format example is already in the schema. The description adds no format, normalization, or validation detail beyond that, so the baseline of 3 is appropriate.

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 — returns a payment link for the full vehicle report — and enumerates the report contents (APK history, defects, recalls, import/taxi/export history, specs). This clearly distinguishes it from the sibling report/spec tools such as nl_vehicle_report and nl_vehicle_basic.

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?

"Only use when the user wants the full report or asks to buy it" gives explicit activation criteria, which matters for a paid tool. It stops short of naming the free/alternative sibling (e.g. nl_vehicle_report) as the fallback when the user does not want to pay.

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?

Annotations only cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds the details annotations cannot: pricing (0.001 USDC via x402 or 1 credit), the free tier of 5 paid-tool calls per day, the data source (RDW), and the shape of the returned status bands. That is exactly the auth/cost/rate context the annotations leave out.

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?

Trigger condition is front-loaded, followed by return payload, then input, then cost — a sensible ordering with no filler. Every clause (status bands, fleet polling, free tier) carries actionable information for an agent deciding whether to call.

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, the description compensates by enumerating the return fields and status bands, and it covers the payment/key path that a paid x402 tool requires. For a two-parameter, non-destructive lookup, nothing an agent needs before calling is missing.

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 both parameters are already documented in the schema, including the api_key flow. The description only restates 'Input: Dutch licence plate' and never mentions api_key, so it adds essentially nothing beyond the structured fields. Baseline 3 applies.

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 — 'when a Dutch car's APK (MOT) expires or whether it is still valid' — and enumerates the returned fields (expiry date, days left, status band, insurance and recall flags). This clearly separates it from broader siblings like nl_vehicle_report or buy_full_vehicle_report.

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 opening clause gives an explicit trigger condition ('Use when the user asks when a Dutch car's APK expires') and adds a legitimate secondary use case ('cheap enough to run daily for a fleet'). It stops short of naming alternatives or exclusions — it never says when to prefer nl_vehicle_basic or nl_vehicle_report instead.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the specific data returned (APK defect rate vs. average, top 10 defects, recalls with component and risk, open-recall share, odometer rollback share, registrations) and the ~450-model coverage scope.

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?

Front-loads 'Free' and the trigger condition before the dense data enumeration. The long list of returned fields is information-dense rather than padded, though it is packed into a single sprawling sentence.

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, the description carries the burden of describing return contents, and it does so thoroughly. For a simple two-parameter lookup tool, an agent has enough to invoke and interpret 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?

Schema description coverage is 100% and both parameters (make, model) are documented in the schema with examples. The description adds no syntax, format, or matching guidance beyond what the schema already provides, so the baseline 3 applies.

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+resource: reliability facts for a car model in the Netherlands sourced from RDW data. The 'Free' prefix implicitly distinguishes it from the paid sibling buy_full_vehicle_report, though it never names that sibling directly.

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?

Gives explicit trigger conditions ('when the user asks how reliable a car model is, or which used car to buy'), which is clear usage context. It stops short of naming when NOT to use it or pointing to a specific alternative tool.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the lookup is free of charge and the data source is RDW, plus the breadth of returned attributes including a risk level. It does not mention rate limits or auth, but that bar is low given the 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?

A single sentence, front-loaded with the 'Free.' qualifier and the trigger condition before the long but load-bearing field list. Nothing is redundant, though the enumerated return fields make it slightly dense.

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 single-parameter read-only tool with no output schema, the description compensates by listing what the response contains (APK expiry, insurance, recall, risk level) and naming the data source. An agent has enough to invoke and interpret it; only the sibling-routing detail for the paid reports is left implicit.

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?

One parameter at 100% schema description coverage, with the schema itself supplying the format example (GT-722-F). The description adds no syntax, format or normalization guidance beyond what the schema already provides, so baseline 3 applies.

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 resource (Dutch licence plate / a specific car in the Netherlands) and enumerates exactly what it returns: make, model, age, fuel, Euro class, APK expiry, insurance, open recall, odometer verdict, risk level. The leading 'Free.' implicitly separates it from the paid siblings (nl_vehicle_report, buy_full_vehicle_report), though it never names them.

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?

Gives a clear trigger condition: 'Use when the user gives a Dutch licence plate or asks about a specific car in the Netherlands.' No explicit when-not or named alternative, but 'Free.' signals the paid-report siblings without spelling out the choice.

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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds the non-obvious operational context an agent actually needs: source is RDW, cost is 0.004 USDC via x402 or 2 credits, and the first 5 paid calls per day are free with no key. It also previews the output contents, including 'the best per metric and red flags'.

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?

Trigger is front-loaded in the first clause, followed by the metric list, input, source and cost. Two sentences with no filler, though the long comma-run of metrics is dense and slightly harder to scan than a compact structure would be.

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, the description does the necessary work by enumerating the returned metrics and flagging red flags and best-per-metric. It omits failure behavior (an invalid or unknown plate among the 2-3) and result shape, which matters when several plates are supplied at once.

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 both plates and api_key are already documented with format and sourcing guidance. The description only echoes 'Input: Dutch licence plates', adding no separator or example detail beyond the schema. Baseline 3 applies since the schema carries this dimension.

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: 'plates side by side with make, model, age, APK expiry, insurance, open recall, odometer verdict...' for 2 or 3 Dutch cars. The multi-plate comparison scope cleanly separates it from the single-vehicle siblings (nl_vehicle_basic, nl_vehicle_report), so an agent can distinguish it without opening a schema.

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?

Opens with an explicit trigger: 'Use when the user is choosing between 2 or 3 Dutch used cars'. It does not name a when-not case (e.g. one plate → nl_vehicle_basic, or full dossier → buy_full_vehicle_report), leaving that routing to inference.

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?

Annotations only declare it is a safe idempotent read; the description adds genuinely new behavior: the RDW source, the English output language, the exact cost model and credit conversion, and the free-tier carve-out that removes a payment blocker. That is precisely the context an agent needs before spending money.

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?

Front-loaded with the usage trigger, then the payload contents, then input/source/cost — a sensible order with no filler sentences. The long field enumeration is dense but each item is informative; the 'in English' clause is awkwardly spliced into the list.

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, the description carries the burden of describing return content and does so thoroughly, plus source, cost and payment paths. Minor gaps: no mention of error behavior for an unknown or non-Dutch plate, and no indication of response shape or latency.

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% and both parameters are documented in the schema, including the fl_live_ format and the 'pass it right after get_trial_key' hint. The description only restates 'Input: Dutch licence plate', adding no syntax or format detail beyond the schema example GT-722-F.

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+resource ('report on a specific Dutch car or licence plate') and enumerates the returned data (APK expiry, inspection history, recalls, odometer verdict, specs, CO2, risk flags), so an agent knows exactly what it gets. It does not, however, distinguish itself from close siblings such as nl_vehicle_basic or buy_full_vehicle_report, which appear to overlap.

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?

'Use when the user asks about a specific Dutch car or licence plate, for example before buying it used' gives a clear trigger scenario. Payment routing is also spelled out (0.02 USDC via x402, 10 credits, first 5 paid calls/day free), but there is no guidance on when to prefer the cheaper/sibling variants instead.

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