KzCalc

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses the exact computation (poverty line minus income plus 1.5 MRP per child aged 1–6, from application month to quarter end), the fact that it is advisory rather than authoritative, and the legal basis (MTSZN order No. 160, 35% median / 70% subsistence minimum).

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 purpose and Russian/Kazakh aliases, then scope limits, then the calculation and legal rule. Dense but each sentence carries substantive information; the trilingual title line and long legal citation add some length without much agent value.

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

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

With no output schema, the description compensates by spelling out what the tool returns (monthly and quarterly amounts and the formula) and by stating the authority/eligibility boundary, which is exactly what an agent needs to interpret the result and not overstate it.

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 real meaning for poverty_line_kzt: it is regional, changes every quarter, must come from the user or an official source, and is legally defined as the larger of 35% of median income and 70% of the regional subsistence minimum. It also explains application_month's role in fixing remaining quarter months.

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 ('Tests the income criterion for targeted social assistance (АСП) in Kazakhstan and estimates the monthly and quarterly amount'). Clearly distinct from sibling tools such as kz_mrp_convert or kz_salary_gross_to_net.

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 scope boundaries: 'It does not decide eligibility: the family survey, employment measures, social contract and refusal grounds are decided by the authority.' Also instructs the user to supply the poverty line rather than guess. It does not, however, name an alternative sibling tool or state when another tool would be preferable.

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 genuinely useful behavior beyond that: the sufficiency table covers ages 20–62, out-of-range ages are handled in a defined way, and the actual withdrawal right and balance are confirmed downstream by ENPF and operators, which is an important caveat about result authority.

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 core comparison, then boundary rules, then the caveat. Dense and mostly waste-free, though the trilingual title keyword string at the start is a minor overhead for an agent reading the definition.

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 return-value burden and does so: it states the tool returns either the amount above the threshold or the shortfall, plus the qualifier about downstream confirmation. Combined with full schema coverage and clear annotations, 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 the baseline is 3, but the description adds meaning beyond the schema by explaining how the age parameter maps to the threshold table (below-table ages, above-table treated as retirement). It does not elaborate on the lang parameter or the tenge rounding, which are already documented in the schema.

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

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

States a specific verb and resource: it compares mandatory ENPF (OPV) pension savings against the 2026 minimum sufficiency threshold for a given age and returns the surplus available for housing/treatment or the shortfall. This is clearly distinguishable from siblings like kz_otbasy_mortgage or kz_mrp_convert without opening either 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 gives clear usage context for the housing/treatment withdrawal set of use cases and boundary behaviors (ages below the table yield no available amount, ages above are treated as retirement age). It does not explicitly name an alternative sibling tool or state when not to use it, which keeps it short of a 5.

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

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

Annotations already declare this a safe, read-only, idempotent, closed-world lookup, so the safety profile is covered. The description adds genuine value on top: the data is year-versioned and volatile ('change every year'), and it is sourced from official publications, which tells the agent to fetch fresh rather than cache.

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 second sentence is a dense but purposeful enumeration of returned fields. The trilingual title repetition consumes space for a modest multilingual-matching benefit, keeping it short of 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?

With no output schema, the description compensates by listing the returned indicators and their sources, and the annotations cover the safety profile. A single optional parameter needs no more explanation, so it is nearly complete for this tool's complexity.

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 'lang' parameter is fully documented with its enum and default, so the schema does the heavy lifting. The trilingual tool naming ('показатели РК / Қазақстан көрсеткіштері') hints at the localization dimension but adds no syntax 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+resource (returns 2026 Kazakhstan statutory indicators) and enumerates the exact figures returned (MRP, MZP, BDO, subsistence minimum, payroll rates/caps), which clearly separates it from the sibling calculator tools. An agent can tell it is a data-lookup tool, not a calculation 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?

Explicitly says to use it 'instead of model memory' because the figures change every year, which is a clear condition for selecting it. It does not name a specific sibling alternative or say when not to use it, so it falls short of a 5.

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

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

