Nettomaandinkomen

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

Annotations already declare readOnlyHint/idempotentHint, so safety is covered. The description adds substantive domain behavior the schema does not: the 2% accrual discount per year outside the Netherlands and the inclusion of vakantiegeld in the gross figure. It omits nothing critical, though it does not disclose precision caveats of the 'indicatief' net estimate.

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

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

Front-loaded with the computation, followed by usage, exclusions, and prerequisites in a logical order. It is a dense single block rather than separated clauses, but every sentence carries information and nothing is 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?

An output schema exists so return values need no explanation, and annotations cover the read-only profile. The description supplies the calculation scope, exclusions, and required inputs, leaving only the 'required' wording slightly inconsistent with the schema defaults.

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, but the description adds meaning beyond the schema by tying the 2%-per-year rule to the outside-NL accrual input and referencing woonsituatie (samenwonend). Minor mismatch: it calls woonsituatie 'required' while the schema makes samenwonend optional with a default.

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 specific outputs — AOW-leeftijd, AOW-ingangsdatum, gross (incl. vakantiegeld) and indicative net monthly AOW for single/cohabiting — so the agent knows exactly what is computed. It also explicitly distinguishes itself from nmi_ww_uitkering and nmi_wia_uitkering by naming them. This is a precise verb+resource+scope statement.

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?

