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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral content: figures are averaged per month before tax, three alternative split methods are modelled, and the output includes the savings the on-leave parent would need under 50/50 plus missed pension contributions. It does not mention rounding, currency handling, or unit assumptions for the annual salary inputs.

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?

Everything sits in a single front-loaded sentence with no filler or repetition; the purpose comes first and the modelled outputs follow. The semicolon-chained inventory is dense and slightly hard to parse, but it does not waste words.

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 eight-parameter read-only calculator with no output schema, the description does the necessary work: it explains what is computed, which jurisdictions are covered, and what categories of results come back (split amounts, savings requirement, pension shortfall). The remaining gap is the absence of any note on what a returned result object looks like or how leave duration interacts with top-up duration.

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 already 100%, setting a baseline of 3. The description still adds meaning beyond the schema by clarifying that pay figures are averaged per month before tax and that us-XX denotes unpaid FMLA, which the enum alone would not convey. It leaves topUp, topUpWeeks, and pensionRate to the schema, which is acceptable given the high coverage.

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 the exact computation: how a couple shares bills during parental leave, using statutory pay (with named schemes per country), employer top-up, averaged monthly pre-tax, against partner pay, across three split methods plus savings and pension shortfall. That is far more specific than a restatement of the name. It loses a point only because it is phrased as a noun-phrase inventory rather than a verb-led statement, and it never distinguishes itself from the overlapping sibling parental_leave_income_gap.

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

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

Usage is implied by the enumerated coverage (UK SMP, Ireland Maternity Benefit, Canada EI, Quebec QPIP, Australia PLP, US state schemes, us-XX for unpaid FMLA), which tells an agent which country codes are in scope. However, there is no explicit when-to-use guidance, no stated prerequisites, and no routing to or away from sibling tools such as parental_leave_income_gap or the country-specific leave calculators.

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