Get Supply Surplus

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior, lowering the description's burden. The description adds a valuable behavioral disclosure: zero-price states must be interpreted as forecast/status values, not as inferences from observed Pool Price. This prevents a likely misinterpretation.

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 with no fluff; the first is front-loaded with verb and resource, and the second carries an essential caveat. Every sentence earns its place.

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?

Output schema is present, so return-value details are not the description's job; annotations cover safety and idempotence; the schema covers filtering/pagination. The description supplies the one non-obvious semantic caveat, giving an agent enough to select and invoke the tool correctly.

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 high; the request wrapper has a descriptive comment and nested parameters carry defaults/constraints. The description adds 'hourly' and 'official' context but does not explain start/end/limit/offset semantics beyond what the schema already provides. Baseline 3 is appropriate.

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?

Description states a specific verb ('Returns'), a concrete resource ('official AESO hourly Supply Surplus status observations'), and adds a scoping caveat (zero-price states are forecasts/statuses, not inferred from Pool Price). This distinguishes it from price-derived siblings such as get_pool_prices and from analysis-oriented tools like analyze_supply_surplus_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 phrasing implies use when official AESO Supply Surplus status observations are needed, and the pool-price caveat hints that this is not a price-inference tool. However, it does not explicitly say when to prefer this over siblings such as analyze_supply_surplus_events, nor does it give when-not-to-use guidance.

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