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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses important behavioral traits: the `pending` field is an estimate of a not-yet-published report, built from weather-driven demand and LNG feedgas components, and `last_verified` includes realized error. It also explains that demo scope only returns published actuals. This is rich, non-contradictory context.

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 dense but every clause carries substantive information: the data source, unit, scope, components of the nowcast, error tracking, and demo behavior. It is front-loaded with the core purpose and uses efficient punctuation to pack detail without becoming unreadable. No wasted words.

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?

Despite having no parameters and an existing output schema, the description fully explains what the tool returns in both scopes, the nature of the nowcast, and the associated accuracy metrics. For a read-only information tool with an output schema, this level of description is complete and leaves no major ambiguity about when or how to use it.

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 tool has zero parameters and the input schema is empty, so the baseline is 4. The description adds no parameter-specific meaning because there are none, but it compensates by explaining output scope (pro vs. demo) and the nature of returned fields, which is valuable for an agent deciding how to interpret results.

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 clearly identifies the tool as returning the EIA weekly natural gas storage report, specifically the released headline injection/withdrawal and, on pro scope, a pending nowcast estimate. It distinguishes from sibling tools by naming the storage report and its lower-48 working gas context, and explicitly says 'Demo scope returns only the already-published actual.' This is specific and unambiguous.

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?

The description provides clear context for when to use the tool: to obtain the EIA weekly storage report and a nowcast for unpublished reports. It explains scope-dependent behavior (pro vs. demo), which helps the agent decide based on expected output. It does not name alternatives explicitly, but the context is sufficient and no misleading guidance is present.

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