With readOnlyHint/idempotent/non-destructive already in annotations, the safety profile is covered, and the description layers on real domain behavior: exactly which contributions are computed and which are waived for pensioners, pre-1975 births and disabilities. It does not describe the return shape or the MZP-cap behavior at the edges, but the contribution logic is substantial added context.

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

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

Front-loads trilingual keywords for discoverability, then a substantive sentence on scope and outputs, then the imperative about the required input. Every sentence carries weight; the trilingual header is slightly redundant against the name but justified for search recall.

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 8-parameter calculator with full schema coverage and no output schema, the description supplies the scope, the computed outputs, the exemption rules and the required user input. Only the response format and cap/limit edge cases remain unstated, which the absence of an output schema makes less critical.

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 genuine meaning beyond the schema: monthly declared income is required and sets the contribution base, and the exemption booleans are framed as a conditional ruleset. It reinforces value rather than merely restating fields.

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 (calculates) plus concrete outputs — the half-year tax and the four mandatory monthly payments (OPV, OPVR, SO, VOSMS) — for a narrowly defined subject (ИП without employees, form 910.00, 2026). This is clearly distinguishable from every listed sibling, which cover salaries, maternity, mortgage, fines and indicators rather than IP 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?

The description scopes usage tightly: individual entrepreneurs without employees on the simplified declaration, 2026. It also tells the agent to elicit a required input before calling. It stops short of naming when NOT to use it or pointing to a related tool for the employed/other-regime case, so no explicit alternative is offered.

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 a pure, idempotent, read-only calculation (readOnlyHint, idempotentHint, non-destructive, closed-world), so the safety profile is covered. The description adds real domain context (126 vs 140 days, coverage until 1.5 years, which income base feeds which benefit), but omits any caveats about approximation, statutory caps on insured income, or which assumptions the 2026 rules embed.

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, all front-loaded: multilingual synonyms first for matching, then the computed components, then the input branch conditions. No sentence is redundant with the others, and the most decision-relevant branching (employed vs not) is placed last for emphasis.

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 6-parameter, no-output-schema calculator, the description covers what is computed and the conditions on inputs, which is the bulk of what an agent needs. It stops short of describing the shape of the returned estimate (breakdown vs total) or the statutory ceilings that make the result an estimate rather than an exact entitlement.

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 mapping each benefit to its income base (12-month income for leave, 24-month for childcare) and clarifying that incomes are ignored entirely when is_employed is false. It does not add format/syntax detail for the income parameters 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?

States a specific verb (estimates) and resource (Kazakhstan state benefits around a birth in 2026) and enumerates the three components computed: the one-off birth payment, the maternity leave payment, and the monthly childcare allowance. No sibling tool in the list covers maternity benefits, so the resource is unambiguously distinguished.

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 conditional context: an employed mother requires the 12-month and 24-month average income inputs, while a non-employed mother uses only fixed amounts by child rank and incomes are ignored. It does not name alternatives or state when-not-to-use, but no sibling overlaps this domain, so routing 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so credit here is for added behavior. The description discloses the fixed 2026 MRP rate anchor, which tells the agent this conversion is year-pinned and has no other rate versions available — a genuinely useful behavioral fact 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?

Short and front-loaded: the searchable multilingual aliases come first, then the mechanism, then the use case. The alias line is slightly redundant for an agent but defensible; nothing else 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?

Adequate for a two-way converter, but there is no output schema and the description never says what is returned. The lang parameter implies the response also carries source titles, limitation notes and page links, yet the description omits any mention of those outputs, leaving an agent to infer the return shape.

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

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

