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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered. The description goes beyond them by disclosing the exact computation, the monthly-to-annual conversion, and the UK fixed compensation tiers (GBP 40/70/100 by debt size), which materially affect the result. It does not describe the response shape, but the deterministic formula largely substitutes for that.

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-loads the formula and mode definitions, then the jurisdiction caveat, which is the right order. Slightly dense, and the 'Same math as revexos.com/...' sentence is a promotional reference that does not help an agent invoke the tool correctly.

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?

With no output schema and 8 parameters, the description covers the calculation logic, mode semantics, and legal caveat well. The one gap is the return shape (what fields come back, whether the fixed compensation and interest are itemized), which the agent must infer.

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 88%, so the baseline is 3, but the description adds real value: the 'mode' enum has no schema description, and the description supplies its semantics plus the rate-conversion and UK compensation rules that the schema does not. It stays silent on flat_fee/paid_date beyond what the schema already documents.

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+resource ('Simple interest on an overdue invoice') and immediately backs it with the exact formula (amount x annual rate x days overdue / 365, plus a flat late fee). The three modes are named and defined, so an agent can distinguish this calculator from siblings like calculate_invoice_due_date or calculate_proration 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?

Explains which mode to select for which scenario ('annual' contract rate per year, 'monthly' converted x12, 'uk' statutory 8% + base rate) and adds a real precondition caveat: whether interest can be charged depends on the contract and jurisdiction. No explicit routing to sibling tools or statement of when NOT to use it, so it stops short of a 5.

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