NL Tax Calculator

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

The annotations already declare a safe read-only, idempotent, non-destructive calculation, so the description appropriately focuses on adding calculation context. It discloses the accrual formula, the relevant 50-year period, and that results include gross and net monthly amounts plus holiday allowance. It stops short of stating assumptions such as the exact AOW age or full AOW amount used.

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 a single dense sentence with no wasted words. It is front-loaded with the resource and date, then moves into eligibility, formula, and output components in a logical order.

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 simple two-parameter calculator with annotations and no output schema, the description is largely complete: it names the outputs as gross and net monthly amounts plus holiday allowance and explains the accrual basis. Minor assumptions such as the exact AOW age and full AOW reference amount are 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?

Schema coverage is 100%, so the schema already documents both parameters, including the enum and default for living_situation. The description adds value by explaining how insured_years drives the calculation through the 2%-of-full-AOW-per-year formula, giving the parameter meaning beyond the schema text.

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 identifies a specific resource and scope: Dutch AOW state pension from 1 July 2026 for single or partner situations, with the 2%-per-insured-year formula and monthly gross/net plus holiday allowance outputs. It is clearly distinct from sibling pension tools such as pension_annuity_room_jaarruimte, though it does not use an explicit verb like 'calculate'.

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?

Usage is implied by the stated date, living-situation scope, and AOW formula, so an agent can infer this is for estimating AOW pension amounts. However, it does not explicitly say when to choose this tool over sibling benefit or pension calculators, nor does it name alternatives or exclusions.

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 establish read-only, idempotent, non-destructive, closed-world behavior. The description adds useful behavioral context beyond that: it explains that the calculation covers only the resident period and includes partial-year tax credits and monthly net pay during that period.

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 a single, front-loaded sentence that immediately names the scenario and then lists the relevant outputs. Every clause earns its place by specifying either the tax context or a return component.

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 carry the return-value burden, and it does so by enumerating resident-period salary, Dutch tax, tax credits, and monthly net pay. It does not discuss estimation assumptions or limitations, but the core calculation context is adequately covered.

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 all five parameters, including date, scenario, gross_annual, and the optional rulings. The description hints at partial-year proration via 'while resident' and 'for that part of the year,' but it does not add parameter-level syntax or mapping 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 clearly states the specific scenario (arrival/departure year, M-form migration tax return) and enumerates the outputs: resident-period salary, Dutch tax with partial-year credits, and monthly net pay. It is more specific than a generic tax calculator, but it does not explicitly contrast itself with sibling tools such as net_salary_netherlands or income_tax_return_netherlands.

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?

