日本の給与・社会保険・労働法

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

With no annotations provided, the description carries the full disclosure burden, and it does substantive work: it reveals handling of substitute holidays, 国民の休日, one-off imperial events, and the bank calendar's Dec 31-Jan 3 closure — behaviors un-inferable from the schema. It stops short of disclosing return shapes or out-of-range behavior, which keeps it from 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 dense paragraphs with the core operations front-loaded; the later sentences justify edge-case coverage and the calendar default rather than repeating schema content. Each sentence earns its place, though the rhetorical 'awkward years' clause is slightly expansive.

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 four-operation tool with no output schema and no annotations, the description leaves the return side unspecified — what 'check' classifies a date as, what 'list' emits, and how count/shift results are shaped. The 'list' operation is absent from the prose entirely. Inputs are well covered, but the output side and per-operation behavior have clear gaps.

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, and the description need only add value beyond the schema. It does so for the least obvious parameter, 'calendar', explaining what 'bank' means (statutory calendar plus year-end closure) beyond the schema's bare 'Defaults to standard.' This is meaningful added semantics for exactly the parameter an agent would be unsure about.

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 first sentence names the resource (business days) with three specific verbs (count, shift, check), and the coverage statement (1955-2027) plus the calendar distinction pins down the tool's scope precisely. The prose omits the fourth operation 'list' (which appears only in the schema enum), a small completeness gap. No sibling tool performs date arithmetic, so differentiation is not a concern.

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 concrete guidance for the main mode-selection decision: when to set calendar='bank', with a legal reference (銀行法施行令第5条) and a practical use case ('relevant for payment due dates'). It sets expectations about the covered year range (1955-2027), which implicitly bounds applicability. No sibling tools are named, but the sibling set is entirely monetary/payroll calculations, so there are no real alternatives to route between.

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 no annotations, the description carries the full burden and does so thoroughly: it discloses the cumulative health-insurance cap (5,730,000 from 1 April to 31 March), the per-payment pension cap with no annual total, order-dependent filling, and the income-tax simplification. It even describes the returned rows ('what was counted, whether it was cut, and how much of the year remains').

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 long but every sentence earns its place: purpose, alternative, legal caps, ordering, output semantics, and exclusions are each in their own focused section. It is front-loaded with the core purpose before the complexity.

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 calculation with no output schema and no annotations, the description is complete: it covers the core formula, statutory limits, ordering rules, tax treatment, and the shape of the result. The schema already covers the remaining parameter details, so nothing essential is left to the agent to guess.

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 high (82%), so the baseline is 3; the description adds real semantics for the bonuses array by insisting on payment order and cap-filling behavior, and clarifies that income tax is monthly_salary times twelve. It does not need to re-explain the well-described parameters, though it could have tied prefecture and workers_comp_type into the annual-cost narrative more explicitly.

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 opening sentence states the exact computation — 'What one employee costs an employer over a year, bonuses included' — with a specific resource and scope. It differentiates itself from naive payslip multiplication and from sibling tools by naming calculate_bonus and calculate_year_end_adjustment as separate concerns.

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 explicit when-to-use guidance: 'Reach for this rather than multiplying a payslip by twelve' and explains why. It also routes bonus withholding to calculate_bonus with include_tax and year-end adjustment to calculate_year_end_adjustment, telling the agent to avoid presenting the result as 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 no annotations, the description carries the full burden and discloses non-obvious behavior: premiums are based on 標準賞与額 truncated to thousands, health/long-term care/child support cap cumulatively at ¥5,730,000 while pension caps per payment at ¥1,500,000, and tax derives from the previous month's pay rather than the bonus. It also surfaces the dependency on fiscal_year_to_date for the annual cap, which is exactly the kind of hidden calculation nuance an agent needs.

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 compact paragraphs front-load the purpose, then give the two core calculation rules (premium caps and tax basis) in order of importance. Every sentence carries necessary information; the 'routinely got wrong' warning is the only editorial addition and it reinforces why the tool exists.

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 calculation tool with no output schema, the description covers the hard decision points: when to pass fiscal_year_to_date, when to set include_tax, and how the caps differ. It does not describe the return shape, but the input schema supplies parameter-level details such as as_of refusal behavior and the birth_date rule, so the agent can invoke 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 already 91%, so the baseline is 3; the description then adds real semantic value by explaining what 標準賞与額 means (truncation), why fiscal_year_to_date matters, and how previous_month_pay feeds tax withholding. It does not discuss every parameter, but the schema already documents age, birth_date, as_of, and column in detail.

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 identifies the tool as computing social insurance premiums and withholding income tax on a bonus (賞与), with 'Set include_tax to also compute it' confirming the calculate action. It does not explicitly name sibling tools or say 'use this instead of calculate_withholding_tax', but the bonus-specific caps and contrast with monthly pay make the scope unambiguous.

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 explicit situational guidance: pass fiscal_year_to_date whenever an earlier bonus was paid in the same fiscal year, and set include_tax when withholding tax is also needed. It does not directly state which sibling tools are alternatives or when not to use this tool, but 'Both work differently from monthly pay' implies the bonus context.

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 no annotations, the description carries the full burden and discloses substantial behavior: rate stacking (1.25 + 0.25 = 1.5), holiday having no overtime premium, the 60-hour 50% threshold, per-category rounding under 昭和63年基発第150号, and the 1 April 2023 end of the small-employer deferral. It loses a point for slightly opaque references like '従業員マイスター's pay detail' and the final instruction to 'Ask for the full name of the tool,' which is unclear rather than enlightening.

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 information is front-loaded and substantive, but the description is long and contains two extraneous asides: '2023年4月 means April 2023' and the confusing final sentence 'Ask for the full name of the tool to clarify before proceeding.' These could be trimmed without losing meaning, and they slightly muddy an otherwise well-organized explanation.

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 statutory calculation with no output schema and no annotations, the description covers the legal rates, rounding, applicability, exclusions, and how to route edge cases to calculate_payslip. It is nearly complete, but it still does not state the return shape/value of the tool, and the 60-hour threshold is described without fully specifying how the single overtime_hours parameter carries hours above 60.

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 describes all six parameters. The description adds value beyond it by clarifying what base_monthly_pay should and should not include ('a premium is not an allowance, so include it'), explaining that overtime_hours excludes holiday work, and describing the rate logic that determines how the hour categories interact.

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 first sentence names a precise verb and resource: 'Works out statutory premium pay under 労働基準法第37条 — overtime, night work and work on a statutory holiday.' It names the legal basis and the three covered categories, and later points to calculate_payslip for a different scope, which distinguishes it from a key sibling.

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 an explicit routing rule: 'If you need amounts after a mid-month entry or leaving, use calculate_payslip...' It also states applicability ('Applies to all periods in employment since 1 April 2023') and exclusions ('Does not determine work rules or agreements'), so an agent knows 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly reveals deterministic run_id derivation, that nothing is stored so retries cannot duplicate a run, and that partial failures return errors with index and id while the rest of the run completes. These are non-obvious behaviors essential for safe invocation.

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 in the first sentence. Each subsequent paragraph earns its place: usage triggers, parameter strategy, error semantics, and idempotency. It is detailed but not bloated, with no redundant sentences.

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 batch tool with no output schema and no annotations, the description covers the essential operational context: what the return totals are, how run_id behaves across retries, how partial errors are handled, and how to organize the input. Nothing an agent needs to call this correctly is left unclear.

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 meaningful guidance beyond the schema by advising users to put shared values in defaults (prefecture, business_type, column) and only differing values per row, and by explaining how errors reference row index and id. This elevates the guidance without needing to restate every field.

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 specific verb and resource: 'Runs calculate_payslip for many employees in one call and returns the run totals.' It further clarifies the unique value (gross, employee deductions, net, employer cost) and differentiates itself from the single-employee sibling tool calculate_payslip.

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 states when to use the tool: 'Reach for this the moment more than two or three people are in play.' It also explains why the alternative (asking one employee at a time) is inadequate, and provides guidance on structuring inputs via defaults, making the decision context complete.

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 no annotations, the description carries the full burden and succeeds: it discloses the 標準報酬月額 step-function basis, the actual-salary basis for employment insurance, half-down rounding, the grade-32 pension stop, the 40-64 long-term care condition, and that income tax is derived after social insurance. These are non-obvious behaviors an agent must know 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?

