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

Annotations already declare the read-only, idempotent, non-destructive profile, so the description does not need to restate safety. It adds some context by specifying the source ('official hourly CSD dispatch') and the aggregation focus, but it does not disclose edge-case behavior, data-availability assumptions, or how the time interval is handled beyond what the schema already notes.

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?

A single sentence that front-loads the verb, resource, and scope, then lists the metrics. Every phrase contributes; there is no filler or repetition of annotation fields.

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 plus annotations and output schema give a fairly complete picture for a straightforward summarization tool. However, the lack of asset-ID provenance or any usage routing leaves an agent to infer how to populate the request correctly, especially given the large sibling set.

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 0% at the top level, and the description does not compensate: it only says 'selected assets', which maps loosely to asset_ids, and 'hourly' implies a time window, but it does not explain the request object, the format or source of asset IDs, or the interval semantics. The nested start/end descriptions do some work, but the top-level request parameter is undocumented.

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 opens with a specific verb, 'Summarizes', ties it to a concrete resource ('official hourly CSD dispatch'), and enumerates the derived metrics (energy, generation, capacity factor, ramp extremes). This distinguishes it from raw-data siblings like get_generation and get_metered_volumes by signaling an aggregated analysis over dispatch data.

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?

No guidance is given about when to choose this tool over siblings such as analyze_ramps, get_generation, or compare_csd_to_metered. The description implies a use case but never states exclusions, prerequisites, or context where an alternative would be better.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is fully covered. The description adds meaningful behavioral nuance: it computes denominator-aware MAPE (not plain MAPE) and only operates 'when the official source provides paired values', which is an operational constraint not present in annotations. There is no contradiction with annotations.

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 a single, information-dense sentence that front-loads the action ('Calculates') and enumerates all key metrics before the conditional caveat. Every clause earns its place with no wasted wording, and the structure is easy to parse despite the long list.

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?

With a full input schema, complete parameter descriptions, annotations, and an output schema present, the description is largely sufficient to understand the tool's scope and output. The only real gap is the unstated behavior when paired values are not available—the description flags the condition but does not explain what the tool would do in that case.

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 100%, so the schema already documents start/end timezone handling, series enum values, and the percentiles array. The description adds a natural-language mapping of the series names to supported forecast types, but does not provide deeper parameter semantics than the schema already supplies. The 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?

The description names the exact metrics calculated (forecast-minus-actual bias, MAE, RMSE, denominator-aware MAPE, error percentiles) and the scope of supported resources (AIL, Pool Price, wind, solar, wind_solar), with a conditional qualifier. This is a specific verb+resource definition and clearly differentiates it from generic forecast/comparison tools by enumerating the analytical output.

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 a clear context: use it for supported forecast/actual pairs and when the official source provides paired values, listing the series types it can handle. However, it does not name alternatives such as compare_forecast_to_actual or get_forecast, nor does it state when not to use this tool, leaving routing decisions to the agent's inference.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds modest context (aggregation of CSD data into time-window metrics) but does not disclose edge behavior such as how 'peak MW' is computed over the interval or how hourly records are aggregated. No contradiction with annotations.

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?

One 19-word sentence with the verb and resource front-loaded and every word carrying information. No filler, no redundancy, and the output metrics are enumerated compactly.

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?

With an output schema present and annotations covering the safety profile, the core call contract is largely complete. The notable gaps are the undocumented fuel_types value domain/default behavior and the lack of sibling differentiation, both of which matter given the crowded tool family.

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 nested start/end parameters are thoroughly documented in the schema (inclusive/exclusive, timezone behavior), but the top-level request object and fuel_types have no schema descriptions. The description's 'by fuel type' clarifies that fuel_types is the grouping/filtering dimension, yet valid fuel type values and the default when fuel_types is omitted remain undocumented in both schema and description.

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 a specific verb ('aggregates'), a precise resource ('official hourly individual-asset CSD generation'), and the exact derived output metrics (energy, share, average MW, peak MW by fuel type). This distinguishes it from siblings like get_generation (raw data) and analyze_supply_stack without opening their schemas.

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?

No guidance is given on when to choose this tool over alternatives. With over 50 siblings including get_generation, get_historical_generation, and analyze_supply_stack, the agent must infer selection solely from the name and output metrics; there are no explicit selection conditions, exclusions, or alternative references.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds useful behavioral nuance by clarifying that the output is a proxy (gross offers vs capability) and not metered flow, which helps set expectations about what the metric means. No annotation contradiction exists.

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 purpose, followed by an important caveat. There is no redundancy or filler; 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?

With output schema present and annotations covering read-only safety, the description need not explain return values or idempotency. It communicates the analytical intent and distinguishes the tool from metered-flow alternatives. However, the optional interties parameter's semantics are not explicitly tied to 'path and direction', leaving a minor gap in fully instructing invocation.

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 0% and the description does not explain start_date, end_date, or the optional interties parameter. Although the schema provides types and requiredness, the description leaves the meaning of interties and the behavior when omitted implicit, forcing the agent to infer domain knowledge rather than providing clear parameter guidance.

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 uses a specific verb ('Summarizes') and a precise resource ('gross offers relative to available intertie transfer capability by path and direction'). It also clearly distinguishes itself from metered-flow tools by stating it is an offer-to-capability proxy, not metered flow, which separates it from sibling tools like get_metered_volumes and get_interchange.

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 implies when to use the tool: when the user wants an offer-to-capability proxy rather than actual metered flow. However, it does not explicitly name alternatives or state when not to use it, so an agent must infer the usage boundary from the phrase 'not metered flow' rather than receive explicit routing guidance.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds value by disclosing that output is descriptive rather than causal and that the baseline may be supplied or automatically taken from the immediately preceding period. No contradiction with annotations.

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 dense sentences with no filler: the first front-loads the comparison behavior and evidence scope, the second states the output limitation. Every phrase 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?

For a complex analytical tool, the description captures the input window, baseline handling, evidence dimensions, and output nature; an output schema exists so return structure need not be repeated. It could be more explicit about how baseline parameters relate to the focus window, but the core call semantics are adequately conveyed.

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 0%, so the description must carry parameter meaning, but it only glosses a 'focus window' and 'baseline' without explaining baseline_start/end semantics or how the preceding baseline is selected. The schema gives timezone notes for start/end, but baseline fields remain underdocumented.

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 uses a specific verb ('compares') with a clearly enumerated evidence scope (price, demand/forecast, supply, merit-order, intertie, commitment, operating reserve) and states the output type ('descriptive associations, not causal claims'). This distinguishes it from single-source getters and from causal explanation tools in the sibling list.

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 implies when to use the tool (multi-domain comparison in a focus window) and cautions against causal interpretation, but it does not explicitly compare against close siblings like compare_market_periods or explain_market_conditions. It provides clear context without explicit alternatives or exclusions.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint false. The description adds useful behavioral context beyond those annotations: the calculation is hourly, defaults to wind and solar, allows selecting renewable fuels, and produces average, peak, and minimum net load values. This helps the agent understand the tool's output shape and configurable behavior.

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?

