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

Annotations already mark the tool read-only and idempotent, and the description adds behavioral nuance beyond that: it uses typical appliance figures rather than exact loads, applies a 10% spare factor, and counts running watts plus the largest motor's starting wattage. The explicit limitation about electrician load calculations is useful. No contradiction with annotations.

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 only two sentences and front-loads the primary sizing purpose. However, the second sentence is structurally tangled: 'what generator permits stated as job value, by size, where a city has enough of them' is hard to parse and does not earn its place as cleanly as the first sentence.

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?

There is no output schema, so the description carries the burden of explaining results; it names generator size and permits but omits units, output format, and how the permit value relates to the loads input. The phrase 'where a city has enough of them' is incomplete given that the only parameter is a loads array, leaving an agent to guess part of the expected response.

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 schema already documents the loads array and its enum, so the baseline is 3. The description adds meaning by explaining that these loads represent outage must-runs and that the sizing method combines running watts with the biggest motor's starting watts, which helps an agent reason about appropriate enum selections.

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 identifies the core output: the smallest common home standby generator size with a 10% safety margin for outage-critical loads, and it mentions generator permit values by size. This differentiates it from siblings like permit_timeline and project_cost, though the second clause 'where a city has enough of them' is grammatically vague and weakens precision.

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 establishes a clear context: use this tool to size a standby generator for the appliances that must run during an outage. The closing caveat 'an electrician's load calculation beats them' tells the agent the result is a rough estimate and should not replace a professional calculation, though it does not explicitly name sibling alternatives.

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