"Gebruik bij vragen over wanneer en hoeveel AOW" gives the positive trigger, and "Niet gebruiken voor aanvullend pensioen of WW/WIA" with two named alternative tools gives the exclusion. Both when-to-use and when-not-to-use are explicit.

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, closed-world), so the description is free to add domain behaviour: vakantietoeslag is included, kostendelersnorm only counts medebewoners aged 27+, the own home is exempt up to the statutory limit, and no arbeidskorting is applied because norms are already net. That is meaningful context beyond the annotations, though return shape and edge-case handling remain unstated (output schema likely covers 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?

Front-loaded with the computed result, then usage, then exclusions, then a precision caveat. Dense but no sentence is filler; only minor compression would be possible.

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 calculation tool with an output schema (so returns need not be described), the description supplies scope, exclusions, and the main computational rules. The only thin spot is that per-field interpretation of medebewoner_leeftijden and inkomsten is only partially spelled out in prose.

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 71% schema coverage the baseline is 3, but the description adds real semantics: it clarifies that medebewoners only matter from 27+, that vermogen excludes the own home against a statutory threshold, and that netto inkomsten are offset against the norm. These map directly onto the leefvorm/vermogen/overwaarde/medebewoner inputs.

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 names the exact computed output ('Netto bijstandsnorm per maand (incl. vakantietoeslag) volgens de Participatiewet') and enumerates the mechanisms it applies (kostendelersnorm, verrekening netto inkomsten, vermogenstoets). The scope boundaries ('Niet voor jongerennormen (18-20), bijzondere bijstand of gemeentelijke regelingen') carve it away from adjacent concepts an agent might confuse it with.

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?

Explicit routing both ways: 'Gebruik bij vragen over bijstand of sociaal minimum vanaf 21 jaar' states the trigger, and the following sentence lists the exclusions (18-20 normen, bijzondere bijstand, gemeentelijke regelingen). Nothing is left to inference about when this tool applies.

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 carry readOnly/idempotent/closed-world, so safety is covered. The description adds real behavioral context beyond that: the tool silently yields no amounts for non-loondienst cases, and bijzonder loon is taxed at a separate special rate producing both yearly net and monthly average. It stops short of describing pagination/precision behavior, but nothing is misleading.

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

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

Purpose is front-loaded and the three sentences map cleanly to purpose, special-pay behavior, and routing/exclusions. It is dense and readable in Dutch; a slightly shorter exclusion clause would be possible, but every sentence 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?

An output schema exists, so return values need no explanation. The description covers scope, refusals, the special-pay edge case, the annual-salary convention, and the sibling routing — enough for correct invocation of a 7-param calculation 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 description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the tax treatment of bijzonderLoonYearly (apart belast tegen het bijzondere tarief, output als totaal per jaar en gemiddelde per maand) and by defining the jaarsalaris-to-maand conversion, which the schema does not state.

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 ('Berekent het netto maandloon uit een bruto maandloon') and scopes the domain precisely (Nederlandse loonheffing 2026, schijven, heffingskortingen). It distinguishes itself from siblings by naming nmi_woonbudget and by spelling out the ingredient set (pensioenpremie, 30%-regeling, bijzonder loon).

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?

Explicit when-to-use ('loondienst'), when-not ('dga, zzp of buitenlandse belastingplicht volgen géén bedragen'), and an alternative ('Gebruik nmi_woonbudget als de vraag over huur of huurtoeslag gaat'). It even gives a rule for an ambiguous input case (jaarsalaris → deel door 12).

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 openWorldHint=false, so the 'Read-only' sentence largely repeats structured data. The added value is the note that no input is required apart from the optional year, but nothing is said about caching, versioning of the figures, or coverage of non-2026 years.

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

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

Front-loaded with the resource content, then usage, then the exclusion and the read-only note. The enumeration of fiscal items is long but functional for retrieval; every sentence carries information, with only minor redundancy in restating the read-only annotation.

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?

An output schema exists, so return values need no explanation. For a zero-required-parameter read-only lookup, the description supplies purpose, contents, usage, exclusion and the optional-year caveat — nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100% and the single fiscalYear parameter is already documented in the schema (available: 2026, default 2026). The description only echoes this with 'eventueel het jaar', adding no format or edge-case detail 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 verb and resource ('Geeft de kerncijfers waarmee de NMI-rekenkern werkt') and enumerates the exact contents (belastingschijven, heffingskortingen, maximumdagloon, WW/WIA, minimumloon, vakantiegeld, 30%-regeling). It also explicitly distinguishes itself from the calculation siblings by declaring what it is not for.

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 when-to-use ('Gebruik om tarieven op te halen of te controleren in plaats van ze uit het geheugen te noemen') and an explicit when-not ('Niet gebruiken voor een persoonlijke berekening'). The alternative is referenced only generically as 'de rekentool' rather than by one of the concrete sibling names such as nmi_bruto_netto or nmi_netto_inkomen_volledig, so routing is slightly less precise than it could be.

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 closed-world, covering the safety profile for a pure calculator. The description adds useful domain behavior beyond that: monthly computation, application of the rent limit (huurgrens) and capping (aftopping), and the required inputs. It does not disclose edge cases or output shape, but an output schema exists so that is acceptable.

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 dense but purposeful sentences: purpose and computation basis first, then usage routing, then required inputs. No filler, though the sentence structure is compressed enough that the parameter enumeration reads as a list.

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

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

With an output schema present and annotations covering safety, the description supplies the key routing and input information. The only gap is the two parameters (partner income and asset threshold) left unexplained, which is a minor omission for an 8-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 only 50%, so the description must compensate, and it does by enumerating the main drivers: gross annual income, bare rent, service costs, household type, resident children and age category. It omits partner_jaarinkomen and vermogen_onder_grens, which remain undocumented in both places.

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 (berekent) and resource (huurtoeslag per maand) plus the calculation basis, and explicitly distinguishes itself from siblings nmi_woonbudget and nmi_zorgtoeslag. An agent can route to it 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?

Explicitly states when to use it (loose huurtoeslag question with known annual income) and when not to use it, naming the two alternative tools (nmi_woonbudget for net income/housing budget, nmi_zorgtoeslag for care costs). Also states the two 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 declare readOnly/idempotent/closed-world, and an output schema exists, so the description correctly focuses on behavioral scope: income independence and explicit exclusions (dubbele kinderbijslag, woonlandfactor, 16-17 without school). This adds real value, though it doesn't discuss edge behavior like invalid age inputs or how the excluded cases are handled.

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: purpose first, then the income-independence rule, then alternatives, then exclusions. Every sentence carries necessary information, though the exclusion clause is packed and could be marginally tightened.

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 an output schema, full parameter coverage, and safety annotations already present, the description fills the remaining gaps: sibling routing, income independence, and scope boundaries. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (periode enum, leeftijden_kinderen) are fully documented in the schema. The description only restates that computation is based on age per child, adding no syntax or format detail 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 computation (kinderbijslag/AKW paid by SVB) with its unit (per quarter and per year), scope (children up to 18), and basis (age per child). It explicitly distinguishes itself from nmi_kindgebonden_budget and nmi_kinderopvangtoeslag, so an agent can route correctly without opening schemas.

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?

Names two alternative siblings with the condition that selects each (income-dependent allowance, childcare costs), and states an input rule ('Inkomensonafhankelijk: vraag geen inkomen'). It also lists what the tool does NOT cover, which is exactly the when-not guidance an agent needs.

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 openWorldHint=false, so the safety profile is covered. The description adds genuinely new domain behavior: the calculation caps the reimbursed hourly rate and the number of reimbursed hours per Dutch regulation, plus the eligibility precondition. It does not discuss return format, though an output schema exists to cover that.

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?

Four tightly-packed sentences, front-loaded with purpose, then usage, then domain behavior, then exclusions. Every sentence carries routing or behavioral value with no repetition.

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

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

With an output schema, full annotation coverage and a 100%-documented input schema, the description supplies exactly the missing pieces: eligibility precondition, regulatory capping behavior, and sibling disambiguation. Nothing an agent needs 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 schema already documents every parameter including enum values and min/max bounds. The description only gestures at the input categories (inkomen, opvanguren, uurtarief) without adding format or constraint detail 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 verb (berekent) and resource (kinderopvangtoeslag) with scope (2026, per maand en jaar), and explicitly distinguishes itself from two named siblings (nmi_kindgebonden_budget, nmi_zorgtoeslag). An agent can route correctly without opening any 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?

Gives explicit when-to-use (dagopvang, bso, gastouder bij vragen met jaarinkomen, opvanguren en werkelijk uurtarief), a prerequisite (beide_ouders_werken), and explicit when-not with named alternatives. Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds the eligibility prerequisite tied to vermogen_onder_grens and the fact that the calculation is a Dutch statutory benefit computation, which is useful 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?

Three sentences, front-loaded with purpose and components before prerequisites and exclusions. Dense but every clause carries information; only minor tightening is possible.

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?

An output schema exists so return values need not be described, and the annotations carry the safety profile. Purpose, inputs, eligibility condition and sibling routing are all present, leaving no gap for an agent to fill.

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, including defaults and ranges. The description restates the conceptual inputs (gezamenlijk toetsingsinkomen, leeftijden 0 t/m 17) but adds no syntax or format 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 verb and resource ('Berekent ... het kindgebonden budget per maand en jaar') with the scope (2026), the input basis (toetsingsinkomen, gezinssituatie, leeftijden 0-17) and the components computed. It is immediately distinguishable from the surrounding toeslag 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?

Explicitly names when to use it (basisbedrag, leeftijdsverhogingen, inkomensafbouw, alleenstaande-ouderkop), states a prerequisite (vermogen onder de vermogensgrens) and lists three exclusions with the exact sibling to use instead. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, openWorldHint=false and idempotentHint, covering the safety profile. The description adds the critical behavioral constraint that only 'loondienst' yields amounts, but does not describe the output structure despite having an output schema (which lowers the burden). Adds moderate value beyond 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?

Front-loads the purpose, then usage, then exclusions and requirements in a tight sequence. Efficient but dense; every sentence carries information though the enumeration of components is lengthy.

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 tool's complexity is moderate (7 params, output schema present, annotations cover safety). The description covers purpose, usage, exclusions, and a key constraint; output explanation is unnecessary given the output schema exists. Nearly complete, with only minor gaps around component behavior.

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 seven parameters in detail including ranges and defaults. The description only restates the required 'bruto basisloon' and the loondienst limitation, which is already in the dienstverband schema description. 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 verb+resource (builds a Dutch monthly payslip for 2026 and explains each line in plain language) and enumerates the components covered: basisloon, toeslagen, bijzonder tarief, SV-loon, loonheffing, Zvw, netto. This clearly distinguishes it from the sibling nmi_bruto_netto net calculation.

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?

Explicit when-to-use ('als iemand vraagt wat een post op zijn loonstrook betekent of waarom zijn netto afwijkt') and when-not ('Niet gebruiken voor alleen een netto-bedrag (gebruik nmi_bruto_netto) of een jaaroverzicht'), naming the alternative tool directly.

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 readOnlyHint, idempotentHint, and openWorldHint=false. The description adds useful behavioral content beyond those flags: the step plan covers tool choice, required data, caveats, and a verifiable link, so an agent knows what kind of guidance to expect.

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 all necessary information into a colon-separated list without filler. Every clause earns its place by describing what the step plan contains.

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 an output schema that defines the return structure, rich annotations covering safety and idempotency, and a fully documented optional parameter, the description supplies sufficient context: it explains the tool's role and the contents of the plan. No essential invocation details are 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 coverage is 100%, with the sole optional parameter 'onderwerp' fully described by its enum and default in the schema. The description adds no parameter-level meaning beyond that, 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 ('Geeft') and resource ('stappenplan ... inkomensvraag'), and encloses the scope: which tool, data, caveats, verifiable link. It is clearly distinct from sibling calculators like nmi_bruto_netto because it is a routing/method tool rather than a specific calculation.

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?

Implies usage context: for carefully answering a Dutch income question with NMI tools, and it promises to tell which tool to use. However, it does not explicitly name when to use this versus jumping directly to a sibling calculator, nor does it state 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 cover safety (readOnly, idempotent, closed-world), so the bar is lower. The description adds meaningful domain behavior beyond annotations: it compares annuïteit vs draagkracht and returns the lower amount, and it specifies the two regelingen. It stops short of covering edge cases or output details, hence not 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?

Front-loads the calculation purpose, then usage guidance, exclusions, and required inputs in a compact paragraph. Every sentence earns its place with no redundancy.

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 a rich input schema, full annotations, and an output schema that handles return values, the description provides everything needed: what the tool calculates, when to use it, when not to use it, and the minimum required inputs. No critical gaps remain.

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 four parameters in detail. The description only restates the required inputs ('schuldbedrag, regeling en inkomen') without adding syntax, constraints, or meaning beyond the schema. 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 verb ('Berekent'), resource ('maandbedrag voor terugbetaling van een DUO-studieschuld'), and calculation logic (wettelijk maandbedrag vs draagkracht; lowest applies). It distinguishes itself from siblings by explicitly naming nmi_bruto_netto and excluding hypotheekruimte.

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

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

Explicitly says when to use ('Gebruik bij vragen over aflossing van studieschuld') and when not to use ('Niet gebruiken voor hypotheekruimte ... of netto loon (gebruik nmi_bruto_netto)'). Names the correct alternative tool for an out-of-scope use case.

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 mark it as read-only, idempotent and closed-world, so safety is covered. The description adds process-specific behavioral context the annotations cannot: the SV-dagloon cap (maximumdagloon), the fact that it produces gross figures only, and that it does not determine the disability percentage. The missing piece is any mention of return structure — but that's typical for a numeric-output tool.

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?

Compact, single paragraph, front-loaded with the core action and scope. Every sentence adds value (cap, alternatives, input, limits). Slightly dense but not padded; a mild overload warning would be the only nit.

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?

Because an output schema is present, the description needn't document return fields, and it doesn't. It does signal that the output is gross (not net), which is a useful expectation-set, and it scopes the input adequately for an agent to call it correctly. The main missing detail is the 8% vakantiegeld handling — but that's handled 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 the parameters are already documented. However, the description's 'Vereist: laatstverdiend bruto maandloon' highlights the critical input and implicitly clarifies the semantics of grossMonthlySalary (last-earned, pre-disability) that an agent benefits from seeing up front.

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?

Provides a specific verb (berekent), resource (WIA-uitkering: IVA, WGA-loongerelateerd, WGA-vervolg), target year and the exact output unit (bruto maandbedragen). This precision makes it instantly distinguishable from siblings like nmi_ww_uitkering and is clear enough for an agent to know exactly what the tool returns.

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?

States both when NOT to use it ('Niet gebruiken bij werkloosheid zonder arbeidsongeschiktheid – gebruik nmi_ww_uitkering', 'of voor loon uit werk – gebruik nmi_bruto_netto') with named alternatives, and the intended use case: comparing scenarios. Explicit routing plus an internal rule ('UWV bepaalt na de keuring') that grounds it in the real process — near-exhaustive 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 only cover the safety profile (readOnly, idempotent, closed-world), so the description usefully adds substantive behavior: results are only produced for loondienst/NL residents, the vermogenstoets is NOT checked, and it is not mortgage or loan advice. These are real constraints an agent needs before calling.

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

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

Purpose is front-loaded in the first two sentences, followed by routing guidance and caveats. The single dense paragraph packs several concerns together but no sentence is filler; only the dienstverband restriction partially overlaps the schema.

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

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

With 8 parameters, an output schema present, and annotations covering safety, the description supplies the remaining essentials: what is computed, when to use it versus the sibling, and the eligibility/disclaimer boundaries. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% with enums documented for dienstverband, leeftijd and huishouden, so the schema carries all parameter meaning. The description restates the grossMonthly input and the loondienst precondition but adds no syntax, units or defaults beyond what the schema already 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?

Names a specific verb (rekent) and enumerates the exact outputs: netto maandinkomen, huurtoeslag, residual amount after rent, plus huurgrens and aftoppingsgrenzen. It also explicitly distinguishes itself from nmi_bruto_netto, so an agent can select it without opening the sibling's 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?

"Gebruik deze tool alleen bij een huur- of woonlastenvraag" gives an explicit use condition and names the alternative (nmi_bruto_netto) with the case that selects it (netto loon, vakantiegeld, dertiende maand, IKB). It also states an exclusion: no amounts for dga/zzp/buitenlandse belastingplicht.

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

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

Annotations already cover read-only/idempotent/closed-world, and the description adds real behavioral context beyond them: the SV-dagloon is capped at the maximumdagloon, and importantly it discloses a scope limitation ('recht en uitkeringsduur worden niet vastgesteld'). It does not discuss calculation assumptions or error cases, keeping it just 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?

Front-loaded with purpose, then usage, then exclusions and requirements; every sentence carries routing or constraint information. It is slightly dense with three separate clauses but 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 an output schema present, return values need no explanation, and the description still covers scope, phase logic, caps, non-deliverables (recht/duur), required inputs and preconditions. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters (grossMonthlySalary, includesHolidayPay, applyLoonheffingskorting) are already documented in the schema. The description restates the required bruto maandloon input and holiday-pay dependency but adds no syntax or format detail beyond it; 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 ('Berekent ... de bruto en indicatieve netto WW-uitkering per maand') with explicit scope (2026, per maand, gebaseerd op laatstverdiend bruto maandloon). It names the siblings it is not (nmi_wia_uitkering, nmi_bruto_netto), so an agent can route without opening another 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?

Gives explicit when-to-use (fase 1 75%, fase 2 70%), explicit when-not-to-use with named alternatives ('Niet gebruiken bij ziekte of arbeidsongeschiktheid (gebruik nmi_wia_uitkering) of voor loon uit werk (gebruik nmi_bruto_netto)'), plus preconditions ('dienstverband moet loondienst zijn'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the default assumption that assets are treated as below the limit unless specified, plus the income components considered. It does not describe output shape, though an output schema exists.

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

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

Front-loads the calculation purpose, then usage, then exclusions, then the default assumption. Four dense sentences with no filler; every clause carries routing or computation information.

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 deterministic calculator with a full output schema and safety/idempotency annotations, the description supplies everything an agent needs: when to invoke, what inputs mean, default assumptions, and which siblings to prefer instead. Return values need not be explained given the 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 the baseline is 3. The description goes further by clarifying that toetsingsinkomen is gross annual income including holiday allowance and that the partner's income is combined, and it restates the vermogen default — semantics that enrich the parameter meaning rather than merely repeating it.

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 (berekent) and resource (zorgtoeslag), plus the output granularity (per maand en jaar) and the driving input (toetsingsinkomen). It explicitly names the sibling tools it is not (nmi_huurtoeslag, nmi_kindgebonden_budget), so an agent can route without opening a schema.

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

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

Provides explicit when-to-use ('Gebruik bij vragen over recht op of hoogte van zorgtoeslag') and when-not-to-use with named alternatives for both rent and children. Nothing is left to inference.

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