A single sentence packs the action, resource, formula, defaults, and output statistics without redundancy. The most important information is front-loaded, and every clause 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?

With an output schema provided and read-only annotations covering safety, the description supplies the core calculation logic, defaults, and output metrics. The main minor gap is that 'CSD' is not explained, but this is a domain acronym rather than a missing behavioral requirement. Overall, an agent has enough to understand what the tool computes and how to invoke 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 schema documents start and end semantics, but renewable_fuels has no description. The description partially compensates by indicating that renewable generation is selectable and defaults to wind and solar, but it does not specify accepted fuel values, string formats, or how the request object maps to the calculation. Parameter semantics are therefore adequate but incomplete.

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 uses a specific verb ('Calculates') and clearly identifies the resource and formula: hourly Alberta Internal Load minus selected CSD renewable generation, with wind and solar as defaults. It also lists the computed statistics (average, peak, minimum), which distinguishes it from generic load or generation retrieval tools among the siblings.

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 implies this tool is for net-load analysis after subtracting renewable generation, but it gives no explicit when-to-use guidance, no conditions, and no mention of alternatives. An agent can infer the purpose but is not told when to choose this over get_load, get_generation, or other analysis tools.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds a valuable interpretation caveat by labeling the Pearson correlation as non-causal, but it adds no context on data completeness, missing-hour handling, or the meaning of the default threshold behavior.

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?

One dense sentence that front-loads the core operation (the join), then the outputs, then the caveat. Every clause earns its place, though splitting the causality caveat into its own sentence would improve scannability.

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 analytical intent, output schema, and safety annotations cover the tool's core well. However, high_outage_threshold_mw semantics and default-null behavior are undocumented in both schema and description, leaving an agent to guess what counts as a high-outage hour. For an analysis tool of moderate complexity this is adequate but with clear gaps.

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 0% and the description names no parameters. The schema documents start/end timezone handling but leaves high_outage_threshold_mw with no description; the phrase 'high-outage' is only a weak hint, and the nested request wrapper is never mentioned. The description fails to compensate for the schema gap.

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 uses specific verbs and resources: it 'joins hourly generator outage capacity to Pool Price' and 'reports high-outage versus other-hour price differences plus Pearson correlation.' This makes the analytic purpose clear and distinguishes it from siblings like get_outages or get_pool_prices, though it never names a sibling explicitly.

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 'as non-causal associations' qualifier is an implied usage constraint, telling the agent how to frame results, but there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives like get_outages for raw outage lists or analyze_market_event for broader event analysis.

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

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

Beyond the readOnly and idempotent annotations, the description discloses meaningful behaviors: it supports hourly and five-minute cadence where available, skips non-consecutive observations, reports MW per interval and MW/hour, and never fills missing values. This gives an agent a clear model of how the tool processes data.

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 two dense sentences with no filler. The primary action is front-loaded, and each clause adds a distinct behavioral fact without 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?

Given the rich input schema, annotations, and the presence of an output schema, the description covers the essential behavioral gaps: cadence handling, missing-value policy, non-consecutive observation handling, and output units. Nothing critical for invoking the tool correctly appears to be 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 description coverage is 100%, so the baseline is 3 even though the description does not add much per-parameter detail. The high-level mention of series types and cadence aligns with the schema but does not deepen understanding beyond what the parameter descriptions already provide.

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 a specific analysis ('Calculates cadence-aware up/down ramps') and enumerates the applicable resources: AIL, net load, wind, solar, or asset CSD generation. This clearly distinguishes it from sibling analysis tools like analyze_net_load or analyze_generation_mix.

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 implies usage through its capability statement, but it does not explicitly say when to choose this tool over alternatives or when not to use it. It provides some context about cadence support and data handling, but no exclusionary guidance relative to sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds scope context (one historical hour and its key outputs) but no further behavioral traits such as data availability, error behavior, or edge cases. This is acceptable but not rich.

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 one concise sentence with no filler. It front-loads the core action and resource, then lists key outputs efficiently.

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, annotations, and output schema together provide a minimally viable picture for a read-only analysis tool. It clearly states what the tool does, but omits usage guidance and parameter-level detail, leaving some context for the agent to infer.

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 0%, and the description never names report_date, hour_ending, or limit. It only weakly implies a historical hour input, so it does not compensate for the schema gap enough to help an agent map the textual description to the required parameters.

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 uses a specific verb ('Analyzes') and identifies a clear resource: one historical Energy Merit Order hour, and it lists distinctive outputs such as price-sorted offer blocks and highest dispatched offer price. It does not explicitly contrast itself with sibling tools like get_energy_merit_order, so it lacks full sibling differentiation.

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 no guidance about when to use this tool instead of nearby alternatives such as get_energy_merit_order or analyze_supply_surplus_events. It implies a focus on a single historical hour, but no exclusions or alternative conditions are provided.

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

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

Beyond the read-only and idempotent annotations, the description adds important behavioral caveats: durations are only reported when the official sequence provides an explicit end boundary, and results are descriptive associations, not causation. These are meaningful constraints for interpreting the output.

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 carry the core purpose and key caveats with no filler. The primary operation is front-loaded, and each 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?

Given a complete input schema and an output schema, the description covers the central purpose and the main behavioral caveats. It does not detail how missing official sequences affect the overall result beyond duration reporting, but this is a minor gap for an analysis tool.

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%: both start and end parameters are fully described with timezone and inclusivity/exclusivity semantics. The description adds no parameter-specific detail, so the baseline score of 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?

The description states a specific analytical operation: aligning official AESO supply-surplus status runs with observed Pool Price, AIL, and wind/solar generation. This clearly distinguishes the tool from raw data retrieval siblings like get_supply_surplus and other market analysis tools.

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 a clear context: use when a bounded descriptive comparison of official surplus status against observed market and generation data is needed. It does not explicitly name alternatives or state when not to use the tool, so it stops short of full routing guidance.

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

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

The annotations already mark the tool as readOnly, idempotent, and openWorld. The description adds useful behavioral context by emphasizing the output is deterministic and transparent arithmetic, and clarifying it carries no official AESO status. This goes beyond the structured annotations and sets correct expectations for downstream use.

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 computation and return type, plus a clarifying exclusion. Every sentence contributes meaning and no length is wasted.

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 zero-parameter tool with an output schema and safety annotations, the description adequately covers what the tool computes, what kind of signal it returns, and the caveat about non-official status. It could be more explicit about exactly when to choose it over sibling supply-analysis tools, but the core context is present.

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?