Usage is implied by the phrase 'For the year someone arrives in or leaves the Netherlands,' which scopes the tool to migration years. However, the description gives no explicit when-to-use/when-not-to-use guidance or named alternatives for full-year residents or other tax scenarios.

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, destructiveHint=false, and a closed-world scope, so safety is covered. The description adds value beyond that by flagging that results are only indicative, that nothing is submitted, and that the authoritative decision rests with the Belastingdienst; these are exactly the caveats an agent needs before presenting results as fact.

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 purpose and the read-only caveat are front-loaded, and nothing is redundant with the schema. The long list in the second sentence is dense but informative, since it tells the agent exactly which benefits the answer will cover.

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 9-parameter tool with no output schema, the description covers input dimensions, output shape (indicative yearly amounts per benefit), and the 2026 assumption plus the non-binding disclaimer. What is missing is only minor, such as how partial or ineligible cases are reported.

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 every parameter has a description with defaults and units, so the schema does the heavy lifting. The description only echoes the main input dimensions (income, assets, rent, children's ages) and adds the 2026 target year, without extra semantics such as how partner or childcare inputs change the outcome.

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 verb (estimates) and a specific resource (main Dutch household benefits/toeslagen), then enumerates every benefit covered, including their Dutch names. This enumeration clearly separates it from the sibling tools, which are all tax, salary, mortgage, or visa calculators.

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 makes the use context clear (an indicative eligibility and amount estimate driven by income, assets, rent, and children's ages) and it explicitly states the limit of use: read-only, does not apply for anything, and the Belastingdienst decides eligibility. It does not name an alternative sibling or state exclusions, which keeps it from a 5.

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 as a safe, idempotent, closed-world read, so the description carries the substantive load — it discloses the underlying rules being modelled (100% up to the daily wage cap, 1 employer-paid week, 5 extra weeks at 70% from UWV, 9 parental weeks at 70%) and that output contrasts entitlement against normal pay. It does not state assumptions such as the applicable wage cap value or whether figures are gross monthly vs annual.

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 sentence with the year and country front-loaded, and every clause carries real information (leave type, payer, percentage, duration). The nested parentheticals make it read like a spec dump rather than a routed instruction, which keeps it just short of top marks.

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 still tells the agent what comes back — what each parent receives and what is lost relative to normal pay — and it frames all three leave regimes and their rates. For a pure read-only calculator this is sufficient to invoke 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 each of the six parameters is already documented, which sets the baseline at 3. The description adds meaning to the weeks parameters by attaching the 70%/100% pay treatment to them, but says nothing about holiday_pay_on_top or partner_gross_monthly beyond what the schema states.

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?

It states a concrete computational resource (income during leave after a birth in NL, 2026) and enumerates the three sub-cases it covers: maternity leave, birth leave for the partner, and paid parental leave. The scope is specific enough to distinguish it from generic salary tools in the sibling list.

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?

Usage is implied by the subject matter (someone expecting a child or planning leave), but there is no explicit 'use this when…' statement, no exclusion of nearby tools such as net_salary_netherlands or job_loss_planner, and no stated prerequisites or required inputs.

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 establish read-only, idempotent, non-destructive behavior, and the description adds useful caveats that this is a plan whose details may still change. It also clarifies the conceptual tax base, though it does not disclose calculation assumptions or result shape.

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 compact sentences front-load the planned system, year, and tax base, then add the important caveat that it is still a plan. There is no redundant 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?

The description explains the concept and scope but does not describe what the tool returns, such as a tax calculation, comparison, or estimate, despite there being no output schema. For a nine-parameter tax calculator, this leaves an important gap for an agent selecting and interpreting the tool.

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 all nine parameters are already documented. The description adds conceptual meaning by explaining what the actual return includes, but it mentions rental income and costs that are not represented as input parameters, which could confuse an agent about what can actually be supplied.

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 resource and scope: the planned Dutch Box 3 tax on actual return from 2028, with the components it covers. It clearly distinguishes this from today's notional system, but does not explicitly differentiate it from close siblings such as box3_actual_return_estimate or box3_wealth_tax.

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 context that this is a plan for 2028 and may change, but does not say when to use this tool versus alternatives like box3_actual_return_estimate or box3_wealth_tax. No exclusions or selection guidance are provided.

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, but the description adds real context beyond them: it submits nothing, is a calculation/estimate only, is not tax advice, and that it also determines which procedure applies for the year. That extras go beyond the safety profile the annotations provide.

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, both substantive. The legal background leads and the operational purpose follows; it is slightly back-loaded, since the core 'what it computes' arrives in the second sentence, but there is 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?

For a ten-parameter, read-only estimation tool with no output schema, the description covers the inputs' intent, the computation, the output (an estimated refund difference plus the applicable procedure), and the non-submitting nature. Coverage is sufficient; only explicit sibling routing 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?

With 100% schema coverage the schema already defines all ten parameters, so a 3 would be the floor. The description adds genuine meaning by spelling out the actual-return composition (interest, dividends, rent and value changes minus interest paid), which explains how interest_received, dividends_and_rent, value_change and interest_paid combine in the calculation.

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: it compares the notional Box 3 tax against the tax on the actual return and estimates the refundable difference. The scope (one tax year, 2017-2026) and the core computation are unambiguous, though it never names box3_wealth_tax, its nearest sibling, to differentiate the two.

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 selecting condition: this applies when the actual return was lower than the notional return, following the Supreme Court rulings. It does not, however, state when NOT to use it or point explicitly at box3_wealth_tax for the plain notional calculation, so the sibling routing is left implicit.

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=true, idempotent=true, destructive=false and closed-world, so the safety profile needs no restating. The description adds genuine domain behavior (fixed 2026 rates, notional return on savings/investments/debts, 36% tax, double allowance for partners), but says nothing about what the calculation returns or how the allowance is applied.

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 with no filler: year, system name, and the components covered. It is dense but every clause carries information; the optional joint-filing note is appended in the right place.

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-required-parameter calculator with no output schema, the description should ideally state what comes back (tax due, breakdown, effective rate). With the safety profile fully covered by annotations and all inputs by the schema, the remaining gap is the return value.

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 every parameter (debts, savings, investments, fiscal_partner) is already documented with valuation-date and definition guidance. The description only echoes those fields at a high level and adds no syntax, units or edge-case meaning beyond the schema, making the baseline 3 correct.

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 (Dutch Box 3 wealth tax, notional-return system) and pins the tax year to 2026, which cleanly separates it from siblings like net_salary_netherlands, transfer_tax_netherlands and dutch_tax_changes_2027. It never uses an explicit verb such as 'calculate', so the action is inferred from the name/title rather than stated, and no sibling is named for contrast.

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?

Usage is only implied by the domain: an agent can tell this is the tool for a Box 3 calculation, and the note 'Optionally for fiscal partners (double allowance)' hints at the joint-filing case. There is no when-to-use/when-not guidance, no prerequisites, and no routing against the sibling tax tools.

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, non-destructive and closed-world, so the safety profile is covered. The description adds real modeling behavior beyond that — the 60-month lock-in of an electric car's rate and cap from first registration, and that the extra tax is computed at the employee's marginal rate — but stops short of stating what the response contains or how the lock-in interacts with the supplied year.

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: core subject first, then the electric/fuel qualifier, then the lock-in parenthetical, then the marginal-rate note. Dense with nested parentheses but no filler and nothing that could be cut without losing scope.

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 read-only four-parameter calculator with full schema coverage and no output schema, the description covers the domain, the car-type split, the lock-in rule and the tax-rate treatment. The remaining gap is that it never explains what the tool returns (the bijtelling amount, the taxable base, the extra tax), which the agent must infer given there is no output schema.

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: each of the four parameters (including defaults for electric, taxable_income and first_registration_year) is already documented in the schema. The description reinforces the first_registration_year/60-month link and the taxable_income/marginal-rate link but adds no 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?

The description names the exact concept being computed — the yearly bijtelling for private use of a company car in the Netherlands in 2026 — and scopes it to electric and fuel cars. It is unambiguous against every sibling (none of which covers company car tax), though it is phrased as a domain statement rather than an explicit verb like 'calculate', so the agent must infer that this is a calculator.

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?

Usage is implied rather than stated: the mention of 'private use of a company car' and the 2026 tax year signals when the tool applies. There is no explicit when-to-use/when-not, no mention of alternative years or adjacent tools such as net_salary_netherlands or income_tax_return_netherlands that an agent might confuse this with.

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 non-destructive behavior, so the safety profile is covered. The description adds valuable scope details: which countries are supported, that treaty articles are cited, that Belgian and Polish tax amounts are not yet calculated, and the specific rules applied (progression, 182-day test, 25% rule, telework framework). This is substantial behavioral context beyond 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?

The description is dense but well-structured, front-loading the core purpose and then elaborating on each mode. Every sentence contributes relevant information; there is no filler, though the single-paragraph format could be slightly improved with bullet points for scanning.

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 14 parameters, no output schema, and complex cross-border tax logic, the description provides a clear overview of what is calculated, which countries are covered, and key limitations. It is complete enough for an agent to understand the tool's scope and call it correctly, though it does not explain return values in detail (which is acceptable without an output schema).

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 every parameter is already documented in the input schema. The description mentions mode, country, and posted in prose, but does not add parameter semantics beyond what the schema already provides. The baseline of 3 is appropriate when the schema does the heavy lifting.

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 resource (cross-border salary) and verb-like action (calculating tax/social security under treaty rules), and clearly distinguishes the two modes. It names the countries and what each mode computes, letting an agent identify the tool 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?

The description explicitly defines when to use each mode: 'move' for the year someone moves to the Netherlands, 'commute' for living in one country and working for an employer in the other. It does not name sibling tools or explicitly exclude alternatives, but the context is clear enough for selection.

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?

The annotations already establish that this is a safe read-only, idempotent check. The description adds materially useful behavioral context: it is an indicative risk check, not an official determination, and the official Webmodule is named as the authoritative alternative. It still does not describe the actual return format or how the answers are scored.

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 front-loaded with the core purpose and legal context, followed by the answering rule and the official-check caveat. It is dense but appropriately sized for a 12-parameter legal assessment tool. There is little wasted wording, though the first 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?

It covers the domain, the answer scale, the minimum-answer requirement, and the important caveat that this is only an indication. Because there is no output schema, the description should do more to explain what the tool returns, such as whether it produces a risk level, Boolean, or factor-based explanation. That missing output context limits completeness for a complex 12-parameter tool.

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 every one of the 12 enum parameters is individually described. The description adds an important constraint not obvious from the schema alone: answer each question yes, partly, or no, and answer at least 4. It does not explain how individual answers influence the risk outcome.

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 assessment verb and resource: whether a Dutch ZZP assignment risks disguised employment under DBA rules. It is clearly scoped to schijnzelfstandigheid and names the relevant regulatory context. It does not explicitly distinguish itself from nearby siblings such as employee_vs_zzp_vs_bv or freelancer_tax_netherlands.

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 useful usage mechanics: answer each question yes/partly/no and answer at least 4. It also frames the tool as an indication only and points to the official Belastingdienst Webmodule. However, it does not say when to choose this tool over related sibling tools or when not to use it.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real domain context: the 2027 figures are a proposal until Parliament votes, and the 30% ruling falls to 27% unless it predates 2024. It does not describe the shape of the comparison output, which keeps it short of 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.

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

One dense sentence with the comparison scope front-loaded, followed by the two relevant mechanics. It is packed with parentheticals but every clause earns its place; only a slightly heavy single-sentence structure holds it back from 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 three-parameter read-only calculator with no output schema, the description conveys the comparison basis, the tax elements included, and the proposal's legal status. It does not state what the returned comparison looks like, which is the only material gap.

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, but the description adds mechanism the schema only asserts: why ruling_started_before_2024 matters (30% is retained for pre-2024 rulings) and that brackets and credits are part of the computation. That is genuine meaning beyond the field labels.

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 verb (compares) and resource (income tax on a gross salary) and scopes it precisely to 2026 vs the Belastingplan 2027 proposal. That framing distinguishes it from siblings like net_salary_netherlands and visa_salary_check, which do not compare the reform scenario.

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 scenario is clearly implied (agent should use this when the question is about the 2027 plan rather than current-year net pay), but no sibling is named and no explicit when-not condition is given. An agent must infer the routing from the sibling list.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully structured. The description adds useful context by stating deadlines are calculated 'from today' and listing the included topics, but it does not explain how the boolean flags personalize the output or what the return format looks like.

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 a single sentence, but it becomes a run-on list of topics. It is compact and front-loads the core idea ('The coming deadlines for someone in the Netherlands, from today'), yet the enumeration could be better structured for scanability.

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 12 optional parameters and no output schema, the description should clarify that the tool computes a personalized deadline calendar from the provided flags and what the return roughly contains. Instead, it only lists topics, leaving the agent unsure how inputs map to outputs or when to choose this combined view over sibling tools.

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 all 12 parameters are documented in the schema itself. The description does not add syntax or explain how the situation flags (e.g., homeowner, allowances, thirty_percent_ruling) affect which deadlines appear, 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?

The description identifies the resource (Dutch tax/admin deadlines) and enumerates covered topics, but it lacks a clear verb and does not state that it returns a personalized deadline list based on the 12 situation flags. It also fails to differentiate the aggregator from sibling tools that cover individual topics (e.g., thirty_percent_ruling_timeline, income_tax_return_netherlands).

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?

No guidance is given on when to use this tool versus the many topic-specific siblings, nor are any exclusions or prerequisites mentioned. An agent must infer that this is for a combined deadline overview rather than a single-topic query.

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?

The annotations already establish that this is a read-only, non-destructive, idempotent, closed-world lookup. Beyond that, the description adds useful behavioral context: each figure includes its source, the tool covers three specified years, and 2026 has additional categories. It does not contradict 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?

The description is a single front-loaded sentence with no filler, and the verb/resource appear immediately. The long category enumeration is useful but makes the sentence dense and slightly harder to scan than a more structured list 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?

For a read-only reference lookup with rich annotations and 100% schema coverage, the description is largely complete: it names the years, source provenance, and covered categories. Since there is no output schema, it could have said more about the return shape, but nothing essential for correct invocation 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 the year and query parameters are already fully documented in the schema. The description reinforces the supported years and lists searchable categories, but adds no syntax, matching behavior, or format details beyond what the schema provides.

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: 'Looks up official Dutch tax figures' for 2024, 2025, or 2026, and explicitly states that each figure comes with its source. The category list (tax brackets, credits, Box 3, 30% ruling, etc.) makes clear this is a reference lookup tool rather than one of the many sibling calculators.

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 implies usage by saying it looks up official figures and listing the categories covered, but it does not explicitly state when to use this versus sibling calculators such as box3_wealth_tax or thirty_percent_ruling_timeline. There are no exclusions or alternative-tool routing instructions.

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 a genuinely useful constraint beyond that: only job-ad terms are available in 20 languages, all other terms come back in English or Dutch for the assistant to translate. It says nothing about response length or format, so this is solid but not rich.

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 core capability is front-loaded in the first clause; the example terms and language list are long but function as capability specification rather than filler. The 20-code enumeration is the one slightly bloated element, though it does document real coverage.

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 lookup with no output schema, the description covers what is returned (an explanation in a specified language) and the language limitation that would otherwise cause a failed expectation. Only the shape/length of the returned explanation is left unstated, which is minor here.

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 would be 3, but the description adds meaning the schema does not: it clarifies that `language` is only honored for job-ad terms and that other domains fall back to English/Dutch. It also implicitly confirms `term` accepts either the Dutch word or its English meaning, matching the schema note.

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 ("Explains Dutch terms") and narrows the scope to tax letters, job ads, housing, health and government, with concrete example terms. This clearly separates it from every sibling, which are all calculators/planners rather than a glossary lookup.

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 enumerated domains and example terms make it obvious when the tool applies (the user hit an unfamiliar Dutch term). It stops short of an explicit when-not clause or naming a sibling alternative, but with a glossary tool among calculation tools the trigger condition is unambiguous.

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 establish a safe read-only, idempotent calculation. The description adds substantial assumption context beyond annotations: 2026 Dutch rules, budget excl. VAT, employee budget covering salary and employer costs, ZZP entrepreneur deductions, BV customary wage, corporate tax, and Box 2 dividend treatment.

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 definition is a single dense sentence, front-loaded with the core comparison. It is efficient but the nested parentheticals make it slightly harder to parse than a clean one-line summary plus supporting note.

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 five-parameter calculator with complete schema descriptions and no output schema, the description sufficiently explains the calculation basis, assumptions, and the three resulting net-income figures. It could be more explicit about the output shape, but the core result is clear.

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 still adds interpretive meaning beyond the schema: it clarifies that yearly_budget is what a client or employer pays excl. VAT and that for employees this budget covers both salary and employer costs, and it frames BV salary around the customary wage.

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 calculation: net income for one yearly budget in the Netherlands in 2026 under three structures (employee, ZZP freelancer, own BV). The verb/resource/scope is precise and distinguishable from single-scenario sibling tools such as net_salary_netherlands or freelancer_tax_netherlands.

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 context of comparing three structures for one yearly budget is clear, but the description never explicitly says when to use this tool versus the many sibling tax/net-income tools, nor does it state exclusions. Usage is implied by the scenario rather than routed.

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, so safety is covered; the description adds real domain behavior beyond that: what is optimized, the two comparison baselines (50/50 and all-with-higher-earner), and the legal fact that partners may allocate these items freely in the aangifte. It omits modeling assumptions and limitations, which would push it higher.

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 audience qualifier and then the optimization target; every clause carries information. The main sentence is dense and slightly run-on, but nothing 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?

For a 13-parameter, no-output-schema optimization tool, the description conveys what the result contains (the split plus savings versus two baselines), which is the essential missing piece. It could say more about assumptions and edge cases (e.g. no Box 3 or no home), but nothing needed to call it correctly is absent.

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 does add a little composite meaning by defining the own-home result as eigenwoningforfait minus mortgage interest, linking woz_value and mortgage_interest_annual, but it adds nothing per-parameter beyond that.

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 ('finds the split') and enumerates the exact resources being split: own-home result, joint Box 3 income and shared deductions, with the optimization goal (lowest total income tax) and comparison baselines. It doesn't explicitly name or contrast a sibling tool, but no other sibling covers partner allocation, so confusion risk is low.

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 'For Dutch fiscal partners (married, registered or chosen in the tax return)' gives a clear eligibility condition that tells the agent when this applies. It stops short of stating exclusions or naming alternatives (e.g. single filers should use income_tax_return_netherlands), so it is clear context without 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?

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description usefully enumerates the cost and tax factors folded into the calculation (holidays, sick days, non-billable hours, business costs, entrepreneur deductions, income tax, Zvw), but it doesn't say whether the result is gross/net of VAT, whether it's an approximation, or what assumptions the defaults encode.

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 defines the output first, then lists the inputs folded into it; every clause carries information. It is a long run-on, but nothing is redundant padding.

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 simple read-only calculator with one required parameter and full schema coverage, the description covers purpose and factor list, but with no output schema it doesn't specify what comes back (single hourly figure vs. a breakdown) or whether the figure is ex-VAT, leaving an ambiguity an agent would want resolved.

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 each parameter is already documented with meaning and defaults; the baseline of 3 applies. The description echoes the concept behind several inputs (non-invoiceable hours, business costs, holidays/sick days) but adds no format, unit, or interaction 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 resource and computed outcome: the hourly rate a Dutch ZZP freelancer needs to net a target monthly amount in 2026. A reader knows exactly what is being computed, though it doesn't explicitly distinguish itself from neighbors like gross_salary_for_target_net or freelancer_tax_netherlands.

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?

No guidance on when to use this versus alternatives such as gross_salary_for_target_net, freelancer_tax_netherlands, or employee_vs_zzp_vs_bv. It also doesn't state prerequisites (e.g., that the result is an estimate and that a specific year's tax rules are hardcoded).

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 genuine context: it computes a broad set of Dutch-specific deductions, includes the Zvw contribution and VAT display, and explicitly says it files nothing and is not tax advice.

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 verb and subject, then a single dense list of outputs, closed by two short constraint clauses. No wasted sentences, though the middle enumeration 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?

With no output schema, the description correctly enumerates the computed outputs (profit, deductions, credits, Zvw, post-tax income) and the VAT display. Given annotations cover safety, nothing material 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 the baseline is 3, but the description adds interpretive meaning by tying inputs to concepts — the starters deduction (starter), the 1,225-hour criterion (meets_hours_criterion), and VAT charged on revenue (vat_rate). This goes beyond restating schema text.

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 verb (estimates) and precise resource (2026 Dutch income tax for a self-employed person / ZZP), and the enumeration of computed figures makes it unmistakable against siblings like box3_wealth_tax or net_salary_netherlands. An agent can identify the tool's scope 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 states the tool is read-only, files nothing, and is not advice, but gives no explicit when-to-use vs alternatives routing among the many tax siblings (e.g. income_tax_return_netherlands). Usage context is implied by the audience (ZZP/eenmanszaak) rather than stated.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — and it does: "the recipient pays" clarifies who bears the liability, and "Dutch tax applies when the giver lives in the Netherlands" states the jurisdictional gate, both of which are non-obvious behavioral facts. It stops short of describing the response shape, whence the 4.

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, no filler: the first lists the computed items, the second front-loads the two operative rules (who pays, whose residency triggers the tax). Every clause carries information an agent needs.

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 signal what comes back — it does so by enumerating exemption amounts, per-relationship rates, and a filing-requirement verdict. Year scoping (2026) and jurisdiction are also covered. Minor gap: nothing about partner recipients or how partial-year residency is handled, which matters given the 18-40 partner clause in the schema.

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 adds domain logic not present in the schema: the one-time raised exemption only applies for a recipient aged 18-40, linking the one_time_exemption and recipient_aged_18_to_40 parameters. It also frames the amount as a yearly aggregate ('yearly exemption') consistent with the per-giver-per-year semantics, though it doesn't restate 'both parents count as one giver'.

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 and tax year (Dutch gift tax, 2026) and enumerates exactly what it determines: annual exemption, one-time raised exemption, rates per relationship, and return-filing requirement. It is clearly distinct from the nearest sibling (inheritance_tax_netherlands) by topic, though it never explicitly names an alternative 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?

Usage is only implied by the subject matter — an agent can infer it answers "how much gift tax / which exemption applies" questions. There is no explicit when-to-use statement, no prerequisites (e.g. that both parents count as one giver is only in the schema), and no named alternative for related questions like inheritance or box 3.

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=true, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is fully covered. The description adds useful scope context (annual AND monthly output, holiday allowance and 30% ruling variants) but no behavioral details such as rounding conventions, assumptions for the 2026 tax year, or error 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?

A single front-loaded sentence that packs the direction of calculation, jurisdiction, year, and output shape efficiently. The trailing clause about holiday allowance and the 30% ruling mildly duplicates the schema but is not wasteful.

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 usefully discloses that the result is gross annual and monthly figures, which is what an agent needs. Combined with 100% parameter coverage and full annotations, only niche edge cases (tax-year assumptions, rounding) are left unstated.

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 all three parameters are already documented in the schema, including defaults (false for the 30% ruling, true for holiday allowance). The description only restates the two boolean toggles at a high level, adding no syntax or interpretation beyond the schema — the baseline 3 for full coverage 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: a reverse gross-from-net salary calculation, scoped to the Netherlands and 2026. The 'reverse' framing inherently distinguishes it from the sibling net_salary_netherlands forward calculator, and the output (gross annual and monthly) is named.

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 names a use case ('for salary negotiations in the Netherlands (2026)'), which implies when to reach for it, but offers no explicit alternatives or when-not-to-use guidance. Nothing tells the agent to prefer this over net_salary_netherlands or visa_salary_check in ambiguous cases.

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=true, idempotentHint=true, and destructiveHint=false. The description adds useful calculation context—that the premium includes a discount for a voluntary extra deductible and that the deductible is based on expected care costs—going beyond the safety profile. It does not explain the output format, but that is a minor gap for a read-only calculator.

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 lists the cost components without filler. It could be slightly easier to scan as a bulleted breakdown, but it is efficient and wastes no words.

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 the read-only calculator nature, full schema coverage, and annotations, the description covers the 2026 scope and the three cost components. It does not specify whether the return is a single number or a detailed breakdown—which would be helpful since there is no output schema—but otherwise it is complete enough to call the tool 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 all five parameters and their defaults are already documented in the schema. The description hints at relationships (extra deductible discount, expected care costs under the deductible) but does not add much explicit parameter meaning beyond what the schema provides. Baseline 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 computed quantity—yearly cost of basic health insurance in the Netherlands for 2026—and enumerates its three components (premium, deductible, healthcare allowance). This clearly separates it from generic Dutch tax/benefit siblings such as benefits_toeslagen_check.

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?

No explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are named. The agent must infer from the description alone that this is the right tool for health insurance cost calculations, without help on how it differs from benefits_toeslagen_check or other finance tools.

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 (a self-contained calculator). The description adds real behavioral value on top: it computes the 'best split between fiscal partners', treats foreign real estate as exempt in the Netherlands, and only produces a refund/payment verdict when payroll tax withheld is supplied. These are computation behaviors the annotations do not convey.

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, front-loaded with the overall scope before the refund/payment outcome. Every clause maps to a distinct part of the computation; only minor length costs it a point.

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 state the key output (refund or payment) and the condition that enables it. For a 13-parameter calculator whose annotations already establish it is a safe, closed-world read, this is nearly complete, though it never clarifies that the result is an estimate rather than a filing or that a breakdown is returned.

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% across all 13 parameters, so the schema already carries the parameter burden and the baseline is 3. The description groups parameters conceptually (Box 1 vs Box 3 vs treaty relief), adding light framing but no 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?

The description names a specific verb (estimates) and resource (the whole 2026 Dutch income tax return) and enumerates the components — Box 1, Box 3, own home, partner split, treaty relief. That scope enumeration distinguishes it from narrower siblings like box3_wealth_tax, box3_refund_claim and mortgage_netherlands without needing to name 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?

Scope implies this is the comprehensive-return tool versus the single-topic siblings, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent can infer usage from the breadth of coverage, which is the definition of implied 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so safety is covered. The description adds useful scoping ('for one heir') and the 2026 tax year, but it does not explain what happens when deceased_lived_in_netherlands is false or what the tool returns.

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?

It is a single, front-loaded sentence that packs the tax year, scope, exemption, rate groups, and applicability condition with 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?

With full schema coverage and rich annotations, the definition is nearly complete for selecting and calling the tool. The main remaining gap is that it does not clarify the return behavior or what happens when the Netherlands-residence condition is false.

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 amount, relationship, and deceased_lived_in_netherlands are already documented with enum values. The description restates the relationship groups and implies the amount is one heir's share, but adds no syntax, format, or edge-case 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 resource and scope: Dutch inheritance tax for 2026, for one heir, covering the exemption and rates by relationship group. It is clearly not gift tax or transfer tax, but it does not explicitly name or differentiate against any sibling 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?

There is a factual applicability note ('Due when the deceased lived in the Netherlands'), but no explicit when-to-use guidance, no when-not-to-use conditions, and no named alternatives such as gift_tax_netherlands or transfer_tax_netherlands.

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, closed-world, so the safety profile is covered. The description adds domain context (UWV rules, statutory payment) but says nothing about assumptions, defaults behavior, or result format, which matter for a 9-parameter calculator with no output schema.

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 dense sentence with the trigger condition front-loaded and outputs enumerated; no filler. Slightly list-heavy, but every clause earns its place.

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 9-parameter financial calculator with no output schema, the description names the key return values (severance, WW amount and duration, search-period end date, ruling deadline), which is most of what an agent needs. It stops short of clarifying result units/precision and any jurisdictional assumptions.

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 every parameter including defaults and the permit enum is already documented in the schema. The description adds no parameter-level detail beyond what the schema 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 scenario (Dutch contract ending) and enumerates the concrete outputs: transitievergoeding, WW amount/duration, permit search-period end date, and 30% ruling last start date. This clearly separates it from siblings like net_salary_netherlands or box3_wealth_tax, though it lacks an explicit verb such as 'calculates'.

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 scope ('an employee whose Dutch contract ends') implies when to use it, and the permit/ruling branches hint at expat vs local cases. However, there is no explicit when-not guidance or prerequisite statement (e.g. 'use only for NL employment, not for freelancers').

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 establish that this is a read-only, idempotent, non-destructive calculation. The description adds useful behavioral context: the 2026 tax year, the 30% ruling salary norm, the included compensation components, and the net yearly/monthly output plus difference.

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 a single dense sentence with the main purpose and output front-loaded. Every clause contributes either scope, input meaning, or return format.

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 appropriately explains that results are net per year, net per month, and the difference. It is nearly complete for a calculator tool, though it does not discuss assumptions, rounding, or edge cases around the 30% ruling.

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 detailed field descriptions already do most of the work. The tool description still adds meaning by mapping the calculation to base salary, 8% holiday allowance, 30% ruling with salary norm, pension contribution, and bonus, and by clarifying the two-or-three offer comparison scope.

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 verb and resource: it compares two or three Dutch job offers after income tax in 2026. It also names the exact components considered and distinguishes the tool from single-salary net calculators by focusing on multi-offer comparison.

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 context is clear: use this for comparing two or three Dutch job offers after tax. It does not explicitly mention when not to use it or name sibling alternatives such as single-salary net calculation or country comparison, so it stops short of full routing 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?

The annotations already declare the tool as read-only, idempotent, non-destructive and closed-world, so the safety profile is clear. The description adds meaningful behavioral context by explaining that it computes allowance loss alongside extra income tax and identifies cliff ranges, although it does not state computational assumptions or caveats.

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 two tightly written sentences that front-load the 2026 salary context and then enumerate the main outputs. Every clause contributes to understanding what the tool returns.

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 explaining return values, and it does so by naming allowances, net income including allowances, the kept share of the next €1,000, and cliff salary ranges. It is largely complete for invoking the tool, though additional output-structure detail or assumptions would strengthen it further.

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 all six parameters are already documented in the input schema. The description reinforces household allowance concepts such as rent allowance, healthcare allowance, and child budget, but adds little 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?

The description states a specific calculation for the Netherlands in 2026: allowances, net income, the share of the next €1,000 kept, and salary ranges where raises are mostly lost. This clearly distinguishes it from a plain net-salary or benefits calculator, though it does not explicitly name sibling alternatives.

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 is implied by the phrase 'For a salary in the Netherlands in 2026' and by the mention of salary ranges where a raise is mostly lost. However, there is no explicit guidance on when to choose this tool over siblings such as benefits_toeslagen_check or net_salary_netherlands.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds substantive behavioral context beyond that: the reference date (1 July 2026), that the 8% holiday allowance is baked into the monthly/yearly figures, and the tax/allowance assumptions (single person, no 30% ruling, no pension contribution).

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 sentence plus a short scoping fragment; the resource and reference date are front-loaded, and each clause (rate, gross, net, allowance, assumptions) corresponds to a distinct output dimension. 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, so the description must carry the return semantics — and it does, listing every value the caller receives (hourly rate, gross per month/year, net, zorgtoeslag). Combined with the explicit assumption set, an agent has enough to call and interpret results 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 coverage is 100%, so both parameters are already documented, including the 21-and-older adult-rate rule and the 40-hour default. The description reinforces that hours-per-week drives the month/year figures but adds no new syntax, ranges, or edge cases beyond the schema — 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 statutory minimum wage / wettelijk minimumloon) and precisely enumerates what is computed: hourly rate by age, gross month/year with 8% vakantiegeld, net after tax, and zorgtoeslag. This clearly separates it from generic siblings like net_salary_netherlands or gross_salary_for_target_net, which do not compute the statutory minimum.

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?