Three purposeful sentences: the scope/result, the instruction to prefer the tool, and the key computation rules. It is front-loaded with the most important information and every sentence earns its place given the tool's complexity.

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 lists the output components and the crucial calculation rules, and the schema's per-parameter descriptions are rich enough to fill remaining invocation details. It lacks an explicit output shape and sibling routing, but those are not fatal given the schema's quality.

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 meaningful cross-parameter logic: premiums use standard remuneration while employment insurance uses actual salary, income tax must not be pre-deducted, and age restrictions gate long-term care. This supplements the per-parameter 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 opens with a clear subject-verb-resource: 'Full monthly deduction breakdown for one employee' and enumerates components, including employer share. It implicitly distinguishes this from siblings like calculate_bonus or calculate_payroll_batch by saying 'monthly' and 'one employee,' but it never names an alternative or states what it is not.

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 this rather than computing it yourself' and 'do not pre-deduct it' give some usage direction. However, with many payroll siblings, the description provides no explicit when-to-use versus alternatives (e.g., withholding-tax-only, bonus, or batch payroll).

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 no annotations, the description carries the full burden and discloses important behaviors: taxable amount is after social insurance, the daily 丙 column makes no dependant adjustment, and the computer method can differ by a few yen. It does not describe the return format, but this is a pure calculation tool with no side effects.

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 paragraphs front-load the core purpose and most critical caveat before the selection instructions. Every sentence provides useful guidance without 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?

The description is strong on period/method selection and the after-social-insurance rule, but it leaves out the meaning of 甲 vs 乙, the semantics of dependants, and what the tool returns. With no output schema and no annotations, those are notable gaps for a six-parameter tax 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 83%, so the baseline is 3, but the description adds value by clarifying the after-social-insurance taxable amount, the daily-table 丙 exception, and the possible difference between table and computer methods. The dependants parameter is still not explained.

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 operation and resource: calculating income tax to withhold from a payment using National Tax Agency tables. This clearly separates it from payroll siblings such as bonus or year-end adjustment calculations.

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 explicit selection instructions for period (monthly vs daily) and method (table vs computer), including when the computer formula applies. It does not name sibling tools to exclude, so it misses explicit when-not-to-use 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?