With zero parameters, there is no schema burden for the description to carry, and the baseline for 0-param tools is 4. The description also names the implicit inputs (market snapshot, generation capability, outages) which helps an agent conceptualize what the tool evaluates.

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 states exactly what the tool does: it combines market snapshot, generation capability, and outages to compute supply-margin arithmetic and a deterministic screening signal. It also distinguishes the output from an AESO declaration or causal price explanation, so an agent can tell it apart from analytical siblings like explain_market_conditions or get_supply_adequacy.

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 for when to use the tool: when a transparent, deterministic supply-tightness screening signal is needed. It explicitly states what it is not for (not an AESO declaration, not a causal price explanation), but does not name alternative tools or provide an explicit 'when to use vs get_supply_adequacy' routing statement.

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

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

Annotations already mark the tool as read-only, open-world, idempotent, and non-destructive, so the description does not need to restate safety. It adds useful behavioral detail beyond annotations: the join methodology, the inclusive/exclusive interval behavior, and the promise of explicit missing intervals, which is important for a calculation tool that might silently drop data.

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 compact and well-structured: it opens with the core join, lists the key output metrics, and finishes with a concise caveat. Every sentence earns its place without restating the tool name or repeating the schema verbosely.

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 computation tool with a rich input schema, an output schema, and safety annotations, the description is largely complete. It names the calculation inputs, the outputs, missing-interval handling, and the key settlement caveat. It could slightly improve by distinguishing itself from calculate_capture_prices, but that is more usage guidance than core completeness.

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 100%, with the input schema already documenting start/end date-time behavior and asset_ids selection. The description reinforces that the operation is a join by selected asset over [start, end), but it adds little parameter-level meaning not already present in the schema.

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 states a precise operation — joining hourly metered energy by asset with hourly AESO Pool Price — and specifies the returned metrics (gross revenue, capture price, capture rate, matched hours, missing intervals). It also explicitly delimits its scope with 'This is not total settlement revenue,' which distinguishes it from settlement-related siblings.

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 implies a clear use case — calculating Pool Price energy revenue from matched metered and price data — and provides an explicit exclusion by stating it is not total settlement revenue. However, it does not specify when to choose this tool over nearby alternatives such as calculate_capture_prices or get_monthly_cumulative_net_revenue, so usage routing remains partially inferred.

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

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

Annotations already declare the operation as read-only, non-destructive, and idempotent. The description adds meaningful behavioral context beyond that: it identifies the data sources (hourly Pool Price, official CSD generation), the join operation, and the generation-weighting methodology, giving the agent a clearer model of what happens when invoked.

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 a single, well-structured sentence that front-loads the core action and data source. Every phrase adds information, with 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?

Given the presence of an output schema and annotations covering safety, the description is largely adequate. It explains the data sources, the computation approach, and the available filter dimensions. Minor gaps remain around whether filters are optional and how results are grouped when both asset_ids and fuel_types are provided, but these are not critical.

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 0%, so the description must compensate. It does partially by explaining that filtering is by 'asset and/or fuel group,' which maps to asset_ids and fuel_types, and that the time window is required. However, it does not add details about accepted ID formats, fuel group values, or behavior when no asset/fuel filter is provided.

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 a specific action: joining hourly Pool Price to CSD generation and calculating generation-weighted capture price and capture rate. This distinguishes it from sibling tools like get_pool_prices and get_generation, which retrieve raw inputs rather than perform the analytic calculation.

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 implies when to use the tool — when capture prices/rates by asset or fuel group are needed — but it does not explicitly state exclusions or alternative tools. There is no direct guidance on when to prefer this over related calculation tools such as calculate_asset_energy_revenue.

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

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

Annotations already declare readOnly, openWorld, and idempotent hints. The description adds meaningful behavioral context: the MW-to-interval-MWh conversion, the matched-hour methodology, percentage errors, missing-source counts, and the explicit warning that CSD operational output and metered settlement energy are distinct source concepts.

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 tight sentences front-load the core comparison and output, followed by a one-sentence conceptual clarification. No filler or redundancy; 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?

The description covers inputs, comparison logic, output contents, and source-concept distinction, and an output schema exists for return-value details. It is complete for a read-only comparison tool, though explicit sibling differentiation would make it fully comprehensive.

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 100%, with start and end timezone handling and asset_ids constraints already documented. The description contributes context like 'hourly' and 'by asset', but does not need to add much because the schema already carries the parameter meaning.

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 states a specific verb and resource: compares hourly operational Historical CSD generation against hourly settlement-metered energy by asset. It also specifies what is returned (matched-hour differences, percentage errors, missing-source counts), making the tool's purpose unmistakable and distinguishing it from generic compare tools.

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?

Usage context is implied through the comparison of CSD operational output versus metered settlement energy, but no explicit when-to-use or when-not-to-use guidance is given. Given many sibling comparison tools like compare_forecast_to_actual and compare_market_periods, explicit alternatives would strengthen this dimension.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond annotations by clarifying half-open interval boundaries ([start, end)) and the timezone interpretation (America/Edmonton), which materially affect how inputs are interpreted and results are produced.

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 efficient sentences front-load the core function, then list outputs and timezone context. Every clause adds value and nothing is redundant or speculative.

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?

Given the tool's simple structure, complete parameter schemas, rich annotations, and existing output schema, the description provides sufficient context. It covers what data is compared, the interval, the units, the returned metrics, and the timezone behavior—no critical gaps remain.

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%, with start/end inclusivity and timezone handling already documented in the schema. The description's interval notation and timezone note largely restate this information, adding only minimal extra meaning such as the MW unit context for the comparison.

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 states a specific verb ('Compares'), the exact resource ('Alberta Internal Load forecast versus actual'), the interval semantics, units, and the expected outputs. This clearly differentiates the tool from siblings like get_forecast or get_load, and its metric-focused output distinguishes it from analyze_forecast_error.

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 implies the use case: when you need forecast-versus-actual error metrics over a time range. However, it does not explicitly name alternatives or state when not to use this tool, especially given closely related siblings like analyze_forecast_error and compare_market_periods.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotations by specifying the aggregate nature of the statistics, the inclusion of deltas, and the important caveat that the tool 'does not assert causation.'

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 two concise sentences. The first sentence front-loads the core action and scope, and the second adds a valuable interpretative caveat without unnecessary detail. Every phrase 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?

