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

Annotations already declare a safe read-only, closed-world operation, and the description goes further by disclosing that depreciation is straight-line over the project's economic life and is an editable HomeCalc assumption rather than a measured figure. That caveat about model fidelity is exactly the kind of context annotations cannot carry. It does not mention rounding, currency handling beyond the title, or sensitivity to overrides.

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?

One front-loaded sentence delivers the whole purpose, with the key caveat about the editable assumption nested immediately after the behavior it qualifies. The multiple parentheticals make it dense on first read, but no sentence is wasted.

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, the description must convey return semantics, and it does: value added vs cost, residual value at sale, and net rent. Combined with 100% schema coverage and read-only annotations, an agent has everything needed to call this 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 every parameter already carries its own documentation and the baseline of 3 applies. The description adds only indirect meaning, tying economicLifeYears to the straight-line decay mechanism; it says nothing about overriding valueAdded versus projectType defaults that the schema does not already state.

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 a specific computation (value added vs cost, value decay to sale date, plus net rent) for a specific resource (a home renovation), which clearly separates it from siblings like cost_of_selling or capital_cost_allowance. It stops short of naming an alternative tool or contrasting scope explicitly, so it lands just below the top mark.

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?

Usage is implied by the concept of evaluating a renovation's return, and the phrasing 'how that value shrinks by the time you sell' hints at the sale-horizon use case. There is no explicit when-to-use, when-not-to-use, or pointer to a sibling such as house_flipping or cost_of_selling, leaving selection guidance to inference.

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