Usage context is only implied through the scope qualifier 'Single employee without the 30% ruling or a pension contribution,' which tells the agent when the answer does not apply but names no alternative tool for those cases (e.g. thirty_percent_ruling_timeline). There is no explicit 'use this when' statement or pointer to a sibling.

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 annotations already declaring the operation read-only, idempotent, closed-world, and non-destructive, the description adds substantial context: it is an indicative estimate, it uses the real Box 1 calculation including eigenwoningforfait and the second-bracket deduction cap, and it reports NHG eligibility. This goes well beyond what the annotations alone convey.

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 a single front-loaded sentence with no wasted words—each clause identifies a distinct part of the output. However, the heavy parenthetical nesting makes it dense and slightly run-on, keeping it just below 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 calculation tool with no output schema, the description correctly enumerates the return values (max mortgage, monthly annuity, first-year deduction, net monthly cost, NHG possibility) and flags the results as indicative. Combined with 100% schema coverage and safety annotations, an agent has everything needed to 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?

Schema description coverage is 100%, so the input schema already fully documents all seven parameters. The description explains the overall calculation model but adds no parameter-level syntax or format details beyond what the schema provides, making the baseline 3 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?

The description names the specific computation (indicative maximum mortgage, monthly annuity, first-year interest deduction with Box 1 calculation, net monthly cost, NHG eligibility) and anchors it to a concrete scenario (buying a home in the Netherlands in 2026). This clearly distinguishes it from tax-filing siblings like income_tax_return_netherlands or transfer_tax_netherlands.

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 phrase 'For buying a home in the Netherlands in 2026' provides clear context for when to use the tool. It does not name alternatives or exclusions, so it falls short of a 5, but the intended scenario is unambiguous and requires no 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 already declare this a read-only, idempotent, closed-world, non-destructive operation, so the safety profile is covered. The description adds real domain context beyond that: the 2026 tax year, the specific credits applied, the salary norm/cap behavior of the 30% ruling, and the stated output (net per month and per year plus effective tax rate). It stops short of noting limitations such as no partner income, no other deductions, or rounding assumptions.

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 topic and tax year are front-loaded, and the single dense sentence efficiently lists the components before a short scope clause. It is information-packed rather than padded, though the long sentence takes some parsing.

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 compensates by stating the return values (net per month, net per year, effective tax rate). It also documents the assumed tax year and employee profile. Minor gaps remain around edge cases and assumptions not modeled (e.g., partner income, other deductions).

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 every parameter (including defaults and the 0-30 pension range) is already documented in the schema. The description restates the role of each input in the calculation (holiday allowance, 30% ruling, pension) but adds little value beyond what the schema fields already convey, so the baseline of 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?

