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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: pure arithmetic with no I/O or external calls, no auth or rate limits, rounding to 2 decimals, returned fields, and explicit error behavior (unknown method or missing method-required parameter returns an error rather than a value). That is exactly the kind of behavioral disclosure annotations cannot carry.

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?

Dense but front-loaded: the capability list and routing come first, then per-method parameter requirements, then constraints, then return/behavioral notes. Nearly every sentence carries new information, though the description is long and the method-to-parameter mapping partially duplicates the method enum's formula descriptions in the schema.

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 10-parameter tool with a single required enum selector, the description supplies the method-to-parameter mapping, validity constraints, unit conventions, error semantics, and alternative routing. Output schema exists, so return-value explanation is optional and its brief inclusion is harmless; nothing an agent needs to call correctly is missing.

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 100%, so the baseline is 3, but the description goes further by mapping each method to its required parameters (present_value needs future_value+rate+periods, npv needs cash_flows+rate, etc.) and by stating conditional constraints absent from the schema (growth_rate > -1, cagr requires starting_value > 0 and periods > 0, dcf requires rate > terminal_growth). It also explains the fraction convention and that unspecified params should be omitted with defaults applied.

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 verb set (discount, compound, forecast) and resource (value over time), then enumerates the six formulas behind the method enum, making it distinguishable from siblings like valuation_capm or valuation_probability. An agent can tell exactly which calculation family this tool covers 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?

Explicit when-to-use scenarios are given (convert future cash to today's value, value a forecast with terminal value, project a series, derive implied growth) plus routing to alternatives: get the discount rate from valuation_capm or valuation_international, and explicit exclusions ('Not for option values (use valuation_advanced)', 'not for expected values over outcomes (use valuation_probability)').

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