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

Annotations already establish readOnlyHint=true, so the safety profile is covered, but the description adds real value beyond that: it discloses the distinction between location-based and market-based Scope 2 factors, the presence of the Green-e residual mix rate, the data year, and the important provenance caveat about the 2024 eGRID edition not being EPA-published. That provenance detail is behaviorally meaningful and not derivable from structured fields.

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?

It is front-loaded with purpose, then output contents, then alternative routing — a sensible order with no filler sentences. The long enumeration of return values is somewhat dense, but since no output schema exists, the listing is largely justified rather than wasteful.

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 appropriately carries the burden of describing return values, and it does so comprehensively. Both parameters are covered by a 100%-coverage schema, and the alternative tool is named, so an agent has what it needs to call this correctly; only the coordinate/batch variants are unaddressed.

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%, and the schema itself already explains the ZIP pattern and the 2023/2024 edition enum in detail, so the baseline is 3. The description adds essentially no parameter-level detail beyond what the schema provides, leaving the schema to do all the work.

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 a specific verb and resource ('Look up EPA eGRID electricity emission factors for a US ZIP code') and immediately enumerates the returned quantities, so the agent knows exactly what domain this covers. It is clearly distinguishable from siblings like utility_tariff or electricity_rate, which are about rates rather than emission factors.

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 explicitly routes the agent: 'For Scope 2 emissions from a kWh total, use calculate_emissions, which does the arithmetic for both methods' — naming the alternative and the condition that selects it. However, it is silent on the other closely related siblings (lookup_by_coordinates, lookup_batch) that an agent might otherwise confuse with this ZIP-based lookup.

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