Skip to main content
Glama

Xearno Tools

Japan Childcare Leave Benefit Calculator (育児休業給付金 & 出生後休業支援給付金)

japan_childcare_leave_benefit
Read-only

Your childcare-leave money under the April-2025 framework: 67% (then 50%) of daily wage, plus the new +13% top-up that lifts the first 28 days to 80% gross — with the exact caps valid 1 Aug 2026 – 31 Jul 2027. Computes Japanese childcare-leave benefits: the base 育児休業給付金 (67% of your daily wage for the first 180 benefit days, 50% after) and the 出生後休業支援給付金 introduced April 2025 — a +13% top-up on up to 28 days that lifts them to 80% gross, roughly 100% of normal net take-home once the tax and social-insurance exemptions are counted. General AI still answers 67% (the top-up postdates most training data) and garbles the condition’s asymmetry: the father’s +13% is satisfied automatically while the employed mother is on 産後休業 — it is the mother’s claim that needs the father to take ≥14 days (or a waiver). Uses the caps valid 1 Aug 2026 – 31 Jul 2027 (¥16,540 daily ceiling; ¥60,205 top-up cap per 28 days); every cap revises each 1 August.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
claimantNoWho is claiming? The asymmetry general AI misses: a father’s +13% condition is satisfied AUTOMATICALLY while the employed mother is on maternity leave (産後休業 counts as waiver #6) — he only needs his own ≥14 days. The MOTHER’s claim is the one that needs the father to take ≥14 days of leave, unless a waiver applies (spouse not employed / self-employed / single parent).father
leaveDaysNoLeave days to model (days) Total benefit days you plan to take. The 67% rate runs for the first 180 benefit days (the counter includes 産後パパ育休 days), then steps down to 50%.
monthlyWageNoAverage monthly wage before leave (¥/mo) Average of the 6 months of wages before the leave starts — this sets your 賃金日額 (daily wage) = wage × 6 ÷ 180 = wage ÷ 30. Use gross pay including fixed allowances, before tax and social insurance.
bothConditionNoIs the +13% condition met? The 出生後休業支援給付金 needs your own leave of ≥14 days within the statutory window AND the spouse condition per the claimant note above (a father’s is auto-met while the employed mother is on 産後休業; a mother’s needs the father’s ≥14 days or a waiver). When met, the first 28 days pay 80% gross.yes

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. The description adds valuable behavioral context beyond annotations: that the 'father's +13% is satisfied automatically while the employed mother is on 産後休業' and that caps revise each 1 August — disclosing time-dependency of results. It does not explicitly state the return format (since no output schema exists), but the calculation logic substitution is transparent.

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

Conciseness3/5

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

The description is information-dense and front-loaded with the core calculation, but it runs long — roughly six sentences spanning several clauses about caps, the top-up, and the asymmetry trap. While every sentence earns its place (no filler), the density makes it a heavy read. The structure is effective but could be tightened by splitting the statutory/calculation facts from the 'general AI gets this wrong' guidance.

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

Completeness5/5

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

For a complex four-parameter calculation tool with 100% schema coverage, no output schema, and an obscure legal framework, the description is exceptionally complete. It covers the rate structure, the new 2025 top-up, exact cap figures with validity dates, the tax/social-insurance exemption nuance, the asymmetry trap, and the annual cap revision warning. The writeup leaves no meaningful gap a user would need clarified about the model's inputs or mechanics.

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

Parameters4/5

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 and the scheme both carry detailed param semantics — particularly for 'claimant' and 'bothCondition', where the description explains the legal asymmetry (father auto-met, mother needs father's ≥14 days) beyond the enum values. The description also clarifies what daily wage = wage ÷ 30 for monthlyWage. It adds substantive meaning beyond the schema for the tricky condition parameter.

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

Purpose5/5

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

The description opens with a clear, specific statement of what the tool computes: the 育児休業給付金 (67%/50% base) and the new 出生後休業支援給付金 (+13% top-up to 80% gross). It names the exact statutory framework (April-2025) and caps validity window (1 Aug 2026 – 31 Jul 2027), establishing a specific verb+resource+scope. Among 70+ sibling tools, it is unambiguous — no other tool addresses Japanese childcare leave benefits.

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

Usage Guidelines5/5

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

The description explicitly warns that 'general AI still answers 67%' and explains that the top-up postdates most training data, telling the agent when this specialized tool is needed over general model knowledge. It also flags the asymmetry condition that general AI 'garbles' — a clear when-to-use signal that this tool handles a trap, distinguishing it from what the model might default to.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Each tool targets a distinct niche (e.g., specific country tax rules, loan types, or legal calculations), with detailed descriptions that clarify boundaries. However, the large number of tools (66) could cause some confusion for an agent trying to select the right one for a general query, especially when multiple tools relate to the same country.

Naming Consistency4/5

Tool names follow a mostly predictable pattern: lowercase words separated by underscores, often starting with a country name (e.g., 'uk_stamp_duty_sdlt') or a topic (e.g., 'compound_growth'). There are minor deviations, such as abbreviations ('npv_irr', 'sip') and varying use of verbs, but overall the naming is clear and consistent.

Tool Count3/5

At 66 tools, the server is unusually large and covers an extensive range of financial and legal calculators. While each tool justifies its existence, the count exceeds the typical well-scoped range (3–15), making the server feel bloated. A more modular design might improve coherence.

Completeness4/5

The tool set covers a wide array of domains: personal income taxes, property taxes, loan calculations, investment returns, and specific country regulations. Minor gaps exist (e.g., missing tools for corporate taxes, general retirement planning, or insurance), but the overall coverage is thorough and addresses many niche scenarios that general AI handles poorly.

Resources