The description names a specific computation (gross-to-net salary in the Netherlands) and enumerates the exact components it accounts for: income tax with general and labour credits, 8% holiday allowance, the 30% ruling with its salary norm and cap, and pension. It also scopes the calculation to 'single employee below state pension age.' It never names a sibling tool, so an agent gets no explicit routing signal versus visa_salary_check or transfer_tax_netherlands.

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?

Usage is implied by the scenario (Dutch employee take-home pay for 2026) and the scope clause 'single employee below state pension age' implicitly excludes other cases. However, there is no explicit when-to-use statement, no mention of alternatives, and no guidance on what to use for other filing statuses or years.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the calculation basis (last year's income + factor A, plus carry-forward room) and that it also returns the tax saving, but says nothing about which tax rates/year assumptions are applied or the shape of the result.

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 question being answered and then enumerates the components. It is dense but every clause maps to a computed input or output; 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?

For a read-only calculator with 5 fully-documented parameters and no output schema, the description covers the inputs considered and the two results (deductible room and tax saved). Minor gaps remain around the assumed tax rate and whether reserveringsruimte is capped, but nothing an agent needs to invoke it 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 all five parameters are already documented with defaults and units. The description only restates the concepts behind them (jaarruimte from income and factor A, reserveringsruimte from earlier years) without adding format or edge-case detail beyond the schema, 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 computation and resource: how much may be deposited into an annuity/pension account in 2026 and deducted in Box 1, naming jaarruimte, factor A and reserveringsruimte. An agent can tell this apart from generic siblings like income_tax_return_netherlands or freelancer_tax_netherlands by the explicit jaarruimte/lijfrente scope, though no sibling is named 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?

The target user and year ('employee or freelancer in the Netherlands ... in 2026') are implied, which gives some usage context, but there is no explicit when-to-use/when-not guidance and no pointer to a related tool for adjacent questions (e.g. Box 3 or general income tax).

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, non-destructive and closed-world, so the safety profile is covered. The description adds real substance beyond that: the exact heuristic used (~15% of net income), what is returned (monthly instalment, remaining room, pass/fail), and the caveat that this is not a lender decision.

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?

Three tight sentences: the rule first, the return values second, the caveat last. Nothing is padded, though the return-value sentence overlaps somewhat with what the agent would learn by calling the tool given there is no output 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 usefully enumerates the return payload and discloses the underlying formula and its limits. It stops short of noting the Dutch-only applicability beyond a passing mention and says nothing about how edge cases (zero income, existing debt exceeding the cap) are handled, but it is sufficient to call the tool 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 all five parameters are already documented, including defaults for term_years, annual_interest_pct and existing_monthly_debt_payments. The description adds only a light gloss by naming 'amount, rate and term' and alluding to 'total credit repayments', which loosely maps to the existing-debt parameter, 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 verb and resource ('Checks a personal loan or other consumer credit') plus the exact rule applied (total credit repayments at most ~15% of net monthly income). The framing as consumer credit rather than mortgage implicitly separates it from the sibling mortgage_netherlands and rent_vs_buy_netherlands 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?

Gives clear usage context: it is a rule of thumb, not a lender decision, and real Dutch lenders use NIBUD/NVB tables and BKR registration. That tells the agent when this estimate is appropriate and when a real lender assessment is needed, though it never names a sibling tool to use 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description adds real modelling substance by naming the assumptions baked in (yearly rent increases, Box 3 treatment of the invested down payment, maintenance, mortgage interest deduction, equity build-up). It stops short of saying what the result looks like or which simplifications are made, which is the main remaining behavioural gap.

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 front-loaded sentence that leads with the comparison and then lists the cost components; nothing is redundant. It is a fairly dense run-on clause chain, but each clause contributes a distinct modelled item.

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 an 11-parameter financial model with no output schema, the description explains the inputs' logic well but says nothing about the return value (single net difference vs. a year-by-year breakdown, break-even point, sign convention). It also omits scope limits such as whether buying costs/transfer tax and selling costs are included.

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 every one of the 11 parameters is already documented with units and defaults; the description only adds interpretive context for the down-payment-as-investment and Box 3 angle. That matches the baseline 3 for a schema that does the heavy lifting.

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?

Specific verb and resource: 'Compares the net cost of renting and of buying a home in the Netherlands over a number of years', followed by an enumeration of the modeled cash flows. It is clearly a rent-vs-buy comparison rather than a mortgage calculator, but it never names the neighbouring mortgage_netherlands or box3 tools it partially overlaps with, so differentiation is inferential rather than explicit.

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?

Usage is only implied by the description of the comparison itself; there is no statement of when to pick this over mortgage_netherlands (pure mortgage cost) or box3_actual_return_estimate (investment side alone). No exclusions, prerequisites, or scope caveats (e.g. only for owner-occupied homes) are given.

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 genuinely useful modeling semantics beyond that: taxation occurs at vesting-day value, kept shares land in Box 3 the following year, and the result is a year-by-year projection covering both sell-to-cover and hold strategies.

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 tight sentences, front-loaded with the tax treatment and ending with the scenario scope; nothing is padding. The trailing fragment 'Year by year, with sell-to-cover or keeping the shares' is slightly telegrammatic but still earns its place by flagging the output shape.

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 seven-parameter calculator with full schema coverage and safe annotations, the description covers the domain model an agent needs to trust the call. With no output schema, it partially compensates by indicating a year-by-year, multi-scenario result, though it does not state the output structure or currency/units of results.

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 all seven parameters are already documented with types, defaults and units. The description only alludes to two of them thematically (the 30% ruling, keep vs. sell) and adds no syntax, ranges, or interaction rules, 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?

The description names the exact resource (RSU tax in the Netherlands) and the specific computation (per-vest Box 1 wage taxation, kept shares moving to Box 3). It is clearly distinct from generic siblings like income_tax_return_netherlands or box3_wealth_tax, though it never explicitly contrasts itself with 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?

Usage is only implied: an agent can infer this is the tool for employees holding Dutch RSUs, and that it models sell-to-cover vs. keeping shares. There is no explicit 'use this when…' statement, no prerequisites (e.g., that it needs salary and grant value), and no named alternative for adjacent questions such as the 30% ruling timeline or plain Box 3 wealth tax.

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?

Beyond the read-only and idempotent annotations, the description discloses important behavioral context: 2026 assumptions, optional Dutch holiday allowance and 30% ruling, conversion to euros, a simplified tax/social-contribution model, and exclusions for pensions and local taxes. These caveats materially affect how an agent should interpret the result.

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 front-loaded with the core comparison and avoids unnecessary filler. It is somewhat dense due to the long country list and parenthetical Dutch tax details, but every part is relevant.

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 read-only comparison tool with no output schema, the description gives enough scope, assumptions, and limitations to call it correctly. It could more explicitly state what the return value contains, such as net amounts and the comparison result, but the essential context is present.

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 all six parameters are already documented in the input schema. The description reinforces the Dutch salary, holiday allowance, 30% ruling, country comparison, and euro conversion context, but adds little syntax or semantics 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 verb and resource: it compares take-home pay in the Netherlands against a salary in one of ten named countries. This clearly distinguishes it from single-country tools such as net_salary_netherlands and broader offer tools such as job_offer_comparison.

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 the comparison use case clear but does not explicitly say when to use this tool instead of net_salary_netherlands or job_offer_comparison. Usage is therefore implied rather than routed with alternatives or exclusions.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds substantive domain behavior beyond that: the 30%→27% rate change effective 2027 applies only to rulings starting 2024 or later, the ruling ends after five years, and partial non-resident status is valid only for pre-2024 rulings. It does not cover input validation or default behavior when start_year is omitted (schema handles that), so a 4 rather than 5.

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 with a colon-delimited enumeration of the model's components, front-loading the core output (net income year by year) before the qualifying rules. No filler or repetition of the title.

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 7-parameter deterministic calculator, the description conveys the model's scope (multi-year, ruling-expiry, Box 3 on Dutch and foreign assets) so an agent can judge fit without reading the schema. The one weak point is that with no output schema, the exact return shape (e.g. per-year rows and which fields) is only loosely implied by 'year by year'.

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 every parameter including defaults and ranges (2019-2026) is already documented in the schema. The description restates one parameter rule (partial non-resident only before 2024) but adds no syntax, units, or interaction details beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

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 the exact resource and scope: net income year by year for a 30%-ruling employee, including the 2027 rate step-down, salary norm, five-year expiry, and Box 3 treatment. That distinguishes it implicitly from siblings like net_salary_netherlands (single-year net pay) and box3_wealth_tax, but it never says so explicitly, so it stops short of a 5.

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?

Usage is only implied: the presence of gross_annual and start_year signals a multi-year projection for ruling holders, and the parenthetical about partial non-resident status hints at a constraint. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. net_salary_netherlands for a single year), so it is minimum viable.

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 safety is covered. The description adds genuinely useful behavior context: the mapping from purchase type and buyer profile to the applicable rate (2% / 0% up to €555,000 / 8%), which the structured fields do not spell out. It omits any note on rounding or on what happens above the €555,000 cap for starters.

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 with three rate conditions, zero filler, and the core rate (2%) front-loaded. Every clause earns its place by encoding a distinct tax rule.

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 stateless, annotation-covered calculator with no output schema, the description supplies the rate logic needed to predict the result. It is nearly complete, though the interaction between the €555,000 cap and the 8% rate for non-owner-occupied homes is left slightly 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?

