Assess Supply Tightness

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavior info: it returns transparent arithmetic and a deterministic screening signal, and explicitly disclaims that it is not an official declaration or causal explanation. This goes beyond the annotations without contradicting them.

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?

Two sentences, front-loaded with the core function and output, followed by a clarifying exclusion. Every word earns its place; no filler or repetition.

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?

The description explains what the tool does, what it returns (arithmetic plus a signal), and its scope limitations. It relies on the output schema for return format details, which is appropriate. The only minor gap is not providing more explicit usage guidance, but that is already covered under usage_guidelines. Overall, it is sufficient for a parameterless tool with a rich output schema.

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, so the baseline is 4. The schema is empty with 100% coverage, meaning there is nothing to document. The description does not mention parameters, but none exist, so it does not need to. It adds no redundant information.

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 states the tool combines the current market snapshot with hourly available generation capability and outages to produce supply-margin arithmetic and a screening signal. It distinguishes itself from siblings by explicitly stating what it is not ('not an AESO declaration or a causal price explanation'), which helps differentiate from explain_market_conditions and find_price_events.

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 gives clear context on what data it uses and the nature of the output, and it excludes specific use cases (not an AESO declaration, not a price explanation). However, it does not name alternative tools or explicitly state when to prefer this tool over siblings, so it falls short of a 5.

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