Schema description coverage is 100% and both enums (unit, lang) are fully self-documented in the schema, so the baseline of 3 applies. The description restates the MRP↔tenge direction but adds no format, rounding, or boundary semantics beyond the schema's minimum/maximum constraints.

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 ('Converts between MRP ... and tenge') and names the exact rate basis (2026 MRP value), which no sibling covers. The added clause about fines, fees, benefits and tax thresholds in MRP makes it distinguishable from tools like kz_traffic_fine_discount or kz_indicators_2026 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 clear triggering context: use for fines, fees, benefits and tax thresholds that the law states in MRP. That is real when-to-use guidance, but it names no alternative tool or any when-not condition (e.g., do not use for statutory reference data lookups).

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, so the safety profile is covered. The description adds genuinely valuable behavioral context beyond that: this is a formula estimate rather than the bank's actual schedule, stage 2 rate depends on the bank's accumulated score, the 20% state premium and deposit term, and loan limits vary by region.

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 content is front-loaded and dense with useful specifics (program durations, rate band, regional limits). The trilingual keyword header ('Otbasy mortgage estimate / ипотека Отбасы банк / Отбасы банк ипотекасы') is redundant padding, but every subsequent sentence carries real 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?

With no output schema and 7 parameters, the description carries the burden of describing results — and it does list the computed outputs (deposit/down-payment/limit checks, stage 1 monthly payment, stage 2 range). It stops short of enumerating exact return fields or units, but covers the calculation's structure well enough to call 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 baseline is 3. The description adds some interpretive value by explaining that the stage 2 rate (3.5%–5.0%) is not an input because it depends on the bank's score, and by restating that limits hinge on region — but it does not give per-parameter meaning beyond the already-exhaustive 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 opens with a concrete verb+resource ('Estimates the two-stage housing loan of Otbasy Bank under the "Nauryz" and "Otau" programs') and enumerates exactly what is computed: deposit/down-payment/limit checks, stage 1 monthly payment, and stage 2 payment range. It is unmistakably distinct from the sibling tools, which cover taxes, salaries, benefits and fines.

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 implied ('It is a formula estimate, not the bank's schedule'), which tells the agent this is an approximation rather than an authoritative schedule. However, there is no explicit when-to-use/when-not-to-use statement and no alternative tool is named or excluded, so the agent must infer the applicability window.

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 as a safe, idempotent, non-destructive read/compute operation, so the safety profile is covered. The description adds real value beyond them by disclosing what the calculation returns: a line-by-line breakdown of employee withholdings and employer contributions under 2026 rules. It does not cover numeric limitations, rounding, or the upper salary cap, 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?

Two sentences, front-loaded with the trilingual output concept and then the calculation scope. The opening keyword string is dense but serves search matching; otherwise there is little waste. Slightly heavy for the amount of routing information conveyed.

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

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

With no output schema, the description carries the burden of describing the return, and it does so by naming the line items returned for both employee and employer sides. That is enough for an agent to know what to expect, though totals, rounding behavior, and currency formatting of the response remain unspecified.

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

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

Schema description coverage is 100%, so all five parameters (lang, employee_type, born_before_1975, gross_salary_kzt, apply_base_deduction) are already documented in the schema with defaults, enums, and legal citations. The description adds domain framing around the withholdings but no syntax or format detail beyond the schema, 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?

States a specific verb and resource ('Converts a monthly gross salary into the net amount paid to the employee in Kazakhstan'), names the jurisdiction and 2026 ruleset, and enumerates the exact components produced (OPV, VOSMS, IPN, OPVR, SO, OOSMS, social tax). The direction of conversion is unambiguous, which cleanly separates it from the inverse sibling kz_salary_net_to_gross.

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 conversion direction and the trilingual keywords, but there is no explicit when-to-use guidance and no mention of the inverse tool kz_salary_net_to_gross as the alternative for the opposite calculation. An agent can infer the fit, but routing 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 establish readOnly, idempotent, non-destructive behaviour, and the description goes further by disclosing the rounding contract ('smallest whole-tenge gross whose rounded net equals the target') and the returned withholding/contribution breakdown. Withholding rules are delegated to the schema's parameter descriptions, so it stops just short of full behavioural coverage.

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 trilingual label line is front-loaded and the second sentence packs scope, semantics and return contract efficiently with no filler. Slightly redundant for a reader who only needs one language, 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?

With no output schema, the description correctly compensates by describing the return value (smallest qualifying gross plus full withholding/contribution breakdown), which is the essential missing piece. It omits how ties or out-of-range inputs behave, but the schema bounds cover those adequately.

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 explains lang, employee_type, born_before_1975 and apply_base_deduction in detail. The description only clarifies the target-net concept ('на руки') and adds no syntax or edge-case detail beyond the schema, 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?

States a specific transformation (find monthly gross from a target net) with the exact country and year scope, and effectively distinguishes itself from the inverse sibling kz_salary_gross_to_net through the direction of the calculation. An agent can tell exactly what comes out 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 scenario is implied by 'employee receives a target net amount', so an agent can infer when the tool applies, but there is no explicit when-to-use/when-not guidance and the inverse sibling kz_salary_gross_to_net is never named as the alternative for the opposite direction.

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 description's job is to add calculation context — and it does, laying out the full pipeline (position salary, category, supervision, notebook checks, rural/master supplements, then OPV/VOSMS/IPN withholdings to net) and disclosing that the cabinet-manager rate is 'not confirmed against a primary source'. It does not cover output shape or rounding/output-schema behavior, which keeps it out of 5 territory.

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 calculation flow are front-loaded, which is good, but the body is one enormous run-on paragraph enumerating every enum id inline. Given that the schema defers to the description, the content is largely earned, yet a bulleted or grouped structure would be far more scannable — as written it is bloated prose.

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, single-shot calculator, the description covers the model inputs, supplement logic, and the gross-to-net stages so an agent understands what it is invoking. The main gap is that it never states what the returned result contains numerically (rate breakdown vs. a single figure), forcing the agent to infer the output.

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 nominally 100%, but the schema descriptions for experience_id, category_id, curator_id and notebook_check_id simply say 'see tool description' — so the description is the only place the enum semantics live, and it supplies every id with its Russian label and percentage rate. That is genuine added value, though parameters such as lang, weekly_hours, standard_hours and is_small_class get no elaboration beyond their 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?

States a specific verb and resource ('Calculates the monthly salary of a Kazakhstan state-school teacher in 2026') plus the legal basis (Decree No. 1193, Law 'On the Status of the Pedagogue'). This clearly distinguishes it from the generic siblings kz_salary_gross_to_net and kz_salary_net_to_gross, which do not model teaching supplements.

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 operational usage guidance: the id-based options 'are fixed ids; ask the user which applies and do not guess', which tells the agent how to source parameter values. It does not explicitly say when to prefer this over the generic gross-to-net siblings, so it stops short of full when/when-not 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 readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavior beyond that: the tool is a pure computation whose output is a deadline plus informational working-day-adjusted deadline and two amounts, and it constrains inputs (2026 delivery date). It does not, however, discuss edge behavior such as what happens when the 7-day window falls on a holiday or how the amounts are rounded.

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, constraints and outputs come first, and the catalog enumeration follows in a single dense block. It is long, and the id list partially duplicates the schema enum, but each entry adds legal-article and MRP context that the enum alone does not provide, so the length is largely earned.

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 return-value burden and does so by naming the four computed outputs. Inputs, exclusivity rule and the 2026 constraint are all covered. Minor gaps remain around rounding, currency/tenge units and the year-validation failure mode, but nothing an agent needs to invoke 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 the baseline is 3, but the description adds genuine meaning the schema lacks: it spells out what each violation_id means in Russian/Kazakh with the governing КоАП article and MRP multiple, explains the either/or relationship between violation_id and custom_mrp_multiple, and ties delivery_date to the 2026 restriction.

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: 'Calculates the deadline and amounts for paying a Kazakhstan administrative (traffic) fine with the 50% discount'. It also enumerates exactly what is computed (strict deadline, informational deadline, full/discounted amounts, remaining days), which unambiguously separates it from the sibling kz_* calculators, none of which deal with traffic fines.

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 input rules are given: 'Give either violation_id from the catalog or custom_mrp_multiple (fine size in MRP), not both' and 'Delivery date must be in 2026'. That is real routing guidance for the agent, though there is no explicit statement of when to prefer this tool over the (non-overlapping) sibling calculators.

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