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

With zero annotations, the description carries the full burden and exceeds it: it discloses that diminishing value front-loads the deduction and never reaches zero by itself, that additional_costs capitalize into the cost base, and that salvage_value floors both methods while the last straight-line year takes only what remains so rounding cannot breach the floor. The 'ONE IMPORTANT LIMIT' paragraph adds a critical caveat that the tool is pure arithmetic, not a tax-rate authority, and warns against presenting invented rates as tax positions. No contradiction with annotations exists because no annotations were provided.

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?

The definition is long but tightly packed — purpose, routing, method divergence, edge-case behavior, the compliance limit, then Args/Returns — with the critical warning capitalized so a scanning agent cannot miss it. Every block earns its place given 0% schema coverage and no annotations, though the allcaps warning and the partial redundancy between the opening sentence and the 'Use for' list mean it could be trimmed slightly without losing value.

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 ７-parameter, two-method calculator with no annotations and no output schema, the description covers all grounds: every parameter, conditional requirements, edge-case rounding behavior, the return payload (cost base, depreciable amount, firstyear charge, total charged, closing book value, full schedule), and the compliance boundary. No material gap remains for an agent to call this tool correctly or route users away from it when they need an IRD prescribed rate.

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 0%, so the Args block fully compensates: it documents all seven parameters with behavioral meanings — additional_costs as capitalised delivery/installation, salvage_value as a floor, and the two method enum values spelled out. It also adds conditional semantics the schema lacks, namely that useful_life_years is required for straight_line, annual_rate_pct is required for diminishing_value, and years_to_schedule defaults to the life or ten. This is complete compensation for the schema's silence.

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-plus-resource statement — 'Depreciate an asset by straight line or diminishing value, with a year by year schedule' — naming both methods and the output. The 'Use for' examples ('how is depreciation calculated', 'book value after 3 years') remove any ambiguity about which of the sibling calculators is meant. Nothing is a tautology; the tool is immediately distinguishable from all 35 siblings.

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?

Provides an explicit list of query phrasings to match, then an equally explicit exclusion: the tool is 'the ARITHMETIC of the two methods on a rate you supply' and 'NOT a lookup of Inland Revenue's prescribed rates.' It routes the rate-lookup case to the IRD depreciation rate finder and instructs the agent not to invent a rate — model-level when-to-use / when-not-to-use guidance with a named alternative.

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