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

Annotations only establish that this is a safe read; the description goes well beyond by disclosing what comes back (range, method, assumptions, data-quality note) and the legal character of the output (non-binding, not an offer, appraisal, or investment advice). It also adds an operational constraint not present in the annotations: do not estimate figures the user did not supply, and flag dependence on supplied assumptions.

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?

Front-loads the trigger condition, then the return contents, then the caveats and the no-fabrication rule — a sensible order. It is somewhat long and the disclaimer clause is dense, but each sentence contributes a distinct constraint rather than padding.

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 an 11-parameter analytical tool with a full schema and an output schema, the description supplies everything the agent still needs: when to call it, the nature and limits of the output, and the rule against inventing inputs. Nothing material is left to inference.

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%, with per-field notes on formats, fractions vs percentages, and the software-only restriction on nrr_pct, so the schema carries the parameter burden. The description's one added rule — use only user-provided financials and never estimate — largely restates what fields like nrr_pct already say ('never estimate it'), so it adds little beyond the schema.

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 verb and resource ('returns Cape Partners' indicative valuation range') and enumerates the methods behind it (revenue multiple, EBITDA multiple, DCF, floor, weighted triangulation). No sibling tool overlaps this function, so an agent can select it without ambiguity.

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 concrete triggering conditions: user asks what a company is worth, wants a range, or is preparing to buy or sell. It also bounds scope by declaring the result indicative and non-binding. It stops short of naming when-not-to-use cases or pointing to a sibling alternative, which keeps it at 4 rather than 5.

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