With an output schema present, the description does not need to explain return values. It provides the essential information needed to invoke the tool correctly: the comparison target, the market area, the statistic types, and the causal limitation. No critical information for selecting or calling the tool 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 description coverage is 100%, so the baseline is 3. The description adds value by identifying the timezone 'America/Edmonton' and clarifying that the comparison is about pool-price and load statistics, which helps the agent understand the semantic context of the four date-time parameters even though the schema already defines their types and required status.

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's specific action: 'Compares aggregate pool-price and load statistics between two America/Edmonton market periods.' It names the exact resource and scope, and the comparison-of-two-periods framing distinguishes it from sibling tools like get_price_statistics or get_pool_prices, which do not emphasize dual-period comparison.

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 implies a clear use case: comparing aggregate pool-price and load statistics across two distinct historical periods. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear that an agent would know when to select this tool over single-period or forecast-related siblings.

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

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

Annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations by disclosing that the tool returns observed metrics and associated_changes without asserting causation, and that the calling model must generate any natural-language explanation.

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?

Three sentences, each carrying distinct information: the comparison and default baseline, the output components, and the critical limitation/caveat. There is no repetition 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 read-only tool with a fully described schema and an output schema, the description covers the default baseline and the non-causal nature of the output. It could add a little more context about what 'market conditions' evidence is intended to support, but the output schema likely supplies that detail.

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 100%, so the schema already documents request.start, request.end, and the optional baseline window. The description's mention of the default preceding equal-length baseline restates information already present in the schema (baseline_start's default), adding no new semantic detail.

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 uses a specific verb ('Returns') and resource ('structured evidence for market conditions in a focus window versus a baseline window'), clearly conveying the comparison task. It distinguishes the tool from a natural-language analyst by stating it does not claim causation, though it does not explicitly name or contrast a sibling tool.

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: use it when structured market-condition evidence is needed and a baseline comparison is desired, with a default baseline if none is supplied. It does not enumerate exclusions or explicitly name alternatives, but the boundary between this tool and a natural-language explainer is stated via the final sentence.

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

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

Annotations already cover read-only, non-destructive, idempotent behavior, so the description's job is to add context. It does so by disclosing the threshold mechanism (absolute or percentile, default 90th) and the nature of the result (event boundaries and load context when available). This adds meaningful behavioral context beyond the annotations.

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 two sentences with no filler. The core detection behavior is front-loaded, followed by threshold semantics and the return value summary, so 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?

Given that an output schema exists, the description need not enumerate return fields in detail. It covers the interval, threshold modes, default behavior, and output categories, which is sufficient for an agent to select and invoke this 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 100%, so the baseline is 3 and the description does not need to compensate. It does restate the threshold alternatives and default percentile, which is helpful, but it does not add material meaning beyond the schema's already detailed parameter descriptions.

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 uses a specific verb ('Detects'), a clear resource ('sustained high Pool Price events'), and an explicit interval ('[start, end)'), which distinguishes it from sibling tools that return raw prices or market snapshots. It also states the output shape ('event boundaries, duration, peak/average price'), leaving no ambiguity about what the tool does.

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 implies the tool is for detecting sustained high-price events, but it does not explicitly state when to use this tool versus alternatives such as analyze_market_event, get_price_statistics, or get_pool_prices. No exclusions or alternative routing guidance is provided.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds behavior beyond annotations: start/end select publication windows, not outage intervals, and lookups are tightly bounded because upstream navigation walks archive pages.

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?

Three sentences with purpose first, usage second, and differentiation third. Every sentence adds information and there is no filler or redundant elaboration.

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?

Given the simple parameter surface, rich annotations, and presence of an output schema, the description covers what the tool returns, how to request current vs historical data, and how it differs from related outage tools. Nothing essential for correct invocation 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?

The schema already documents start as optional inclusive and end as optional exclusive, and schema coverage is 100%. The description repeats this at a high level and adds the 'current public publication' and 'tightly bounded' nuance, but it doesn't carry substantial meaning beyond the schema.

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 opens with 'Returns AESO-approved planned transmission outages (approval_status=approved)', giving a specific verb, resource, and filter. It also explicitly differentiates from generator outages and long-range tentative outages, which maps to sibling tools and prevents confusion.

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 tells the agent to omit start/end for the current public publication and to use them for tightly bounded historical publication windows. It doesn't explicitly name the exact sibling tool for generator or tentative outages, so alternative routing is implied rather than fully explicit, but the usage cases are clear.

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

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

The truncation caveat ('Results may be truncated by the limit parameter') adds genuine behavioral context beyond the annotations' readOnly/openWorld/idempotent hints — it warns the agent that a query may return an incomplete result set, which affects downstream reasoning. No contradiction with annotations.

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, zero filler. The primary action and filter scope are front-loaded in the first sentence, and the truncation caveat earns its place in the second.

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 read-only list tool with a rich annotation profile and an output schema, the description covers purpose, filter scope, and the key truncation behavior. Minor omissions like default limit and ordering are already visible in the 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?

Schema description coverage is 100% and property names are self-explanatory, so the baseline is 3. The description adds marginal value by mapping natural-language filters (e.g., 'pool participant') to schema parameters and noting that limit can truncate 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?

States a specific verb ('Returns') and resource ('AESO market asset registry records'), and enumerates the filter dimensions. Among the ~60 sibling tools, none other targets the asset registry, so the tool is clearly distinguishable.

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 usage context is implied — use this to fetch asset registry records with optional filters — but no explicit when-to-use guidance, exclusions, or alternative tool routing is given. With many sibling tools, explicit routing would help, though the purpose is self-evident enough to infer appropriate usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds complementary context: results are 'bounded official AESO publications', and DDS is conceptually distinct from related market data. This helps an agent interpret the data source and scope, though pagination behavior is left to the schema.

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 two sentences with no wasted words. It front-loads the core return behavior, then adds a single clarifying distinction. It avoids repeating information already present in annotations or the schema.

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 schema fully documents the required request object, start/end semantics, timezone handling, and optional limit/offset. Annotations cover the safety and idempotency profile, and an output schema exists. The only minor ambiguity is the word 'bounded', but the limit/offset parameters and schema constraints resolve it sufficiently.

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 100% at the request parameter level, with nested start/end descriptions including timezone interpretation and limit/offset constraints/defaults. The tool description itself adds no parameter-specific meaning beyond the schema, so the 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?

