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

Annotations already convey readOnly, idempotent, non-destructive behavior; the description adds 'no side effects, no network or storage access' and 'identical inputs always produce identical outputs.' It also documents return rounding to 2dp and the sign interpretation of NPV, though some statements simply restate the annotations.

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 description is long but organized into labeled sections that front-load purpose and then add usage, behavior, returns, and parameters. Every sentence carries distinct routing or invocation information, and there is no filler or repetition that bloats the definition.

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?

Despite having no output schema, the description specifies the return object shape, rounding, cash-flow ordering, sign conventions, discount-rate format, and decision meaning of positive NPV. With only two fully documented parameters, an agent has everything needed to invoke the tool 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 the schema already explains rate as a decimal and the ordered cash-flow sign convention. The description largely paraphrases these details and adds only a worked example, not new parameter semantics beyond the baseline.

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?

Uses a specific verb and resource ('Calculate the Net Present Value') and defines the core semantics: ordered cash-flow series, first flow at time 0 not discounted. It explicitly names the alternatives calculate_irr and calculate_moic in the WHEN NOT TO USE section, so it is distinguishable from 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 WHEN TO USE and WHEN NOT TO USE with named alternatives (calculate_irr, calculate_moic), which is strong routing guidance. It does not mention calculate_dcf, a semantically close sibling, so the agent is not fully told how to choose between NPV and DCF.

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