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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: rule versioning by start date, the 28-week cap, HMRC unrounded daily rates, transitional SI 2026/373 handling, and a rate-fetch timestamp caveat that tells the agent figures may be stale. It stops short of describing the response shape, e.g. whether the transitional rules produce a separate output field or a flag in the result.

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?

Front-loaded with the core purpose, then progressively narrower detail on rates and transitional rules; every sentence carries factual weight. It is one dense block, though, and the rate/versioning details could be broken out for faster scanning, and the fetched-on timestamp could be trimmed to a shorter caveat.

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 pure-computation tool with no output schema, the description supplies the calculation basis, both rule regimes, the cap, and the data provenance needed to trust and call it. The remaining gap is what the agent gets back (a figure alone, or a breakdown with the applied regime and transitional flag).

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 a 3 would be the baseline, but the description adds real semantics: it explains that average_weekly_earnings is used for the 80% test and that start_date selects the rule regime, both of which link inputs to computation logic. It does not elaborate on how days_off interacts with calendar_days_sick beyond what the schema says.

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?

Opens with a specific verb+resource ('Works out UK Statutory Sick Pay') for a clearly bounded scope ('for a period of sickness'). The domain is distinct from all three siblings (maternity pay, eligibility check, minimum wage rates), so an agent can route to it without opening the schema.

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 makes clear which temporal scenario selects which rule set (starts on/after 6 April 2026 vs 6 April 2025–5 April 2026), which is the key usage determinant. It does not explicitly name alternatives or exclusion cases (e.g. 'use check_eligibility first to determine qualification'), so routing against siblings is left implicit.

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