Schema description coverage is 100%, so the baseline is 3 and the schema already defines each field. The description goes beyond it by explaining how parameters interact — own_home drives 2%, the 18-34 plus price-cap combination drives 0% — which is meaning the agent cannot derive from the per-field descriptions alone.

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 domain calculation (overdrachtsbelasting on buying a home in NL for 2026) with the governing rates, so an agent can distinguish it from the salary, wealth-tax and visa siblings. It never states the action verb explicitly ('calculate'), leaving the verb to be inferred from the title, so it falls just short of 5.

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?

There is no guidance on when to use this versus alternatives — nothing about preconditions, exclusions, or when a sibling such as dutch_tax_changes_2027 is the right call. The rate tiers imply the intended scenario but do not route the agent.

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 establish that this is a read-only, idempotent, non-destructive calculation. The description adds domain-specific behavioral context beyond that: the year (2026), the FEIE vs FTC comparison, inclusion of the child tax credit and its refundable part, and the rule that AOW/Anw premiums are not creditable under the US-Dutch totalization agreement.

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 compact and front-loads the audience and key outputs in a single sentence. It is dense with useful specifics, though the nested parenthetical and run-on structure slightly reduce readability.

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 six-parameter tax calculator with no output schema, the description explains what is computed and includes important domain constraints. It does not describe the shape of the returned result, but given the rich schema coverage and annotations, it is largely complete for selection and 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 description coverage is 100%, so parameter meanings are already well documented in the schema. The description reinforces some domain context, such as the Dutch salary and child tax credit, but does not add parameter-level format or usage details beyond what the schema provides.

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 audience and resource: US citizens/green-card holders with Dutch salary, and explicitly lists the computations: Dutch tax, creditable portion, US tax under FEIE and FTC, child tax credit. It is clearly distinguishable from sibling tools such as net_salary_netherlands or box3_wealth_tax.

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?

