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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine policy behavior the annotations cannot: the rate bands by week range, the €125 minimum, payment from the first Monday, the 6-week application window, and that redundancy has no effect. It stops short of saying the output is a weekly schedule, though the output schema covers return values.

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?

It is a single dense run-on sentence with semicolon-separated clauses; every clause carries real policy content, so nothing is padding. The trade-off is readability: the rate bands, contribution tiers, minimum, timing and exclusions blur together, and the key scope statement is not separated from the detail.

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 10-parameter domain calculator with an output schema, the description supplies the eligibility rules, the three rate bands, the contribution-tier split, the minimum payment, and the timing rules. The remaining gaps (meaning of applyAfterWeeks, dateOfBirth, weeksPaid, redundancyLumpSum handling) are covered by full schema descriptions, so an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so all ten parameters are already documented, setting a baseline of 3. The description does sharpen a few of them — '60% of average gross weekly pay' clarifies the earnings input, the contribution thresholds clarify totalPaidContributions, and 'part-time days move to Jobseeker's Benefit' clarifies partTimeDays — but leaves weeksPaid, dateOfBirth, applyAfterWeeks and redundancyLumpSum to the schema 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 names the exact benefit (Ireland Jobseeker's Pay-Related Benefit) and states the calculation is week-by-week for a job lost on or after 28 March 2025, which lets an agent separate it from siblings like ireland_what_can_i_claim or ireland_severance_tax. It never uses an explicit verb such as 'calculate', so the action is inferred from the rate-band content rather than stated.

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?

Eligibility context is given (job lost on/after 28 March 2025, 260+ vs 104–259 PRSI contributions, apply within 6 weeks), which implies when the tool applies. However there is no explicit 'use this when…' routing versus alternatives such as ireland_what_can_i_claim, and the note that part-time days move the claim to Jobseeker's Benefit signals a case this tool does not cover but without naming a replacement.

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