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), so the description is free to spend its words on computation behavior — and it does: payments on account, the County Court £5,000 rule and its exceptions, and leap years. The one gap is that with no output schema it never says what the call returns (interest total, breakdown, daily rate).

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 action, then qualification and the exclusion. The opening sentence is long, but every clause (rate, start-point variants, payments, £5,000 rule, leap years) carries distinct information and none is padding.

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, enum-heavy calculator with no output schema, this description supplies the legal framing an agent needs to select and feed it correctly, including the key exclusion. It stops short of describing the returned figures or units, which is the only material omission given there is no output schema to fall back on.

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 3 is the baseline; the description rises above it by explaining how start date is derived (order date, Part 36 acceptance, or court-set date) and by flagging payments on account and the County Court £5,000 test that drive the payments/otherSums/crown fields. It adds interpretive value rather than merely restating the schema's field blurbs.

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?

States a specific verb and resource ('works out simple interest ... on an order for costs in England and Wales') plus the governing regime and rate (Judgments Act 1838, 8%). An agent can distinguish it from siblings such as calculate_part_36_offer or calculate_detailed_assessment_deadlines without opening either 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?

Gives clear jurisdictional and legal context (England and Wales, Judgments Act 8%) and an explicit boundary: 'It does not decide rates where the court has a discretion.' It also enumerates the triggering events (order date, Part 36 acceptance, court-set date) that select this tool's inputs. It does not, however, name sibling calculators or say when to reach for one of those instead.

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