Usage is implied by the target audience ('For a US citizen or green-card holder with a Dutch salary'), which tells an agent when this tool is relevant. However, there is no explicit when-not-to-use guidance and no named alternative or comparison to sibling tools.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuine behavioral context beyond that: holiday allowance is excluded and a 13th month only counts when paid monthly, which materially affects results. It still omits what the response looks like or how borderline cases are reported.

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?

Three short sentences, front-loaded with the core purpose, then the two counting rules. Every sentence earns its place and nothing is padded.

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 read-only single-value check with seven well-documented parameters and full schema coverage, the description is nearly complete. The one gap is that there is no output schema and the description does not say what the result contains (pass/fail, which threshold, applicable amount), though the verb 'checks whether' implies a verdict.

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 interpretive meaning beyond the schema by stating that holiday allowance does not count toward the norm, clarifying how includes_holiday_pay and thirteenth_month interact with the threshold rather than merely restating the field definitions.

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 (checks) plus resource (IND 2026 salary requirement for kennismigrant / EU Blue Card) and names the third norm covered (30% ruling). It is immediately distinguishable from siblings like net_salary_netherlands, which computes net pay rather than testing a threshold.

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 scopes usage clearly: it covers three specific norms (HSM, EU Blue Card, 30% ruling) for 2026, which tells an agent when this tool applies. It does not, however, name alternatives or state when-not to use it (e.g. vs net_salary_netherlands for take-home 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?

With annotations already declaring this as a read-only, idempotent, non-destructive tool, the description adds useful behavioral context: objecting is free, the WOZ-beschikking contains the value and date, and the objection deadline is six weeks. It also discloses the no-comparables fallback behavior. It does not describe every output field, but it goes beyond 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?

The description is dense but front-loaded: it states the core purpose first, then elaborates on savings, the deadline, and the fallback case. Every sentence adds information relevant to calling or interpreting the tool. It is slightly long and run-on but well structured for a complex financial check.

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, multi-input financial calculation with no output schema, the description explains the main outputs: comparable-sales comparison, yearly savings in eigenwoningforfait and OZB, and the objection deadline. It also covers the no-comparables fallback. Some finer details of returned values and assumptions are left implicit, but the description is sufficient for an agent to understand what the tool will do.

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 input schema already documents each parameter thoroughly. The description adds some meaning by noting that two or more comparable sales make the comparison usable and by tying the deadline to the decision date. Since the schema carries most parameter semantics, the baseline score 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?

The description names a specific verb and resource: checking whether objecting to a Dutch WOZ value is worthwhile. It distinguishes itself from the many other Dutch tax tools by focusing on WOZ valuation, comparable sales per m², OZB, eigenwoningforfait, and the objection deadline. An agent can identify the tool's domain 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?

The description makes clear when the tool applies: when someone has a WOZ decision and is considering objecting. It also explains the fallback when no comparable sales are supplied, still returning yearly OZB and objection information. It does not explicitly name when not to use it or name sibling alternatives, but the context is clear.

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