The description uses a specific verb ('Returns') and names a precise resource ('AESO Dispatch Down Service availability publications'). It also explicitly distinguishes DDS from energy-market dispatch and metered generation, which helps the agent differentiate it from siblings like get_generation or get_metered_volumes without opening schemas.

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 implies this tool is for Dispatch Down Service availability data and warns against confusing it with energy-market dispatch or metered generation. However, it does not provide explicit when-to-use guidance or name an alternative tool to prefer in other cases; the usage context is suggestive rather than prescriptive.

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

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. The description adds valuable behavioral context beyond those annotations: the 60-day publication delay, the units (CAD/MWh, MW), and the timezone (America/Edmonton), which materially affect interpretating results. No contradiction with annotations exists.

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 three short sentences, each adding necessary information: the primary purpose, the data recency constraint, and the unit/timezone context. There is no fluff or repetition of schema details, and the most important purpose is front-loaded.

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?

Given the output schema exists and annotations cover side effects, the description supplies the remaining critical contextual facts: history-only scope, 60-day delay, units, timezone, and paginated offer-block format. An agent has enough to select and use the tool correctly without additional description.

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 100%, so the input schema already fully documents report_date, limit, and offset with defaults and bounds. The description adds only general context about report units and pagination, which does not need to replace the schema's parameter documentation. 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?

The description clearly states the tool returns one historical AESO Energy Merit Order report date as paginated offer blocks, which is a specific verb, resource, and scope. This distinguishes it from sibling tools like get_system_marginal_prices or get_pool_prices, which serve different market data purposes.

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: it is for historical merit order data, with a 60-day release delay, so agents can infer it is not for real-time queries. It does not explicitly name alternative tools or exclusions, but the historical qualifer and report type provide sufficient routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is handled. The description adds genuine value beyond annotations by disclosing the AESO sign convention (imports negative, exports positive) and by drawing a boundary against offered/dispatched data, both essential for correct interpretation. No contradiction with annotations.

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 zero filler: the first delivers the core purpose, the second delivers the critical sign convention and scope boundary. Content is front-loaded and 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?

The output schema carries return-value documentation, annotations carry the safety profile, and the schema carries parameters at 100% coverage. The description supplies the one non-obvious interpretive fact (sign convention) and a scope boundary. Nothing an agent needs to call it correctly 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 description coverage is 100%, with start, end, limit, and offset all documented including timezone semantics for naive datetimes. The description adds no parameter-level detail beyond the schema; the word 'bounded' loosely echoes the limit/offset mechanism but contributes nothing new. Baseline 3 applies since the schema does 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?

States a specific verb ('Returns') and a well-scoped resource ('bounded official FFR Net Schedule archive'), with qualifiers 'bounded' and 'official' pinning down scope. The explicit clarification ('this is not FFR offered or dispatched') further distinguishes it from adjacent data categories an agent might confuse it with.

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?

No explicit when-to-use conditions and no named sibling alternatives. The negative clause ('not FFR offered or dispatched') gives a partial when-not signal, but it stops short of routing the agent to the correct alternative or stating the situation in which this tool is preferred.

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

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

Annotations already convey read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond annotations: the half-open [start, end) interval semantics and the conditional "where the requested source horizon exists", which alerts the agent that data availability is not guaranteed. This goes beyond the annotation baseline without contradicting it.

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 a single, front-loaded sentence that packs in the resource, scope, interval semantics, series options, and a data-availability caveat. There is no filler or unnecessary repetition of schema details.

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?

Given the rich input schema, output schema, and annotations, the description provides enough orienting context for an agent to decide whether this tool fits the request. It covers what data is returned, for which series, over what interval, and notes the horizon-existence condition; return-value details are covered by the 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?

Schema description coverage is 100%, so the input schema already documents the request object, start/end timezone interpretation, horizon requirements, series enum, and pagination fields. The tool description adds little parameter-level meaning beyond restating the series and interval, so the baseline score of 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?

The description uses a specific verb, "Returns", and identifies the resource as "typed official AESO actual and forecast observations" over a defined interval. It further specifies the supported series (AIL, Pool Price, wind, solar, combined wind/solar), making it easy to distinguish from forecast-related siblings like get_operating_reserve_forecast or get_load_outage_forecast.

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 implies its use for retrieving official AESO forecast/actual observations for the listed series, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool names are mentioned, so the guidance relies on inference from the tool name and scope.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful behavioral context: the snapshot includes all fuels in MW, historical data is hourly wind/solar, and renewable share is computed as wind + solar + hydro over total generation. Pagination and limit behavior are not mentioned but are available in the schema.

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?

Three sentences with no wasted words: purpose first, then conditional usage, then a metric definition. Front-loaded and every sentence contributes to the caller's understanding.

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 a nested request schema and an output schema, the description covers the key behavioral modes and the renewable-share definition. It does not explain pagination or the exact output structure, but the schema and annotations fill those gaps, so nothing critical 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% and the nested request schema already explains the two date-range modes. The description enhances this by explicitly telling the user to omit or provide start/end and by defining the renewable-share calculation. Limit and offset are left to schema defaults, which is acceptable.

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 ('Returns Alberta generation data') and clearly distinguishes the two operating modes: current fuel-mix snapshot vs historical wind/solar hourly generation. This makes it separable from sibling tools like get_generation_capacity or analyze_generation_mix without needing to inspect them.

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, actionable usage guidance: omit start/end for the current fuel-mix snapshot, and provide them for historical wind and solar generation. It does not explicitly contrast with sibling tools such as get_historical_generation, but the parameter-based conditions are unambiguous.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description goes further by adding the inclusive 31-day date bound, MW units, hourly granularity, fuel-class breakdown, and paginated output, all of which are meaningful operational details beyond the annotations.

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 redundant phrasing. The core return value is stated first, followed by key operational constraints (date bound, units, pagination). Every phrase contributes to the agent's understanding.

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?

Given the presence of an output schema and annotations, the description supplies the necessary operational context: data resolution (hourly), scope (AIES), content (capacity and outages by fuel class), date restriction (31 days), units (MW), and pagination. Nothing critical for correct invocation appears to be 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?

The schema description already covers 100% of parameters, including the request object description of an inclusive report-date range with bounded pagination. The description adds value by explicitly stating the 31-day maximum inclusive range and confirming that output is paginated, which directly relates to start_date, end_date, limit, and offset semantics.

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 identifies a specific verb ('Returns'), a specific resource ('hourly AIES maximum and available generation capability plus operating and mothball outages by fuel class'), and clarifies units and pagination. It is clearly distinguishable from sibling tools like get_generation or get_outages because it focuses on capacity capability rather than actual generation or general outages.

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 a clear context of what data is returned (capacity and outage status by fuel class) and constraints (31-day limit, MW, paginated), so an agent can infer when it is appropriate. However, it does not explicitly state when to prefer this tool over alternatives such as get_generation, get_outages, or get_historical_generation, nor does it mention exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the '[start, end)' half-open interval, the timezone-naive interpretation as America/Edmonton market time, the optional refresh behavior, and the caveat that the archive is not settlement-metered data. These go beyond what annotations provide.

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 two sentences: the first packs the core semantics (resource, interval, resolution, filters, pagination), and the second adds a critical caveat. Every clause earns its place, and the key constraints are front-loaded.

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?

