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

Annotations already cover the safety profile (readOnly, idempotent, closed-world, non-destructive), so the bar is lower, and the description still adds real value: it discloses the calculation basis (team size, salary, revenue), the three-way cost breakdown, and the source methodology at wizcomltd.com. The 'Estimate only' disclaimer manages expectations about precision, though it doesn't state units of the return values or any rounding behavior.

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?

Three sentences, purpose front-loaded, then return shape, then provenance and caveat — no filler. The middle sentence is dense but every clause (breakdown, three maintenance levels with hours/year) carries information the agent can't get elsewhere.

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 no output schema, the description must explain the return value, and it does so concretely: hourly cost split into idle wages, lost revenue, and recovery, plus yearly cost at three named maintenance levels. Combined with rich annotations and fully documented parameters, an agent has everything needed to call and interpret this tool.

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 all three parameters already carry their own descriptions and min/max bounds. The description reinforces which inputs matter ('from team size, average salary, and annual revenue') but adds no syntax, unit, or edge-case detail beyond the schema — baseline 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?

States a specific verb and resource — 'Estimate what one hour of IT downtime costs a business' — and immediately names the three inputs driving it. It is unmistakably distinct from siblings like check_cyber_insurance_readiness or scan_ai_visibility, so an agent can route without hesitation.

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?

Usage is only implicit: the tool is clearly for producing a rough downtime-cost figure, and the 'Estimate only' caveat signals it is not a substitute for a real assessment. However, no alternatives are named and no when-not-to-use condition is given, leaving the agent to infer when this beats the sibling tools.

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