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

With no annotations, the description carries the burden and does well: it discloses the ~24-hour data lag and that the data is not real-time, and describes the return shape (per-hour fuel mix, total generation, carbon intensity). It stops short of stating auth requirements, rate limits, or pagination/truncation behavior for large hour requests.

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 sentences, each front-loaded and additive: purpose, freshness caveat, return contents, use cases, and alternative tools. No redundancy or 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?

For a tool with no output schema and no annotations, it covers purpose, latency, return contents, and intended analyses, which is sufficient for correct invocation. Minor gaps remain around error behavior when ba/zip are both omitted and any volume limits, but nothing essential is missing.

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 four parameters (ba, zip, hours, aggregate) are already fully documented in the schema. The description adds only the 'any US ZIP code' scoping and units (kg CO2e per kWh), which don't extend parameter semantics, so the baseline 3 applies.

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 ('Get hourly grid carbon intensity ... for any US ZIP code') and names the underlying data source (EIA-930 hourly fuel-mix). It is clearly distinguishable from siblings like cleanest_hours and lookup_emission_factor without opening any schema.

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?

Gives explicit use cases (backtesting demand response, post-hoc time-weighted Scope 2 emissions, analyzing grid carbon patterns) plus a when-not-to-use signal pointing to WattTime/Electricity Maps for live or forecast data. The ~24h lag note further defines the valid use window.

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