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.

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.

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.

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.

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.

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.