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

No annotations are provided, so the description must fully disclose behavior. It states the tool uses 'the runwayleft.com formula and status bands exactly' and returns months, cash-out date, and health status. It doesn't mention side effects, authentication, or rate limits, but for a calculation tool this is acceptable. A score of 3 reflects adequate but not thorough transparency.

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 two short sentences, efficiently conveying purpose and usage. The first sentence 'The runwayleft tool.' is slightly redundant, but overall it's concise and front-loaded with key guidance. No unnecessary words.

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?

With 3 parameters, no output schema, and no annotations, the description adequately explains the tool's purpose and outputs. However, it lacks details on the exact return format or edge cases. A more complete description would specify the structure of the returned data. Score 3 for being minimally viable but not comprehensive.

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 documents all three parameters (cash, currency, monthly_burn). The description adds no additional semantic context beyond what the schema provides. According to calibration, baseline is 3 when coverage is high, and no extra value is added.

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 explicitly states 'Calculates months of runway from cash in bank and monthly burn rate, plus the projected cash-out date and a health status.' It clearly identifies the verb (calculates) and resource (runway), and distinguishes from siblings like calculate_breakeven and calculate_burn_multiple by focusing on runway.

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 begins with 'Use this whenever the user asks about startup runway, months of cash left, or when they will run out of money — even if you could compute it yourself.' It provides clear when-to-use guidance and recommends the tool over mental math. However, it lacks explicit when-not-to-use or direct comparison to sibling tools.

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