Given the rich schema, output schema, and annotations, the description covers the essential operational semantics: interval bounds, resolution choice, filtering, pagination, and the non-settlement caveat. Minor gaps like pagination details and the refresh mechanism's behavior are not fully explained, but the schema and output schema already carry much of that load.

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 100%, so the schema already documents parameters thoroughly. The description adds semantic value by explaining that filters are bounded ('Bounded asset/fuel filters'), that the interval is half-open, and that the data is operational CSD not settlement-metered. This is enough to elevate above the baseline 3.

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 states a specific verb ('Returns'), a specific resource ('AESO CSD individual-asset generation'), a precise interval semantics ('[start, end)'), and two resolution options. It also distinguishes this from settlement-metered data, which helps differentiate it from sibling tools like get_csd_to_metered.

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 implies use for historical official CSD generation queries and notes that this archive is not settlement-metered, giving a useful exclusion. It doesn't explicitly name sibling alternatives like compare_csd_to_metered or summarize_market_history, but the interval and filter scope make the usage context reasonably clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds valuable behavioral context by specifying exactly what diagnostic information is reported (coverage, cadence gaps, counts, schema version, dependency checks), which goes beyond the structured 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?

The description is a single sentence that front-loads the core purpose ('Reports local DuckDB/Parquet coverage') and then efficiently enumerates each reported item. Every clause earns its place without any redundant wording 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 zero-parameter status-reporting tool with an output schema present, this description is complete. It covers all relevant dimensions of the tool's behavior—coverage, gaps, counts, schema version, and dependency checks—and the output schema handles return-value details, so no necessary information 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?

The tool has zero parameters and the input schema is empty, so the baseline of 4 applies. The description doesn't need to explain parameter semantics since there are none, and the schema coverage is already 100%, leaving nothing undocumented.

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 uses a specific reporting verb and names the exact resource ('local DuckDB/Parquet coverage') plus a detailed list of what it reports, including cadence gaps, counts, schema version, and dependency status. This clearly differentiates it from sibling data retrieval tools like get_historical_generation, which report market data rather than storage health.

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 clearly implies when this tool should be used: whenever an agent needs to assess the completeness or health of the local historical data store, such as before running sync_historical_store. It provides clear context for the tool's purpose, though it does not explicitly name alternatives or exclusion criteria.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description is not responsible for side-effect disclosure. It adds meaningful behavioral context by explaining the AESO sign convention and that results are current flows, going beyond the annotations.

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 concise sentences. The first states the core purpose and measurement unit; the second adds the sign convention. No wasted words or redundant schema 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?

For a zero-parameter read-only tool with an output schema, this description is complete. It specifies the resource, units, temporal scope, and a key interpretive detail. Nothing else is needed for correct invocation.

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 schema fully covers input semantics. The description's mention of 'by path' refers to output granularity, not a parameter, so no additional parameter guidance is needed.

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 returns current Alberta interchange flows by path in MW and includes net interchange. It also specifies the sign convention, distinguishing it from intertie capability and outage tools.

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?

There is no explicit guidance on when to use this tool versus alternatives like get_intertie_capability or get_intertie_outages. The description implies current flow retrieval but does not state exclusions or conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's added value lies in disclosing operational constraints: hour-ending bounds, versioned reports, 100-day date range limit, and paginated output. These go beyond the annotations and help the agent anticipate response size and filtering behavior, though it does not detail error handling or exact response structure.

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 two sentences with zero filler. The first sentence front-loads the core purpose and data content; the second efficiently covers operational constraints. Every phrase provides information needed for correct invocation, making it an ideal size for an agent-facing tool description.

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?

Given the presence of an output schema and thorough annotations, the description adequately covers the essential operational context: data type, constraints, and pagination. It does not explicitly address when to use this tool versus sibling tools, but the detailed resource scope makes the use case reasonably clear. A small gap remains around differentiating from related intertie tools, but this is not critical for basic invocation.

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?

While schema description coverage is high and defaults/min/max exist, the tool description adds meaning by translating 'hour-ending bounds' to the start_hour_ending/end_hour_ending parameters, 'optional versioned reports' to include_versions, and 'paginated' to limit/offset. This clarifies how the nested parameters are intended to be used, which is not obvious from the schema alone.

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 states a specific verb ('Returns') and a clear resource ('hourly import/export ATC, TTC, reliability margins, and gross offers for AESO interties and flowgates'). This is far more specific than the tool name and clearly defines the scope of data returned, distinguishing it from likely siblings like get_interchange or get_intertie_outages by its precise data content.

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 implies when to use the tool through its detailed resource and data output, but does not provide explicit guidance on when to prefer it over alternatives or when not to use it. It mentions constraints like the 100-day limit and pagination, which affect usage, but does not name alternative tools or exclusion criteria, leaving usage decisions to inference.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context by stating output is paginated and that affected paths and event boundaries are reported in America/Edmonton timezone. This goes beyond 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?

A single dense sentence front-loads the action and scope, then appends output details and pagination. There is no filler or redundancy, making it easy for an agent to parse quickly.

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 one nested parameter, a rich output schema, and strong annotations, the description covers the core purpose, domain, timezone, and pagination behavior. The only minor gap is the lack of explicit differentiation from the many sibling outage-related tools, but the 'interties or flowgates' scope makes the intended use clear.

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 schema already covers parameter semantics at 100% with the request description 'inclusive AESO report-date range with bounded output pagination.' The tool description repeats the ideas of 'inclusive' and 'paginated' but does not add new parameter-level meaning. 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?

States a specific verb ('Returns'), resource ('AESO interties or flowgates'), and scope ('inclusive date range'). The description also mentions affected paths and event boundaries, adding precision beyond the title. It does not explicitly distinguish itself from siblings like get_outages, so it stops 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?

The description clearly implies its use case: retrieving outages that affect interties/flowgates. However, it offers no direct guidance about when to choose this over alternative outage tools such as get_outages or get_approved_transmission_outages. The inclusive date range and pagination are operational details rather than usage conditions.

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

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