With no annotations provided, the description carries the behavioral disclosure burden and does it well: it states what the tool returns, that it does not assume unprovided inputs, that high earners are rejected, and that certain deductions are excluded. It could add more about error handling or whether the operation is purely computational, but the disclosed behavior is substantial.

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 long because the tool is complex, but the first paragraph front-loads the overall purpose and output, while the second paragraph delivers crucial boundary conditions. Every sentence adds information; the only minor issue is the dense enumeration of deductions, which partially duplicates schema content.

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 16-parameter tool with no annotations and no output schema, this description is remarkably complete: it defines the return value, scope, exclusions, assumptions, and edge cases such as the 20,000,000 yen threshold. The input schema covers the remaining parameter details, so an agent has enough context to invoke 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 coverage is 81%, so the baseline is 3, but the description adds meaningful parameter-level context: pay and withheld figures are for the whole calendar year, only declared values should be passed, and the tax_return block is explicitly clarified as not part of 年末調整. This goes beyond the schema's property descriptions and helps the agent pass values correctly.

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 makes the tool's function clear: it performs Japanese year-end adjustment for 2026 and returns every box of the 源泉徴収簿 plus refund/collection status. It is specific about scope and contents, though it does not explicitly differentiate itself from sibling tools like calculate_withholding_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 second paragraph gives practical usage constraints: pay must cover the whole year including bonuses, only declared amounts should be passed, the tool does not assume family/insurance status, 20,000,000 yen or more is outside scope, and medical/donation/casualty-loss deductions belong to a tax return. This is strong guidance, but it does not name alternative sibling tools explicitly.

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 no annotations, the description carries the burden of behavioral disclosure. It explains that the tool reports coverage periods and revision due dates and warns why stale data is dangerous, but it does not state whether the operation is read-only, describe response shape, or mention any side effects—though 'reports' implies a read operation.

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 three well-structured sentences: rationale, core capability, and use triggers. The risk framing is slightly verbose but earns its place by telling the agent why freshness matters, and the key capability is clearly stated.

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-parameter reporting tool with no output schema, the description is complete: it states what the tool returns (current coverage and next revision date) and when to call it. 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?

The tool has zero parameters and the schema has 100% description coverage, so there are no parameter semantics to add. The baseline 4 applies because no parameter documentation is needed.

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 an exact action and object: it reports what every dataset currently covers and when the next revision is due. The opening also grounds the tool in the fixed-date revision calendar, making it distinct from sibling calculation/rule tools such as get_insurance_rates or get_minimum_wage.

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 explicit triggers: call before relying on a figure for a filing, and whenever a result is checked near one of the revision boundaries. It does not list exclusions or alternatives, but the use cases are concrete enough for an agent to choose this tool.

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

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

