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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description's job is added context, and it delivers: the downstream figure belongs to the customer, not the site owner, and must never be summed with other values. It also flags that site_annual_revenue is mandatory and never defaulted, which prevents a wrong-result invocation. Missing is any note on what the open-world hazard lookup does when a hazard or region is unknown.

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?

Four short sentences, front-loaded with the eligibility scope before the output semantics and the numeric hazard. Capitalised emphasis on 'ONE' and 'CUSTOMER's' makes the two highest-risk misreadings scannable. Dense but no sentence is filler.

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?

The output schema exists, so the description rightly omits return-value detail, and the annotations carry the safety profile. But for a 13-parameter estimate tool the definition is thin on input meaning, leaving an agent to guess at buffer/substitution/leverage parameters that materially change the answer.

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?

With 0% schema description coverage across 13 parameters, the description must carry parameter meaning, and it covers only site_annual_revenue (plus an implicit hazard). Eleven parameters — buffer_days, restart_tail_days, share_of_output_pct, substitution_lead_days, customer_revenue_gated, acknowledge_leverage, upgrades, vertical, org_type — are left entirely unexplained, and acknowledge_leverage in particular looks like it carries a precondition an agent could trip over.

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 precisely what the tool computes: outage duration for a hazard event at a sole-source manufacturing/warehouse site, the resulting customer outage, and its monetary value. It also bounds the eligible subject ('run by a commercial or nonprofit body'), which separates it from a generic risk assessment. It stops short of naming which sibling to use for a different question, so it lands at 4 rather than 5.

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?

It defines the qualifying scenario (single site, sole-source, specific org types) and gives an explicit quoting rule — pair the result with scenario.probability_pct because this is ONE event, not a yearly average. It also carries an explicit exclusion ('never add it to anything'), which is real when-not-to guidance. It does not name an alternative tool for multi-site or portfolio questions, so no 5.

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