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

Annotations already carry the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description needn't restate them. It adds scope context and a link to an interactive version, but says nothing about the computation itself — e.g. whether the result is annualized as (end/start)^(1/years)-1, or how a start value of zero or a decline is handled.

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?

Two sentences plus a link, zero waste. The definition is front-loaded and the disambiguation follows immediately, which is the right order for routing.

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?

There is no output schema, so the description should describe what comes back (a rate — decimal or percentage?), and it does not. For a simple three-parameter, fully-documented calculator the rest is adequate, but the return-value gap leaves an agent guessing at the result format.

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 all three parameters are already documented with units, bounds, and exclusivity. The description adds only the interpretive frame (a single value's growth), not syntax or format detail beyond the schema — baseline 3 is correct here.

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 computation (compound annual growth rate) with its exact inputs (start value, end value, years), so the agent knows precisely what it produces. The second sentence names the sibling tools it is not (irr, xirr), making it distinguishable 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?

Gives an explicit selection rule: single-value growth (revenue, asset price) goes here, multiple cash flows go to irr or xirr. Both the when and the when-not are stated with the named alternatives.

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