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

With no annotations supplied, the description carries the full behavioral burden and does substantial work: it discloses the not_found failure mode, that forecasts are pre-committed rather than computed live, that status remains 'unproven' until a published scoring gate is passed, and that it is free with no API key. It does not describe pagination or response size, but for a single-record lookup those are minor omissions.

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 core content is front-loaded and the payload list is informative, but the description is a dense multi-clause run-on mixing output contents, failure behavior, status semantics, a disclaimer, and a bracketed pricing tag. Sentences like 'Statistical information only, not advice' and the free-tier tag earn their place, yet the enumeration of return fields could be tightened.

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 must explain the return value, and it does so thoroughly — quantiles, threshold probabilities, model version, input timestamps, forecast_id and hash. Combined with the not_found and 'unproven' status disclosures, an agent has enough to call and interpret this correctly; only the exact response shape remains unspecified.

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 83%, so the schema already documents series, quantity, thresholds, target_date, caller_market_price, and apiKey in detail. The description adds only that threshold probabilities come from the logged quantiles — useful framing but marginal beyond the schema. Baseline 3 is appropriate when structured fields do the heavy lifting.

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 names the resource precisely — a pre-logged forecast for a public EIA series and target date — and enumerates what it returns (median, 5/25/50/75/95% quantiles, threshold probabilities, model version, inputs, forecast_id, hash). The verb is implicit (retrieve a logged forecast) rather than stated outright, and it does not explicitly contrast itself with siblings like verify_forecast or energy_track_record, so it falls short of a 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 gives a real usage constraint: the forecast is never computed on request, and returns not_found when nothing was logged. That tells an agent when the tool will fail, but it offers no positive routing guidance — no statement of when to prefer this over verify_forecast or energy_track_record, and no prerequisites for the target_date format beyond what the schema carries.

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