Living in the Netherlands

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile needs no restating. The description adds genuine behavioral context: the data source is live RDW Open Data, one input unlocks the extra bijtelling block, and the electric rate is locked for 60 months from first registration.

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?

One dense paragraph, front-loaded with the core lookup before the conditional bijtelling behaviour and the data-source note. The field enumeration is a long list but each item is a distinct return value, so little is wasted.

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 correctly carries the return-value burden by enumerating the fields produced. Only gaps are failure behaviour for an unknown plate and whether partial or missing RDW records are possible.

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 the baseline is 3. The description nevertheless adds meaning beyond the schema: it explains the causal effect of supplying taxable_income and the 2026/60-month rule attached to it, and confirms plate accepts the dashed or undashed kenteken form.

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 (lookup Dutch-registered car by kenteken) and enumerates the exact fields returned, including APK due date, insured status, and conditional bijtelling. An agent knows precisely what this does and what comes back without opening anything else.

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 makes clear this is a per-plate RDW registry lookup and that taxable_income is only needed when company car tax is wanted, which is actionable usage context. It does not name exclusions or point to alternatives, though the sibling tools (budget, facts, rent points) are unrelated domains so there is little routing 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioural context beyond that: the modelled assumptions (unregulated-sector rent, typical energy bill, healthcare allowance netting) and an explicit exclusion list — food, transport, internet and water board charges are omitted.

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 outcome ('what is left each month'), followed by the formula and the fallback/exclusion caveats. Dense but every clause carries information; only minor cost is that the middle formula sentence is long.

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?

There is no output schema, so the description carries the burden of explaining the return value — it never says whether the result is a single euro figure or an itemised breakdown (net pay, rent, insurance, energy, municipal charges). Given the tool's computational richness, that omission leaves a real gap even though the inputs are fully documented.

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 the baseline is 3. The description nonetheless adds meaning: it clarifies that rent is derived from home size while monthly_rent can override it, that health insurance scales per adult, and that the 30% ruling and holiday allowance are optional inputs to the net-salary calculation rather than fixed assumptions.

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 computation (monthly leftover) with an enumerated formula: net salary minus rent, health insurance, energy and municipal charges. The scope (Dutch city, renter, 2026 tax) is precise enough that an agent can tell immediately this is a budget calculator, not a rent lookup or a general facts tool.

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 city-handling rule (ten named cities have own figures; anything else falls back to national average and drops municipal charges) is effectively usage guidance for choosing the city parameter. But there is no explicit statement of when to call this versus the sibling rent_points_check, or for which user questions it is and is not appropriate.

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, closed-world and non-destructive, so safety is covered. The description adds genuinely new behavioral context: results carry the applicable period and an official source, and the year (2026) signals freshness — important since there is no output schema to convey this.

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?

Purpose and freshness rationale come first, then the topic inventory, then the sibling routing rule — a sensible front-loaded order. The topic list is long but earns its place by acting as the human-readable key to the enum; the only slight redundancy is repeating the question-fallback rule already in the schema.

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 describing the return content (amount + period + source), and it clarifies that both parameters are optional alternatives. Nothing critical is missing, though it does not say what happens if topic and question conflict or if a question matches no topic.

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, but the description goes further by pairing each enum value with a plain-language label (e.g. health_deductible → eigen risico, ind_fees → residence permits and naturalisation), which the raw enum does not provide. It also restates the topic-vs-question precedence, though that is already in 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 names a specific resource (current Dutch yearly figures), states the payload shape (amount, applicable period, official source), and enumerates all six topics with human-readable labels. It also separates itself from the tax-figures tool, so an agent can place it among its siblings without opening the 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?

It gives two concrete calling modes ('Ask by topic, or with a short question') and explicitly routes income-tax questions to dutch_tax_figures on the tax server. There is no explicit statement of what this tool should not be used for beyond tax, so it stops short of a full when/when-not map.

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 cover read-only, idempotent, closed-world, non-destructive, so the bar is lower. The description still adds substantive domain behavior: the 2026 reference year, the concrete sector thresholds (143 / 186 points), the fact that increase caps are sector-dependent, and the upstream data source. It omits how proposed_increase_pct is evaluated and what happens when current_rent is absent.

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 front-loaded sentence that leads with the applicable scope before the computation, with the exclusion clause placed at the end where it belongs. It is dense with parentheticals (Dutch terms, thresholds) but every clause carries information; no filler.

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?

There is no output schema, and the description compensates by enumerating the return values (sector, legal max basic rent, above-max flag, max yearly increase). Combined with annotations and full schema coverage this is close to complete; only the treatment of the optional proposed_increase_pct and missing current_rent remains unspecified.

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 reinforces that points come from the Huurprijscheck and that rent means kale huur without service costs, and it explains the threshold logic that gives the points parameter meaning, but it does not add syntax or format detail 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?

Names a specific computation (legal maximum rent and allowed increase) on a specific resource (Dutch rent points / WWS for an independent home), and enumerates the concrete outputs: sector, legal max basic rent 2026, whether current rent exceeds it, max yearly increase. Nothing in the sibling set (car_by_plate, monthly_budget_by_city, nl_current_facts) overlaps, so an agent can route unambiguously.

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 clear applicability scope: rented independent home with own front door, kitchen and toilet, and explicitly excludes rooms (onzelfstandige woonruimte) which use a different table. It also tells the agent where the points input must come from (Huurprijscheck on huurcommissie.nl). It does not name a competing tool or state a triggering user intent, so it falls short of a 5.

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