Annotations already convey read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: exact interval semantics, timezone handling, a 90-day maximum range, and the caveat that forecast values are included only 'when available'. No contradiction with annotations.

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 purpose, and every sentence adds necessary information: units, interval, timezone, maximum range, and optional forecast inclusion. No filler or redundancy.

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 straightforward read-only data retrieval tool, the description plus rich schema and annotations cover what an agent needs to call it correctly: interval semantics, timezone, range limit, and optional behavior. Output schema exists, so return structure does not need to be described.

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 descriptions already document start/end inclusivity and timezone interpretation, and include_forecast is explained. The description mostly restates these semantics rather than adding new meaning. Limit and offset are not described in the description, but their defaults and bounds are clear from schema metadata, so the schema carries the burden.

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: 'Returns Alberta Internal Load (AIL) observations in MW'. Clearly defines the data type, unit, and interval [start, end), making the tool distinguishable from related market and generation tools even without naming a sibling.

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 implies the tool is for retrieving AIL observations, with interval and forecast inclusion guidance, but it does not explicitly state when to prefer this over sibling tools like get_forecast or get_load_outage_forecast. No exclusions or alternatives are given, so usage context is clear but selection guidance is absent.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context beyond those: the data is hourly, in MW, the date range is inclusive and capped at 31 days, timestamps use America/Edmonton, and output is paginated. These are exactly the kind of operational details annotations don't convey, so the description meaningfully supplements 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, no wasted words. The first sentence front-loads what the tool returns, the unit, and the range; the second covers timezone and pagination. Every piece of information is essential for calling the tool correctly.

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?

Given the rich input schema, output schema, and annotations, the description is nearly complete. It covers the critical constraints an agent must know: inclusive dates, 31-day max, timezone, and pagination. The only minor gap is the behavior when the range exceeds 31 days (whether it errors or truncates), but this is not crucial because the cap is explicit.

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 schema description covers 100% of parameters (100% coverage), so baseline is 3. The description adds meaning beyond the schema by explaining that start_date and end_date form an inclusive range capped at 31 days, and that pagination applies (aligned with limit/offset). This directly enriches the parameter semantics.

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 verb 'Returns', the resource 'AESO hourly load-outage forecast observations in MW', and the date range constraint, which is specific and distinguishes this from generic tools like get_load or get_outages. However, it does not explicitly name a sibling tool or contrast itself with alternatives, so it stops short of full differentiation.

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 no guidance on when to use this tool versus the many sibling tools (e.g., get_load, get_outages, get_forecast). It does not mention conditions, exclusions, or alternatives, leaving the agent to infer the use case from the name alone.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description doesn't need to restate those. It adds useful context beyond annotations: the ~24-month forward-looking horizon and the fact that entries may be tentative with approval_status=tentative and not AESO-approved.

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 two sentences with no filler. The core function and key caveat are front-loaded, and the sibling disambiguation is placed at the end without redundancy.

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?

Given the output schema exists and annotations cover safety/idempotency, the description supplies the remaining essential selection context: temporal horizon, tentative approval status, and sibling differentiation. Nothing critical for an agent to call this tool correctly 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 description coverage is 100%, and the single parameter's description already explains that long-range reports are tentative/coordination listings and that only the current publication is supported. The tool description adds no further parameter-specific detail, so the baseline of 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?

The description uses a specific verb ('Returns'), names the exact resource ('Long Range Significant Transmission Outages'), and adds a temporal scope (~24 months ahead). It also distinguishes itself from the sibling get_approved_transmission_outages by flagging the tentative, non-AESO-approved nature of the data.

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 explicitly warns not to confuse this tool with get_approved_transmission_outages, providing a clear exclusion and identifying the alternative. It conveys that this tool is for tentative, not-yet-approved long-range outages, though it doesn't fully spell out when the approved tool should be preferred beyond the name and contrast.

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

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

The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description adds value by explaining that the view is 'cohesive' and 'current-state', and by specifying units (CAD/MWh, MW) and timezone (America/Edmonton). It does not define exactly how 'recent' is measured, but the output schema mitigates that gap.

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 compact and front-loaded, with two sentences that state the core purpose, enumerate included data, and add units and timezone. Every sentence earns its place with no filler or redundancy.

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?

This is a zero-parameter snapshot tool with an output schema, so the description is complete for invocation. It names the market and geographic scope, lists the major bundled metrics, and provides essential interpretation details such as units and timezone.

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 input schema has zero parameters, so there are no parameter semantics for the description to clarify. The baseline for no-parameter tools is satisfied, and the description appropriately focuses on output content instead.

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 uses a specific verb ('Returns') and names a precise resource ('Alberta electricity market'), then enumerates the metrics included, such as pool price, system marginal price, Alberta Internal Load, generation, net interchange, and operating reserves. This clearly distinguishes it from the granular sibling getters by positioning it as a cohesive current-state snapshot.

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: use this tool for a cohesive current-state view of multiple market metrics at once. It does not explicitly name alternatives or say when not to use it, but the snapshot framing makes the use case obvious relative to the granular sibling tools like get_pool_prices or get_generation.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the mutual exclusivity of filters, the 16-day limit on unfiltered requests, and pagination behavior. These are non-obvious execution traits the agent needs to know.

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, no filler. The main result is front-loaded, and constraints are packed efficiently.

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?

With output schema and rich annotations present, the description covers essential invocation details: unit, granularity, filter constraints, date-window limitation, and pagination. Nothing critical is missing for an agent to select and call 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?

The schema already covers the request object with property names and limits, so baseline is 3 at high coverage. The description adds semantic meaning by clarifying that asset_ids and pool_participant_ids cannot be combined and that omitting filters restricts the date window.

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 states a specific verb ('Returns') and resource ('hourly AESO metered energy in MWh by asset'), making it easy to distinguish from sibling tools like get_load or get_generation. The unit and granularity are explicit.

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?

Provides clear context: filters can be up to 20 asset IDs or pool-participant IDs but not both, unfiltered requests are limited to 16 days, and output is paginated. It does not explicitly name alternative tools or conditions for choosing them, so a full score is not warranted.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful behavioral context: the report is the current public report, includes cumulative CAD vs 1/6 annualized unavoidable costs, includes the trigger status, and uses America/Edmonton hour-ending interval timestamps.

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 concise sentences with no filler. The first sentence identifies the tool's output; the second adds content and timezone details. 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?

Given the simple one-parameter schema, the existing output schema, and the comprehensive annotations, the description is nearly complete. It clearly identifies what is returned and key formatting details. It lacks explicit usage-scenario guidance, but that is a relatively minor gap for this read-only report tool.

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 100%, so the baseline is 3. The description does not add anything about the 'request' or 'current_only' parameters beyond what the schema already states.

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 a specific verb ('Returns'), a specific resource ('AESO Monthly Cumulative Settlement Interval Net Revenue (MCSINR) public report'), and clarifies the report's key contents. This makes it easy to distinguish from the many sibling market-report tools.

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?