With no annotations, the description carries the burden of behavior disclosure. It reveals the key rule and outcome (whether the month's premium is owed), which is behaviorally important, but it does not explain the return format, whether both employee and employer premiums are addressed, or edge-case handling such as mid-month entry or missing dates. A 3 is fair because the core deterministic rule is transparent, yet implementation details remain opaque.

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 heavily front-loaded with a compelling warning and a concrete example, then ends with the directive. Every sentence serves a purpose, though the opening 'single most expensive month-end mistake' framing is somewhat repetitive of the title's subject. It is not bloated and reads quickly.

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 judgment tool with three self-explanatory parameters and no output schema, the description explains the core rule, gives a concrete edge case, and tells the assistant to always delegate to it. It leaves out the exact return value shape, but the absence of an output schema and the simple yes/no nature of the judgment make this a minor gap rather than a serious one.

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 all three parameters well. The description adds emphasis that left_on is the last day actually worked, not the day after, which is a valuable semantic correction beyond the schema. However, it does not clarify the interplay between joined_on and left_on, such as when both are supplied for someone joining and leaving in the same month, so it only modestly exceeds the schema baseline.

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 this tool judges insurance premium liability for joining/leaving months in Japanese payroll, and the unusual rule is spelled out. Its title '入社月・退社月の保険料の要否' plus the description of 'Coverage ends the day AFTER the last day worked' makes the purpose unmistakable and distinct from sibling tools that calculate amounts or rates.

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 explicitly tells the assistant this is the authoritative check for the single most expensive month-end mistake and says 'Always check here rather than reasoning it out.' This both establishes when to use it (whenever judging premium liability for months around joining/leaving) and effectively excludes guessing/memory or alternative calculation 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?

With no annotations, the description carries the full burden and does a strong job: it distinguishes maternity vs childcare rules, discloses the 14-day rule, explains bonus premium exemption conditions, and highlights two counterintuitive edge cases. The main gap is that it never states what the tool returns—whether it outputs exempt months, booleans, or premium types—and it does not address how leaves spanning October 2022 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?

Four dense sentences pack the key distinctions, the 14-day rule, bonus conditions, and two high-value edge cases with no filler. The structure front-loads the core contrast and then lists the counterintuitive results, making it easy to absorb, though it is slightly longer than strictly necessary.

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 regulatory topic with no output schema and no annotations, the description covers the main rules and gotchas well, which is valuable. However, it omits the return value shape, does not explain how to interpret results, and ignores the 'worked_days' parameter, leaving an agent to guess about the tool's output and optional inputs.

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 adds real meaning for 'kind' by contrasting maternity vs childcare behavior and for 'start'/'end' by describing edge cases like a single day on the last day of a month. It does not mention 'worked_days' at all, but the schema already documents that parameter clearly, so the description still adds net value.

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 title '産休・育休の保険料免除月' and tool name 'check_leave_exemption' clearly indicate the tool checks insurance premium exemption months for maternity/childcare leave, and the description reinforces this by explaining the rules that govern those exemptions. However, the description never explicitly states 'returns the exempt months' or 'checks eligibility', relying on inference from the name and title. It also does not differentiate the tool from its siblings like check_insurance_eligibility.

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 this tool is used when determining insurance premium exemptions for maternity/childcare leave, and it explicitly warns that employment insurance is never exempt, giving a clear boundary. It does not name any alternative tools or state when to prefer them, and the usage context is only implied through the rule explanations rather than direct 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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the income-tax versus social-insurance asymmetry, gives a concrete salary example, sets the 150,000 cap, explains distance and parking rules, and warns against memory-based answers because of two revisions—even stating the direction of the likely error.

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, then builds through the key asymmetry before addressing limits, distance rules, and revision warnings. Each sentence carries necessary information, including the concrete example and the explicit instruction not to rely on memory.

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 four-parameter tool with no output schema and substantial legal complexity, the description is complete: it covers both calculation bases, the ceiling, distance thresholds, parking, retroactivity, and how to read the current table. Nothing needed to select or invoke the tool correctly is missing.

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

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

Although the schema documents all four parameters, the description adds critical semantics: nothing is exempt under 2 km, parking adds up to 5,000 to the distance band, public-transport and vehicle calculations combine and are capped at 150,000, and omitting the amount reads the whole table. This materially improves correct invocation.

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 precise verb-resource pair: it works out how much of a commuting allowance escapes income tax and states the amount still counted for social insurance. It further distinguishes itself from generic payroll/tax tools by stressing the two different bases and warning that a single figure must never serve both.

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 clear context for use: computing the income-tax exemption and social-insurance inclusion of a commuting allowance, including when to call with no arguments to read the current table and both revisions. It does not explicitly name sibling alternatives or when-not-to-use conditions, but the scope 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?

With no annotations, the description carries the full burden and does so well. It discloses the rate-change history (3% → 5% → 8% → 10%), the reduced rate's start date of 2019-10-01, the back-dating rule for invoices and credit notes, and that history mode returns changes with statutes. These are meaningful behavioral traits beyond what annotations would likely 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?

Three dense sentences with no filler. The core function is front-loaded, and the second and third sentences provide behavioral context that an agent actually needs rather than repeating schema content. Every sentence 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 5-parameter tool with no annotations and no output schema, the description covers the key behaviors: date-specific rates, reduced-rate eligibility, optional tax computation, and history mode. Minor gaps remain around the exact output shape when `amount` is passed and what happens if both `date` and `as_of` are provided, but these are not critical for basic 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 the baseline is 3 because the schema already documents all five parameters in detail. The description adds useful semantic context for `date` (back-dating matters more than expected) and `history` (returns changes with statute), raising it above baseline. It does not add much for `as_of` or `amount`, which are already well covered by 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 first sentence clearly identifies the resource as the Japanese consumption tax rate in force on a date, including national/local split and the reduced 8% rate. This distinguishes it from the payroll and insurance sibling tools. It lacks an explicit verb like 'returns', but the functional intent is unmistakable.

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 concrete usage context: back-dated invoices and credit notes against old sales should use the original transaction date, and it warns that date matters more often than people expect. It does not name alternatives or explicitly state when not to use the tool, so it falls short of perfect 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It does well by explaining that sub-threshold months drop out entirely rather than counting as zero, that carry-over follows 保険者算定, and that short-time workers have a unique 15-day intermediate step. It does not describe the overall return structure, but the schema partially covers some outputs.

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 concise and front-loaded, with the core purpose stated first and edge cases in a compact second paragraph. Every sentence adds meaningful content, though the density of Japanese terms may make it slightly harder to parse quickly.

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 tool's complexity, the description covers the most important traps and exceptions. The lack of an output schema is partly mitigated by the schema's rich parameter descriptions, which mention response behavior such as naming the carried-over grade and returning how long a determination applies.

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 itself adds only a small hint about acquired_month and does not need to repeat parameter details already fully 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?

The description clearly identifies the tool as the yearly redetermination of standard remuneration, effective September through August. It distinguishes itself from related concepts like 随時改定 by noting that the 15-day fallback exists only in 定時決定.

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 context on when this annual determination applies and even warns about a common mistake with payment-basis-day thresholds. It implies the distinction from monthly revision rules, but does not explicitly name alternative sibling tools such as judge_monthly_revision.

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 no annotations provided, the description carries the full burden and does so well: it discloses null-vs-false semantics for previous_remuneration, the meaning of to_file/not_required totals as forms rather than employees, partial-failure behavior (bad rows go to errors with index and id while the rest completes), and legal exclusions. The warning 'do not discard a whole run over one bad row' is exactly the kind of behavioral guidance an agent needs.

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 longer than average but every sentence earns its place: the legal context motivates the batch shape, the usage rule is front-loaded, and the remaining paragraphs cover optional-parameter effects, totals semantics, and error handling. The structure is logical and dense without 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 no output schema exists, the description covers the return contract well: per-row judgement inherited from decide_regular_remuneration, grade-change flag, filing totals, and errors with index/id. However, the exact per-row field names and the role of the defaults object in overriding employee rows are not explicitly addressed, leaving a minor gap for a tool of this 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 coverage is 100%, giving a baseline of 3, but the description adds significant behavioral meaning beyond the schema: previous_remuneration's null-vs-false distinction, how acquired_on/left_on/revision_month influence whether an employee is filed, and what the aggregate totals mean. This substantially enriches the raw parameter 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?

The first sentence states a specific verb and resource: 'Runs the annual 定時決定 for a whole payroll in one call, and reports which employees moved grade.' It clearly distinguishes the batch tool from the singular sibling decide_regular_remuneration by framing single-employee queries as 'the wrong shape for the task.'

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 guidance is provided: 'Reach for this the moment more than a couple of employees are in play.' It also tells when each optional parameter matters (previous_remuneration for grade comparison; acquired_on, left_on, revision_month for filing status), and contrasts with the one-at-a-time alternative.

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 no annotations, the description carries the behavioral burden and discharges most of it: it flags estimate uncertainty, states that the municipality decides the amount and the employer deducts per the 特別徴収税額通知書, and instructs the agent to communicate that. It also states the fiscal-year mapping for income_year and validates accuracy against published examples, though it does not describe return shape or behavior for unsupported input combinations.

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 purpose is front-loaded in the first clause, and nearly every subsequent clause carries a specific tax rule or caveat, so there is little waste. The density is high and the single run-on paragraph is harder to scan, which keeps it from a 5 for a tool with this many parameters.

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 26-parameter tax calculator with no annotations and no output schema, the description is unusually complete: it covers the main formula, prefecture surtax exceptions, city rules, the estimate caveat, and key inputs like income_year and grade_level. It still leaves some operational details, such as exactly what is returned and how unknown municipalities are handled, to the schema or the agent, so it is not a 5.

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 54%, and the description adds meaningful tax semantics beyond the schema: deduction amounts and caps, the 10% levy split with special rules for designated cities, the non-taxable threshold formula with 級地, furusato credits capped at 20%, and city-specific rules. It does not mention all 26 parameters, but it enriches the high-impact ones without contradicting 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 opens with 'Estimate of next fiscal year's resident tax (住民税: 道府県民税 + 市町村民税 + 森林環境税) from the previous year's income and the municipality', naming a specific verb, resource, and input basis. It distinguishes this tool from income-tax siblings by itemizing resident-tax components and even cites matching published worked examples.

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 context for when the tool applies: estimating the next fiscal year's resident tax from the prior year's income and municipality, with the explicit 'It is an ESTIMATE' caveat and the instruction to 'Say so.' It does not explicitly name alternatives or state when-not-to-use it, so it stops short of a 5, but the context 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively does so by revealing the non-obvious legal computation rule: an age is reached the day before the birthday, with a concrete example for people born on the 1st of a month. This is genuinely useful behavioral context beyond what the schema could 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 compact and front-loaded: the first sentence states the core output, and the second paragraph adds a necessary legal nuance that directly affects correctness. Every sentence earns its place, with no fluff or 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?

For a simple two-parameter, pure-computation tool with no output schema, the description is complete: it states what is returned (exact dates and premium start/stop), covers all relevant thresholds, and warns about the legal edge case. An agent has enough information to invoke it correctly and interpret its 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 the baseline is 3. The description references birth dates in its example but does not add extra meaning about the as_of parameter or the expected date format beyond what the schema already provides. The schema handles parameter semantics adequately.

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 specific verb and resource: 'Returns the exact date each threshold is crossed and which premium starts or stops.' It lists the exact age thresholds (40/65/70/75) and what happens at each, making the tool's purpose concrete and distinguishable from sibling calculation tools like get_insurance_rates or national_insurance.

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 direction: 'Compute this here rather than by subtracting years.' It explains why this tool is the correct choice by citing the 年齢計算ニ関スル法律 rule. However, it does not explicitly name alternative sibling tools or state when those should be preferred, so it falls just 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?

With no annotations provided, the description carries the full behavioral burden. It discloses that health rates differ by prefecture and change each March, pension is national, employment insurance changes each April, FY2025 and FY2026 are held, and an out-of-coverage date returns out_of_coverage rather than a guess. The March crossover nuance is especially valuable.

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 one dense sentence that front-loads the full list of outputs before explaining timing and parameter conditions. Every clause contributes a distinct fact, and while it is long, the complexity of the rate-year interactions justifies the length.

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 that no output schema exists, the description thoroughly covers the query space: available rates, prefecture dependence, national pension, employment-insurance bands, as_of fiscal-year behavior, and the March mismatch. The only notable gap is that it does not describe the exact response structure or field names.

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 adds meaningful context beyond the schema: business_type triggers employment insurance rates, as_of selects the in-force rate on that date, and the fiscal-year timing interplay between health and employment insurance is clarified. This is more than the schema provides 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 clearly enumerates what the tool returns: health insurance, long-term care, pension, child-support rates, bonus caps, and the employer-only child-care contribution. It is specific about scope and distinguishes this from obvious siblings like get_minimum_wage or list_workers_compensation_rates, though it does not explicitly name 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?

The description gives concrete usage guidance: add business_type for employment insurance rates, pass as_of to select the rate in force on a date, and be aware of the March crossover between health and employment insurance years. It does not explicitly state when not to use this tool or name alternative tools, but the parameter-driven conditions are clearly explained.

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 no annotations, the description carries the full disclosure burden, and it discloses the tool's central behavioral trap: returned rates are effective-date-dependent and vary per prefecture, so a stale assumption would yield wrong results. It also sets data-coverage expectations ("History runs back to FY2002") for time-travel queries. The only unaddressed trait is return shape, partly mitigated by the "Hourly" qualifier.

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, each earning its place: purpose, temporal usage warning, and data coverage. The most important caveat (date sensitivity) is front-loaded immediately after the purpose statement. No filler, no restatement of schema fields.

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 straightforward lookup with 100% parameter documentation and no output schema, the description covers purpose, the revision-timing trap, and historical depth — sufficient for correct invocation. Minor gaps are the unstated read-only/safety profile (no annotations) and no return-value description, both low-risk given the "get_" prefix and simple hourly-rate nature.

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 each parameter is already documented with format and default behavior (e.g., date defaults to the currently enforced rate; prefecture accepts English, Japanese, or JIS code). The description enriches the date parameter by explaining why it matters and ties the history parameter to the FY2002 range, but the schema does the heavy lifting — baseline 3 with modest added meaning.

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 opening sentence names a specific resource — "Hourly 地域別最低賃金 for a prefecture" — with a clear lookup verb and scope, and the title's "(指定日時点)" adds the as-of-date qualifier. It is easily distinguished from siblings like get_insurance_rates and get_statute_text by domain, though it never names an alternative explicitly.

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 concrete operational guidance: "pass one when checking a past payroll rather than assuming the current rate applied," backed by the reason (revisions take effect prefecture by prefecture from October on different days). This tells an agent exactly when the optional date is effectively required, though it does not name alternative tools or state exclusion conditions.

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?

No annotations are supplied, so the description carries the full burden. It discloses the limited bundled set ('about 28 across 8 laws'), the behavior of calling without a ref, resolution of abbreviations and missing 第, paragraph-level references resolving to the article, and the expected behavior for references outside the set. This is strong behavioral disclosure.

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 action and stays relevant throughout. The motivational sentence about checked citations is useful context but slightly expands length; overall every major point earns its place without being bloated.

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 one-parameter, no-output-schema tool with no annotations, the description is operationally complete. It covers what the tool returns, how to enumerate available provisions, how references are normalized, and how to handle unsupported citations. An agent can invoke this tool correctly without further inference.

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?

Although the schema already describes ref, the description adds significant meaning: it documents omission semantics, gives practical abbreviation examples like 健保法43条 and 厚年法81条の2, clarifies that a missing 第 is tolerated, and states that paragraph-level references resolve to the article. This goes well beyond the schema's minimal description.

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: 'Returns the full text of a Japanese statutory provision, as published by e-Gov.' It also distinguishes itself from the judgement tools, which name a statute but do not provide its words, making it clear this tool is for retrieving quotable statutory text.

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 explicitly says when to use the tool: 'Use this to quote the provision itself.' It also sets boundaries by noting the bundled corpus is limited, telling the agent to 'call it with no ref to list them,' and instructing that anything outside the set should be acknowledged rather than invented.

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 no annotations, the description carries the full burden and handles it well. It reveals that the 随時改定 result is not a plain twelve-month average, explains the fixed/non-fixed split, mentions that three grade tests must pass, and discloses that the tool cannot verify consent or recurrence and merely echoes those declarations back.

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-organized: use case first, then route-specific logic, then requirements and limitations. Every sentence contributes information, and there is no filler or 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?

For a complex tool with seven parameters and no output schema, the description covers the core conditions, formulas, route differences, and input verification. The main gap is that it never explicitly states what the response contains beyond echoing the consent and recurring-annually inputs, such as whether the computed grade 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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining the mixed-average formula, the separate treatment of fixed and non-fixed pay, and the significance of consent and recurring_annually as mandatory echoed inputs. The schema already documents most property-level meaning though.

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 action: compute the annual-average insurer grade for seasonal work, and distinguishes the two supported routes (定時決定 and 随時改定). It clearly separates this from the ordinary calculation that would produce a wrong grade for most of the year.

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 explicitly tells when to use the tool: when April-June is the busiest or quietest quarter and the ordinary calculation would fix an incorrect grade. It also gives when-not conditions, such as a one-off busy period, and states the mandatory consent and recurring-annual-swing requirements.

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 no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly: it explains the legal thresholds, the part-time switch at 30 hours, carryover and lapse rules, and the fallback when attendance_rate is omitted — reporting the 80% test as not judged rather than assuming it passed.

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: purpose, legal rule, part-time exception, obligation/carryover, and attendance handling each get a focused paragraph. No sentence is filler, and the core purpose is front-loaded.

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?

Despite having no output schema, the description states the two result dimensions clearly: granted days and whether the five-day obligation remains. It also covers the main input-relationship pitfalls, missing-data behavior, and legal context needed to call the tool correctly for a complex 7-parameter judgment.

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%, but the description greatly enriches parameter meaning: weekly_hours at or above 30 overrides day count, weekly_days and weekly_hours must be judged as a pair, attendance_rate is evaluated against 0.8, and days_taken count against the five-day obligation. This goes well beyond the baseline for a fully documented 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 opening sentence specifies two concrete outputs: how many paid-leave days were granted and whether the employer still owes the five days it must direct. This is a clear verb+resource statement that distinguishes the tool from siblings by naming its legal scope.

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 explicit invocation guidance: ask for weekly days and weekly hours together because neither alone settles the part-time determination, and request attendance as a pre-calculated rate rather than a raw day count. It does not name alternative tools or state when not to use this one, so it stops 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?

No annotations are provided, so the description carries the full burden, and it delivers: it discloses that fixed pay need not change, that only one of three months must meet the threshold, that missed months are excluded from the average, that the employee must apply, and that the tool is unavailable when another leave starts immediately after. These are substantive behavioral details beyond what the tool name or schema alone would 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 dense but efficient: the core differentiator from 随時改定 is front-loaded, and each rule earns its place. The phrase 'the one people forget' is mildly non-essential but reinforces usage context. Overall it is well-structured for its informational load.

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 and schema together cover invocation conditions and parameter meanings well. However, there is no output schema and the description never states what the tool returns — whether it is a boolean decision, a revised grade, or a calculation result. For a 5-parameter tool with no annotations and no output schema, that is a meaningful completeness 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 description coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema by explaining that months missing the threshold are excluded from the average and that fixed-pay changes are irrelevant. This enriches the semantics of the 'months' and 'current_remuneration' parameters rather than merely restating them.

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 identifies the resource: leave-end revision (産休・育休終了時改定) and its defining condition — one grade of movement is enough. It distinguishes this route from 随時改定, so an agent can tell it apart from sibling tools like judge_monthly_revision. However, it never explicitly states the action verb such as 'judges' or 'determines whether,' relying on the tool name and title for that.

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 a concrete trigger: returning to shorter hours cuts pay without changing a rate, so 随時改定 would not fire — this tool is the lower-bar alternative. It also states the one-of-three-month rule and the next-leave exclusion. It stops short of explicitly naming the sibling tool or saying 'use this instead of X,' but the comparison to 随時改定 is clear enough.

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 no annotations, the description carries the full burden, and it does so exceptionally well: it reveals the separate health/pension answers, the ~665,000 yen pension ceiling, the ministerial-notice legal source, the overtime exclusion, and the failed-requirement explanatory output. This goes far beyond the structured fields and gives an agent real insight into tool 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?

The core three paragraphs are front-loaded and information-dense, but the sentence 'When the answer is no, the response says which requirement failed rather than just false' is repeated verbatim dozens of times. This severe redundancy obscures the otherwise good structure and wastes significant token budget.

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 no-output-schema decision tool, the description covers the legal basis, key exceptions, scope, and failure-reporting behavior, while the input schema supplies parameter details. The main gap is an exact description of the output shape for a 'yes' or mixed health/pension answer, but the domain behavior is otherwise sufficiently complete.

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 the months format, worker_type thresholds, fixed_pay_change meaning, and the current_remuneration actual-pay caveat. The description adds useful domain context but no new input-format or parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The first sentence clearly names the exact decision ('whether a pay change forces the standard remuneration to be revised'), the resource (standard remuneration), and the separate health/pension scope. It does not explicitly name sibling tools or state what it is not, so it falls short of the strongest differentiation, but the function is unambiguous.

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 the trigger ('a pay change') and the decision context (monthly revision), and it warns against attempting the reasoning unaided. However, it never says when to prefer judge_annual_average, decide_regular_remuneration, or another sibling, and it gives no explicit exclusions or alternatives.

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 no annotations provided, the description fully carries the behavioral disclosure burden. It reveals that missing monthly days or an unclear workplace count yields 未判定, explains the short-term exception, student exemption nuances, and clarifies how counts are interpreted. It also warns that a wrong classification silently produces a wrong downstream answer.

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 purpose and invocation order, and the paragraphs are thematically organized. It is long, but the legal complexity justifies much of the length. It loses a point for some redundancy around the 51-person rule and a few vague or awkward sentences, such as 'the one-word rules may be right, but the reason is what the tool will ask about later.'

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?

Despite having no output schema and no annotations, the description is remarkably complete for a complex legal decision tool. It covers legal thresholds, exceptions, parameter meanings, failure behavior (未判定), when to call downstream siblings, and which rules are outside scope. The only minor absence is an enumeration of exact worker_type return values, but this is not essential 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?

The schema already covers all 8 parameters, but the description adds substantial legal meaning: monthly_wage is 所定内賃金 excluding allowances such as overtime, commuting, and bonuses; monthly_days is required for the three-quarter test; workplace_insured_count refers to 健康保険 insured people, excludes the person being judged, and has special 501-person thresholds; employment_months triggers the short-term exception.

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 first sentence states a specific action: deciding insurance coverage and the payment-basis day count for annual determination. It also distinguishes itself from siblings by naming decide_regular_remuneration and judge_monthly_revision as downstream tools and by explicitly excluding the 4-hour 3-day rule.

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 explicit when-to-call guidance: before decide_regular_remuneration or judge_monthly_revision whenever the person is not plainly full-time. It also states when not to use it (the 4-hour 3-day rule) and instructs the agent to ask the user for missing facts rather than assume them.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the entire premium falls on the employer, that nothing is deducted from the employee, that rates vary widely, and how the optional parameter changes output. It does not specify output shape or the effect of as_of in detail, but this is still substantial disclosure.

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 tightly focused paragraphs with the main purpose front-loaded. Every sentence adds useful context: the premium, the rate range, why estimation is unsafe, and how to control the output.

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 3-parameter tool with no output schema and no annotations, the description covers the core invocation logic and key behavioral context well. It is slightly incomplete on as_of semantics and exact return format, but the schema plus the table/premium language close most gaps.

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 real meaning by tying business_type to the 労働保険関係成立届 and explaining the omit-for-full-table behavior. It also clarifies that wage_total is the base for the employer premium, though as_of is left to 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 that the tool lists 労災保険 rates by business type and computes the employer premium on a given 賃金総額. It is specific about the resource and behavior, and the scope is distinct from sibling tools like get_insurance_rates or national_insurance.

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 explicitly says to pass the 事業の種類の番号 from the 労働保険関係成立届 and that omitting it returns the whole table. The phrase 'this cannot be estimated' gives a clear reason to use the tool for exact rates. It does not name alternative tools or exclusion conditions, but the context is strong.

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?

No annotations are provided, so the description itself must carry behavioral disclosure. It states the output semantics, including the clamped-pension-grade flag, and clarifies the tool's scope. It does not explicitly state read-only or error behavior, but 'lookup' and 'check a grade' strongly imply non-mutating 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?

Two focused sentences with no filler. The core mapping behavior is front-loaded, and the usage distinction is placed right after, making the tool easy to scan and understand quickly.

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 covers the main return contents: health grade, pension grade, resolved standard remuneration, and clamp flag. It lacks exact response field names and out-of-range handling, but for a single optional parameter, this is nearly complete.

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 one parameter is already fully described ('Monthly remuneration in yen. Omit to get the whole grade table instead of one lookup.'). The description adds no additional parameter-level meaning 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?

Description names a specific verb ('Maps') and resource ('monthly amount' to 'health grade (1-50) and pension grade (1-32)'), and lists the returned elements. It also distinguishes itself from calculate_payslip by stating 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?

Explicitly instructs when to use it ('to check a grade') and when not to ('not to compute premiums'), naming calculate_payslip as the alternative. The schema adds another usage mode: omit the parameter to get the whole grade table.

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 no annotations, the description carries the behavioral disclosure burden. It explains that the pension contribution comes back as a number, while the health insurance contribution has no national figure due to municipal variation. It also sets expectations about what is not handled, such as exemptions and deferrals.

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 longer than minimal, but each paragraph contributes meaningful routing or behavioral information. It front-loads the target audience and the key alternative tool, and the legal context helps an agent understand why results may be partial.

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 tool with no output schema and rich legal nuance, the description covers what results to expect for pension versus health insurance, when to use it, and what it does not judge. It could be more explicit about the exact return shape, but it gives sufficient context 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 description coverage is 100%, so the schema already documents all three parameters. The description adds useful context about flat pension contributions and municipal health variation, but it does not add new parameter-level meaning 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 clearly identifies the tool's audience (self-employed, freelancers, people between jobs) and its subject matter (国民年金 and 国民健康保険). It distinguishes itself from calculate_payslip, but it never states the core action directly as a verb like 'calculate' or 'estimate' — the function is implied through phrases like 'comes back as a number'.

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 says to use this tool instead of calculate_payslip when the person is not an employee, and points to judge_worker_type when unsure. It also states that exemptions, deferrals, and special cases are not judged here, giving clear exclusion criteria.

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 no annotations provided, the description carries the full burden, and it delivers exceptional transparency. It discloses that the tool only proves well-formedness, not registration or holder identity, explains why sole proprietors can satisfy the same rule, and warns against overreporting the result. This goes well beyond the typical validation-tool description.

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 compact sentences with no filler. The core action is front-loaded, and the critical caveats follow immediately. Every sentence earns its place, including the explicit redirection to the National Tax Agency lookup.

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 is largely sufficient for a simple validation tool: it names accepted formats, states what a passing result means, warns about false implications, and names the right external alternative. Minor gaps remain: it does not mention the batch sibling, the base parameter's number-generation mode, or the return/error behavior, though the input schema covers parameter details.

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 useful context about the T prefix and the check-digit-only nature of validation, but it does not explain the base parameter's use case for computing a check digit from a 12-digit 会社法人等番号. The schema already covers this, so the description neither strongly adds nor detracts.

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?

Uses a specific verb ('Checks') and precisely identifies the resource: the National Tax Agency check digit on a 13-digit 法人番号 or a T-prefixed qualified invoice registration number. The description is clear, but it does not explicitly distinguish itself from the sibling validate_invoice_numbers_batch, and it omits the base parameter's alternative behavior of computing a check digit.

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 tells the agent when not to rely on this tool: a passing check digit does not prove registration and must not be reported as evidence of a corporation. It also points to the National Tax Agency's own lookup for registration confirmation. However, it does not mention the batch sibling tool for validating multiple numbers, which is a relevant routing gap.

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 no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly warns that a passing check digit does not mean the number is registered, explains revocation/lapse possibilities, says the register is not consulted, and details duplicate and index behavior. This is unusually transparent.

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 longer than average, but it front-loads the core function in the first sentence and organizes the rest into crucial caveats, workflow value, and result behavior. Each section earns its place, though the detail about the public site's bulk download and Web-API is somewhat tangential.

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 one-parameter tool with no output schema, the description covers the important context: what the check does and does not prove, how results are keyed, and how duplicates behave. It does not specify the exact return payload shape, but it gives enough behavioral detail for an agent to call it and interpret results safely.

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?

The only parameter, 'numbers', is already fully described in the schema with the leading T requirement and the 1000-per-call limit, so schema coverage is 100%. The description adds no new parameter-level meaning beyond what the schema already states, 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 states a specific action (checks the National Tax Agency check digit) on a specific resource (qualified-invoice registration numbers) in batch, and clearly differentiates this from the sibling validate_corporate_number tool by targeting invoice registration numbers specifically. The title also reinforces the batch scope.

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 workflow context: use this to filter out numbers that fail format checks before consulting the official register, and explains why the actual register must be consulted for real validity. It does not explicitly name alternative sibling tools or state 'when not to use', so it stops 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.