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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds substantial context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and explicit error behavior for unknown methods or missing required parameters. Slight deduction because it does not describe the chapter/formula_number fields it says are returned, though an output schema exists.

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 scope statement and routing guidance are front-loaded, and the dense sentences carry real information with little redundancy. It is long, but nearly every clause (method-parameter mapping, input conventions, error behavior) earns its place, so it stays efficient despite the density.

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 19-parameter, method-dependent calculator, the description supplies everything an agent needs: metric coverage, method selection semantics, per-method parameter requirements, input units, error behavior, and sibling routing. An output schema exists, so return-value explanation is not required.

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 well beyond the schema by mapping each method to its required parameter set (e.g. ltv needs arpu + gross_margin + churn_rate; nrr needs starting_revenue + ending_revenue), which is not encoded in the schema. It also clarifies input conventions (fractions 0.10 = 10%, weight lists in [0,1] summing to 1).

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 states a specific domain (SaaS unit economics and valuation) and enumerates the exact metrics computed (LTV, CAC, MRR, ARR, NRR, magic number, Rule of 40, CAC payback, revenue multiple). It explicitly differentiates itself from siblings by routing marketplace GMV to valuation_marketplace, payments/lending to valuation_fintech, and pre-revenue company value to valuation_core.

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 (subscription software) and when-not-to-use with named alternatives for each boundary case (marketplace, fintech, pre-revenue). It also states that only method is required and that other parameters are method-dependent and should be supplied only for the selected method.

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