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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value beyond annotations by explaining the mechanical/screening nature of the estimate and the specific inputs used, while listing exclusions that affect interpretation. This is valuable context for the agent's expectations.

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 concise sentences, both informative. The first states the main action and methodology, the second clarifies important limitations. No repetition, no filler. Highly efficient.

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 simple read-only tool with one parameter and no output schema, the description fully covers its scope, calculation basis, and limitations. The exclusions are especially valuable for setting expectations. No significant gaps remain.

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?

The input schema covers 100% of parameters: a single required 'company' field with description 'Ticker, company name, or CIK.' The description adds no additional parameter-level detail, but that is unnecessary given the schema's completeness. Baseline of 3 is appropriate.

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 opens with a specific verb and resource: 'Estimate a company’s mechanical liquidity runway' and clearly defines the methodology (SEC-tagged cash/current investments and trailing-twelve-month operating cash flow). This distinguishes it from sibling tools like get_rnd_burn_profile or get_company_financials by focusing on liquidity runway as a distinct analytical output.

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?

The description provides clear context and boundaries: it is a 'screening calculation—not management guidance' and explicitly lists exclusions (future financing, commitments, restricted access, working-capital timing, forecast changes). This tells the agent when not to treat the result as authoritative, though it does not name alternative tools for more comprehensive analysis.

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