No guidance is provided about when to use this tool versus alternatives. For example, it mentions the secondary offer price limit trigger, but does not direct agents to a dedicated sibling tool like get_secondary_offer_price_limit when that is the only needed value.

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

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

The annotations already disclose read-only, idempotent, open-world, and non-destructive behavior. The description adds useful semantics like 'inclusive market-date range' and 'hourly', but it does not go into potential pagination behavior or data availability, which is acceptable given the annotation coverage.

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 a single, front-loaded sentence with no filler. Every word contributes meaning, making it appropriately concise for this tool.

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 output schema and annotations cover return shape and safety/idempotence, while the description provides the important inclusive-market-date-range semantics. It does not explain how to choose this tool over siblings or describe optional filters, but those are discoverable from the schema, so the definition is mostly complete.

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 0%, so the description must compensate for parameter meaning. It clarifies that the date range is inclusive and market-date based, but says nothing about reserve_types, limit, or offset. This is only partial compensation for the missing parameter documentation.

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 states a specific verb ('Returns'), the resource ('standby operating-reserve activation volume' and 'volume-weighted activation price'), granularity ('hourly'), and the date-range scope. This clearly distinguishes it from sibling tools like get_operating_reserve_prices and get_operating_reserve_forecast by focusing on activations rather than prices or forecasts.

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?

There is no explicit guidance about when to use this tool versus sibling alternatives. An agent must infer from the name and wording that it is about activations, and no conditions, exclusions, or alternative tool references are provided.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, and the description adds valuable context: data is current, public, seven-day, hourly, reported in MW, and covers active and standby volumes. It does not describe pagination or public-api limis, but no annotation contradiction exists.

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 a single focused sentence with no filler. It front-loads the action and most important scope facts, making every phrase informative.

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?

With rich annotations, an output schema, and only one nested input parameter, the description conveys the essential data scope well. It could be more complete about request-field semantics and sibling differentiation, but the schema and annotation context make the tool callable.

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 0%, yet the description only names the reserve types, which are already shown in the schema enum. It does not explain the required 'request' container or the limit/offset pagination controls, so the description fails to compensate for the low schema coverage.

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 starts with 'Returns' and clearly identifies the resource: a current public seven-day hourly forecast of active and standby regulating, spinning, and supplemental operating-reserve volumes in MW. It is specific and easily understood, though it does not explicitly distinguish itself from siblings like get_reserves or get_operating_reserve_prices.

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 terms 'forecast' and 'seven-day' imply use for near-term forecasted reserve volumes, but the description provides no explicit when-to-use or when-not-to-use guidance. It does not mention that get_operating_reserve_prices or get_operating_reserve_actives should be used for prices or actual activations.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable beyond-annotation context: the 60-day delay, units (CAD/MWh and MW), timezone (America/Edmonton), and paginated delivery, which help the agent interpret results and set expectations.

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 two sentences with no filler. It front-loads the action and resource, then packs essential constraints (delay, units, timezone, pagination) into the remaining sentence. 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?

With an output schema present, rich annotations, and a single required parameter, the description covers the key operational constraints: historical scope, delay, units, timezone, and pagination. A minor gap is that it does not define what 'Operating Reserve Offer Control' means, but the title and sibling context provide enough orientation for an agent.

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 100%, and the request object description already explains bounded output pagination. The main tool description adds units and timezone but does not add parameter-specific semantics beyond what the schema already documents; the baseline of 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?

The description clearly states a specific verb ('Returns'), a specific resource ('one historical AESO Operating Reserve Offer Control report date'), and a distinguishing behavior ('as paginated blocks'). It is easily distinguishable from sibling operating reserve tools, which cover prices, forecasts, or activations rather than offer control report dates.

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 implies usage for historical report dates and notes the 60-day release delay, giving useful context about when data will be available. However, it does not explicitly state when to prefer this tool over alternatives such as get_operating_reserve_prices or get_operating_reserve_forecast, nor does it mention any exclusions.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behaviors, so the bar is lower. The description adds useful interpretive context: that active price, standby premium, activation strike, and clearing blended price remain distinct. This prevents an agent from incorrectly aggregating or conflating these components.

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 carry exactly the needed information: the first defines the scope and outputs, the second clarifies an important semantic distinction. There is no wasted wording or repetition of schema details.

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?

Given the output schema and rich annotations, the description covers the core domain and return semantics, but lacks usage guidance and pagination behavior. It also does not specify allowed date ranges or timezone conventions, which an agent would need for correct invocation. It is adequate but not fully complete.

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 0%, so the description must compensate for parameter documentation. It references the reserve_types enum values ('regulating, spinning, or supplemental') and 'time block' which loosely maps to start_date/end_date and the product dimension. However, it does not explain the request wrapper, limit/offset pagination, or date format, leaving a meaningful gap.

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 states a specific verb ('Returns') and resource ('operating-reserve price components and volumes') and identifies the key dimensions (regulating/spinning/supplemental product, time block, active versus standby). This makes it clearly distinguishable from siblings like get_operating_reserve_activations, get_operating_reserve_forecast, and summarize_operating_reserve_market.

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?

There is no explicit guidance about when to use this tool versus alternatives. The description implies it is for daily reserve price data, but it does not mention exclusions, preferred scenarios, or sibling tools. An agent would have to infer usage from the resource name and content.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context beyond annotations: hourly granularity, half-open interval semantics, timezone (America/Edmonton), and that the response is a total with per-fuel breakdowns. No contradiction with annotations.

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 compact sentences deliver the essential purpose, interval behavior, timezone, and routing to alternatives. Every clause earns its place, and the most decision-relevant information is front-loaded.

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?

Given the output schema exists, annotations cover safety traits, and the parameter schema documents the two inputs completely, the description adds the remaining needed semantics (hourly aggregation, interval boundaries, per-fuel components, timezone, and sibling differentiation). Nothing critical is missing for an agent to select and call this 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 coverage is 100%, and both parameters already have thorough descriptions including timezone handling and inclusive/exclusive semantics. The description reinforces hourly interval behavior but does not need to add parameter-level detail; the schema does the heavy lifting, so 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?

The description names a specific verb ('Returns'), a precise resource ('hourly AESO generator outage capacity by technology/fuel'), and the interval semantics ('[start, end)'). It also clarifies the output composition ('Total Outage MW plus per-fuel components'), which makes the tool's purpose unambiguous and distinct from the transmission outage tools.

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 explicitly states when to use alternatives: 'For transmission planned outages use get_approved_transmission_outages or get_long_range_transmission_outages.' This directly differentiates generator outages from transmission outages, giving an agent clear routing guidance without needing to inspect sibling tools.

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