aeso-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct data type or analytical task. Overlapping tools like get_pool_prices vs get_system_marginal_prices are explicitly differentiated, and outage tools are clearly separated by generator, approved transmission, and long-range tentative. No two tools could be reasonably confused.
Naming Consistency4/5
Most tools follow a consistent 'get_' + noun pattern (e.g., get_load, get_generation, get_outages). Analytical tools break the pattern with verbs like compare, find, explain, summarize, and assess, but these are still clear and predictable actions. The mix is minor and doesn't hinder readability.
Tool Count3/5
With 27 tools, the server exceeds the ideal 3-15 range and even the 'heavy' 16-25 range. However, the Alberta electricity market domain is broad, and each tool covers a distinct data stream or report, making the count justifiable. Still, it feels slightly bloated and could overwhelm agents.
Completeness5/5
The tool surface covers the core market data spectrum: prices (pool and SMP), load, generation, interchange, reserves, outages (generator and transmission), assets, financial settlement, and capacity. It also includes analytical aggregation tools for comparison and event detection. No obvious gaps for typical market queries or analyses.
Average 4.3/5 across 27 of 27 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on August 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, openWorld, idempotent, non-destructive), so the bar is lower. The description adds valuable behavioral context: the 60-day release delay, units (CAD/MWh, MW), timezone (America/Edmonton), and the paginated structure. These details help the agent interpret results correctly and set expectations, going beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero fluff. The core purpose is front-loaded, followed by three critical factual details (delay, units, timezone) each earning its place. No redundancy with the schema or annotations. This is an exemplar of concise, information-dense writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, single-date retrieval tool with an output schema, this description covers the essentials: what it returns, the delay, units, timezone, and pagination. One could argue it should clarify what 'offer blocks' are, but given the domain context and the output schema, this is sufficient. It is complete enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the request object is described as 'Request one AESO report date with bounded output pagination,' and the nested properties (limit, offset, report_date) have constraints and defaults. The description does not add further parameter-level meaning beyond what the schema already conveys; it mentions pagination but doesn't elaborate on limit/offset semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Returns'), a specific resource ('AESO Energy Merit Order report date'), and a precise output form ('paginated offer blocks'). This clearly distinguishes it from sibling tools like get_pool_prices or get_system_marginal_prices, which serve different data needs. The single-date scope is also explicit, so an agent immediately knows what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any of its 26 siblings. It does state the 60-day release delay, which implies it's for historical data, but nothing explicitly says 'use this when you need X' or names an alternative. The agent is left to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive traits. The description adds valuable behavioral details beyond those: inclusive date range, pagination, and inclusion of affected paths and event boundaries in a specific timezone. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The primary action and scope are front-loaded, followed by essential output characteristics. Every clause serves a purpose, and the definition is appropriately brief for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core calling context: what is returned, date range semantics, pagination, timezone, and the specific resource domain. Since an output schema exists, return value details are not required. Minor omissions like default ordering or error behavior are acceptable given the provided annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the request object description already states 'inclusive AESO report-date range' and 'bounded output pagination'. The tool description repeats this ('inclusive date range', 'output is paginated') without adding new meaning for start_date, end_date, limit, or offset. It meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Returns'), a specific resource ('outages affecting AESO interties or flowgates'), and scoping ('inclusive date range'). It immediately differentiates from generic outage tools like get_outages by naming the intertie/flowgate domain, making the agent's selection unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as get_outages, get_approved_transmission_outages, or get_long_range_transmission_outages. It does not state exclusions or preferred conditions, leaving the agent to infer the use case 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, idempotent, and non-destructive hints. The description adds useful behavioral context: threshold can be absolute or percentile (default 90th), output includes event boundaries, duration, peak/average price, and load context 'when available', which clarifies variable output completeness. This goes beyond annotation defaults 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight paragraph of three sentences. The primary purpose is front-loaded, followed by threshold logic and output summary. Every sentence adds necessary information with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (nested request object, multiple parameters) and an output schema exists. The description provides a high-level overview of functionality, threshold mechanisms, and output elements, covering the essential aspects. It does not detail timezone handling or exact event definition, but these are addressed in the schema. Given the presence of output schema, the description is sufficiently complete for an agent to understand the tool's purpose and key behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 each parameter (start, end, percentile, min_duration_hours, threshold_cad_per_mwh). The description adds minimal new meaning: it restates the threshold options and default, which is also in the schema. It does not elaborate on interval semantics beyond schema, so it adds little value beyond the structured definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects sustained high Pool Price events over a specified interval, a specific verb-resource pair. It differentiates from siblings like get_pool_prices (raw prices) and compare_market_periods (comparisons) by highlighting event detection and output summarization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: the description explains what the tool does (detect events) but does not explicitly state when to use it versus alternatives or mention exclusions. There is no reference to sibling tools for raw price retrieval or other functions, leaving the agent to infer appropriate use from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the note that results may be truncated by the limit parameter, which is useful context beyond annotations. However, it does not elaborate on the truncation behavior (e.g., whether pagination exists) or other behavioral aspects like response size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the action and resource, lists key filters, and notes the limit behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one nested request parameter) and the presence of an output schema, the description is largely complete. It covers the resource, filters, and limit truncation. It does not mention error cases or default behavior when no filters are applied, but these are minor gaps for a read-only retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the request object is described and all fields have types/defaults), but individual properties lack descriptive text. The tool description explicitly names the filter fields (asset_id, pool_participant_id, operating_status, asset_type) and explains their role as optional filters, adding semantic meaning beyond the raw schema. The limit parameter's truncation effect is also explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns AESO market asset registry records and enumerates the specific optional filters (asset ID, pool participant, operating status, asset type). This makes the purpose unambiguous and distinguishes it from sibling tools that handle other market data like outages or prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no explicit guidance on when to use it versus alternatives, nor any exclusions. The purpose is reasonably implied by the name and context, but with many sibling get_* tools, a brief 'use this for asset registry queries' would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds useful behavioral context: the current snapshot includes all fuels in MW, and renewable share is computed as wind+solar+hydro over total generation. It also notes historical data is 'where available' in the schema description. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the core purpose, followed by two distinct usage instructions, and a final note on renewable share computation. Each sentence adds value with no redundancy or filler. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return value details are handled separately. The description covers both invocation modes, the fuel scope, and the renewable share metric. Pagination parameters (limit/offset) are present in the schema and need no description. For a read-only data retrieval tool with clear modes, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the 'request' parameter already explains the two modes (without a date range vs with a date range). The tool description repeats this guidance, adding only the MW unit for the current snapshot. Since schema coverage is 100% and the description adds minimal new semantic detail beyond that, it meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns Alberta generation data' – a specific verb and resource. It then delineates two modes: current fuel-mix snapshot and historical wind/solar, making the tool's scope unambiguous. It does not explicitly name a sibling tool for differentiation, but the content is clear enough to distinguish from related tools like get_generation_capacity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions for the two invocation modes: 'Omit start/end for the current fuel-mix snapshot' and 'Provide start and end for historical wind and solar...'. This is clear context for using the tool itself. However, it does not mention alternatives among sibling tools or exclusions, so it lacks guidance on when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds concrete output details (mean error, MAE, RMSE, MAPE, paired intervals) and clarifies timezone handling (America/Edmonton), which goes beyond the schema. This aligns with annotations; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The core purpose is front-loaded, followed by return metrics and timezone. Every sentence earns its place, and the structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, the description need not detail return structures. It covers purpose, scope, unit, metrics, and timezone. Annotations handle safety, so an agent has everything needed to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so start and end are already well-documented including timezone interpretation. The description adds the inclusive/exclusive interval notation ([start, end)) and reiterates the timezone, which is slightly redundant but adds minor clarifying value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Compares'), a precise resource ('Alberta Internal Load forecast versus actual'), a defined scope ('[start, end)'), and unit ('MW'). It clearly distinguishes this from siblings like compare_market_periods, which compares market periods, not forecast vs actual.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for forecast-versus-actual comparisons but does not explicitly state when to choose it over alternatives or mention any exclusions. Sibling tools like get_load or compare_market_periods exist, but no 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds a meaningful behavioral trait with 'Does not assert causation,' which is a caveat about interpretation. It also specifies the output scope (aggregate statistics) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero redundancy. The purpose is front-loaded, followed by output specifics and a caveat. Every sentence earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, the description is complete. It specifies the timezone (America/Edmonton), the output categories (averages, min/max/median, load stats, deltas), and the no-causation caveat. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the request object's description mirrors the tool's purpose. The description does not add parameter-specific semantics beyond what the schema provides (e.g., date-time formats, required fields). Baseline 3 is appropriate because the schema handles the documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('compares'), resource ('aggregate pool-price and load statistics'), and scope ('two America/Edmonton market periods'). It clearly distinguishes itself from sibling tools like get_pool_prices or get_load, which are single-period queries, by focusing on comparison and deltas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage scenario is implied: it is for comparing two periods, as opposed to retrieving a single metric. However, the description does not explicitly state when to use this tool versus alternatives, nor does it list exclusions or prerequisites. No guidance is given about edge cases like overlapping periods or data availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and open-world behavior. The description adds essential behavioral context: timestamps in America/Edmonton and a 90-day maximum range, plus the optional forecast field. This supplements the annotation without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences: the first states the core function and interval, the second covers forecast and timezone/range. Efficient and front-loaded, with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool, the description covers essential constraints: interval semantics, timezone, max range, and forecast option. The output is handled by the output schema, so nothing needed to invoke correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (start, end, limit, offset, include_forecast) are documented. The description reinforces the interval [start, end) and forecast option, but does not add meaning beyond the schema, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Returns Alberta Internal Load (AIL) observations in MW' with explicit interval semantics ([start, end)). This clearly identifies the verb, resource, and units, and distinguishes it from sibling tools like get_load_outage_forecast without needing to read schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes optional forecast inclusion and defines timezone and duration limits, but does not explicitly state when to use this tool over alternatives. It implies usage for AIL observations but lacks explicit exclusions or conditions for sibling choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds valuable context: the 60-day release delay, units (CAD/MWh, MW), and timezone (America/Edmonton). These details go beyond annotations and help the agent interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero fluff. The core purpose is front-loaded, followed by essential data conventions. Every clause adds value: pagination, delay, units, and timezone. No unnecessary words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover safety, the description fills the remaining gaps: what data is returned (a single date), how it is delivered (paginated blocks), and important conventions (delay, units, timezone). An agent has everything needed to call the tool correctly and interpret results without missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the request object is described as 'Request one AESO report date with bounded output pagination.' The description does not add extra syntax or format details about parameters beyond what the schema already provides. With complete schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact verb ('Returns'), the resource ('AESO Operating Reserve Offer Control report'), and the scope ('one historical ... date as paginated blocks'). This is specific and unambiguous, distinguishing this tool from siblings like get_reserves or get_market_snapshot without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual clues (historical data, 60-day delay, paginated blocks) that imply when this tool is appropriate, but it does not explicitly state when to use it versus alternatives or mention any exclusions. An agent could infer usage from the resource name, but there is no direct guidance on alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 value by specifying that the data is 'current' and that certain volumes are included 'when published,' indicating potential unavailability. This enriches the behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose (returns indicators in MW) and then enumerates specific components. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only tool with an output schema, the description is entirely sufficient. It names the resource, units, and specific data types returned, while the output schema handles return structure. 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers 100% of parameters. Per the baseline for 0-param tools, a score of 4 is appropriate; the description does not need to add parameter details since there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), a clear resource ('current AESO operating reserve indicators'), units (MW), and enumerates specific metrics (contingency reserve required/dispatched, fast frequency response volumes). This clearly distinguishes it from siblings like get_operating_reserve_offer_control, which deals with offers rather than current indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. While siblings are listed in context, the description does not reference them or provide any selection criteria. The only usage hint is 'when published,' which is about data availability rather than tool choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by explaining that a null limit means the cap is not in effect, and clarifies that the report is the 'current' one. The annotations already declare read-only/idempotent, so the additional null-semantics explanation is valuable and not redundant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action ('Returns the current...') and then explains the key semantic (null meaning). Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema (so return values need not be described), and the description covers the essential behavior and edge case (null limit). 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the 'request' parameter and its 'current_only' property are documented in the schema). The description does not add further meaning to the parameters; it only restates the report contents. Baseline 3 is appropriate because the schema already carries the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 specific resource ('AESO Secondary Offer Price Limit public report'), and clearly distinguishes it from sibling tools by naming the exact data it provides. It is not a tautology and instantly tells an agent what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need the secondary offer price limit) but does not explicitly mention alternatives or when not to use it. Since the tool name is highly specific, the usage is fairly obvious, but there is no explicit routing guidance compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 valuable context: explicit statement that it does not claim causation, that it includes observed metrics and associated_changes, and that the model should produce the natural-language explanation—beyond the safety profile provided by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The main purpose and key behavioral caveat are 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (has output schema: true) so return structure is covered. The description clearly explains the comparison window concept, the default baseline, and the expectation of model-generated explanation. It is complete for a read-only analytical tool, though it could mention edge cases or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and includes a description for baseline_start; the description adds minimal parameter detail beyond confirming the default baseline window, which is already in the schema. The baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns structured evidence') and resource ('market conditions in a focus window versus a baseline window'). Explicitly differentiates from siblings by noting it does not claim causation and that the calling model should produce the explanation, which is a clear distinguishing behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use for comparative analysis of market windows, and that the model must generate the explanation. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read-only, idempotent behavior. The description adds valuable behavioral details: a 100-day date range limit and pagination, which are not covered by annotations. It also discloses optional versioning, providing additional context beyond the structured metadata without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence states the core output, the second adds critical constraints. The most important info (what data is returned) is front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 doesn't need to explain return formats. It covers key limitations (date range, pagination) and options (hour-ending, versions) sufficiently for a nested-parameter tool. Minor gap: 'versioned reports' is vague, but not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only has a top-level 'request' object with a generic description, leaving the inner fields (e.g., start_hour_ending, include_versions) undocumented. The tool description compensates by explaining that the tool supports hour-ending bounds and versioned reports, and mentions pagination via limit/offset. Although it doesn't map each field explicitly, it gives enough semantic grounding for an agent to infer parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and specifies the exact data types (ATC, TTC, reliability margins, gross offers) and scope (AESO interties and flowgates). It distinguishes this from sibling tools like get_pool_prices or get_load by naming the resource type, so an agent can identify the correct tool without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions features (hour-ending bounds, versioned reports) and constraints (date limit, pagination) but does not explicitly state when to choose this tool over alternatives or when not to use it. It implies usage for intertie capability data, but lacks direct exclusions or comparison with sibling tools like get_intertie_outages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, openWorld, idempotent), the description adds valuable behavioral details: timezone handling ('Timestamps use America/Edmonton'), pagination ('output is paginated'), and the inclusive 31-day limit. These are not in the annotations and help the agent anticipate response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and immediately adds essential operational details (timezone, pagination, range limits). Every element contributes value with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only, idempotent nature and an output schema that defines the return structure, the description sufficiently covers key usage aspects: data type, units, timezone, pagination, and range constraints. Minor gaps like error handling or empty-result behavior are not critical for a forecast lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though the schema parameters (start_date, end_date, limit, offset) are self-explanatory, the description adds meaningful constraints: 'inclusive, maximum 31-day range' clarifies date semantics, and 'paginated' explains limit/offset usage. With 100% schema coverage, the description still enriches parameter understanding by highlighting limits and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), a clear resource ('AESO hourly load-outage forecast observations in MW'), and includes critical constraints (inclusive, 31-day range). It is distinguishable from sibling tools like get_outages or get_load because it explicitly targets load-outage forecasts, not general outages or load values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (retrieving load-outage forecast data) but does not explicitly contrast it with alternatives or state when not to use it. Since siblings include get_outages and get_load, an agent might benefit from a note about choosing this tool for forecast data specifically, but the purpose is clear 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive traits, so the bar for additional disclosure is lower. The description adds meaningful behavioral context: data may be tentative, not AESO-approved, and spans ~24 months, which is extra value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and includes the key caveat (tentative) and a sibling disambiguation. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 safety, the description supplies the essential usage context: time horizon, data quality, and a direct alternative. It could be marginally richer by mentioning other outage tools, but nothing critical for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'request' object and its 'include_tentative_only' property. The description adds no parameter-specific information, placing it at the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), a precise resource ('Long Range Significant Transmission Outages'), and a distinguishing scope ('~24 months ahead'). It also explicitly warns against confusing it with get_approved_transmission_outages, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly cautions against using this tool instead of get_approved_transmission_outages, and notes that entries may be tentative/non-AESO-approved, implying it's for planning ahead. However, it does not mention other outage-related siblings (e.g., get_outages, get_intertie_outages), so the guidance is not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive traits. The description adds valuable behavioral details beyond annotations: the 16-day limit for unfiltered requests, pagination requirement, and the mutual exclusivity of filter types. These are not obvious from the schema and aid correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core return value and then adding key constraints. No filler or repetition; every clause carries essential information for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the description covers the main usage nuances: filtering constraints, time limits, and pagination. It doesn't explain error cases or exact response format, but the output schema exists and annotations handle safety, making it sufficiently complete for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has descriptions, they are generic ('Request metered volumes'), so the description meaningfully clarifies parameter usage: asset_ids and pool_participant_ids are filters that cannot be combined, start/end dates define the range, and limit/offset handle pagination. This adds semantics beyond the schema's type and constraint declarations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns hourly AESO metered energy in MWh by asset, using specific verbs and resource scope. It is distinct from siblings like get_load or get_generation that return different data, and the mention of filtering by asset/participant IDs further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage constraints: filtering by up to 20 asset or participant IDs, not simultaneously, a 16-day limit for unfiltered requests, and pagination. However, it does not explicitly compare to alternative tools or state when to prefer this over siblings, leaving the choice to the agent without direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read profile is covered structurally. The description adds value beyond annotations by disclosing the 400-bucket cap and the compact aggregate nature of the response, which informs the agent about output limits and behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core function is front-loaded in the first sentence, and the second sentence delivers the usage guidance and the key constraint (400-bucket cap) efficiently. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nested-request tool with an output schema and full annotations, the description covers what it returns, the time semantics, why to use it, and its output limit. The inclusive/exclusive start and end interpretation rules live in the schema descriptions, so nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters (end, start, bucket, include_load) already documented with types and defaults. The description lightly reinforces the bucket enum ('hourly, daily, weekly, or monthly') and the include_load flag ('optional Alberta Internal Load statistics'), but the schema does the heavy lifting, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), specific resources (Pool Price statistics, Alberta Internal Load statistics), and the time semantics ([start, end)). It clearly distinguishes this aggregation tool from the raw-series sibling tools like get_pool_prices, get_load, and get_system_marginal_prices by emphasizing it returns compact, summarized statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use this tool: 'Use this before requesting raw series for long periods.' This gives clear context for selecting the tool, though it doesn't name specific sibling alternatives by name. The 400-bucket cap further clarifies the boundary of when this tool is appropriate versus raw series tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description goes beyond annotations by specifying the report's contents (cumulative costs, trigger flag) and the timestamp convention (America/Edmonton hour-ending). This adds useful behavioral context without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence names the tool's primary output, the second elaborates on contents and timezone. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter (with full schema coverage) and an output schema is present, so the description does not need to explain return formats. It covers the report's purpose, key contents, and timestamp convention, which is sufficient for an agent to correctly invoke it. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single `request` parameter and its `current_only` property are fully documented in the schema. The description adds no extra parameter-level detail beyond what the schema already provides, so it meets the baseline for well-covered parameters without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb "Returns" and names the exact resource: "AESO Monthly Cumulative Settlement Interval Net Revenue (MCSINR) public report". It lists concrete contents (cumulative CAD vs 1/6 annualized unavoidable costs, trigger status) that leave no ambiguity. None of the sibling tools cover cumulative net revenue, so it 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly defines the tool's purpose (returning the current MCSINR report) and includes that only the current publication is supported via the `current_only` parameter. It does not explicitly state when not to use it or name sibling alternatives, but the report's uniqueness in the sibling list makes the usage context clear without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavior info: it returns transparent arithmetic and a deterministic screening signal, and explicitly disclaims that it is not an official declaration or causal explanation. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function and output, followed by a clarifying exclusion. Every word earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does, what it returns (arithmetic plus a signal), and its scope limitations. It relies on the output schema for return format details, which is appropriate. The only minor gap is not providing more explicit usage guidance, but that is already covered under usage_guidelines. Overall, it is sufficient for a parameterless tool with a rich output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The schema is empty with 100% coverage, meaning there is nothing to document. The description does not mention parameters, but none exist, so it does not need to. It adds no redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool combines the current market snapshot with hourly available generation capability and outages to produce supply-margin arithmetic and a screening signal. It distinguishes itself from siblings by explicitly stating what it is not ('not an AESO declaration or a causal price explanation'), which helps differentiate from explain_market_conditions and find_price_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on what data it uses and the nature of the output, and it excludes specific use cases (not an AESO declaration, not a price explanation). However, it does not name alternative tools or explicitly state when to prefer this tool over siblings, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds valuable behavioral specifics: inclusive range, 31-day bound, pagination, and timezone of timestamps. These go beyond annotations and help the agent understand response veracity and constraints. No mention of rate limits or error conditions, but annotations reduce the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core function first, then constraints and content. There is no fluff or repetition; every clause adds information (inclusive range, 31-day bound, pagination, timestamps, timezone). It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (per context signal) and annotations cover the safety profile, the description need not explain return values or side effects. It adequately specifies the required input parameters and their constraints. The only minor omission is not stating that end_date must be >= start_date, but that is implicit in an inclusive date range. Overall, it is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has high coverage (100% per context signal) but the individual fields (start_date, end_date, limit, offset) lack explicit descriptions. The tool description compensates by clarifying the meaning of the date range ('inclusive', bounded to 31 days) and mentions pagination, which implies the role of limit/offset. This adds meaning beyond the schema's basic types, so a 4 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Returns' with a specific resource 'AESO generating-unit commitment directives', and adds scope (inclusive date range, paginated, 31-day bound) and content (timestamps in America/Edmonton). This distinguishes it from sibling tools that target outages, prices, and load, all of which are clearly different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual constraints (inclusive date range, 31-day maximum, pagination) but does not explicitly mention when to choose this over alternatives. However, given the uniqueness of the resource (commitment directives) among siblings, the usage context is clear without exclusions. It lacks an explicit 'when not to use' or naming of alternatives, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: hourly granularity, a 31-day bound on the inclusive date range, values in MW, pagination, and the specific inclusion of operating and mothball outages by fuel class. These details inform the agent about output shape and constraints. Since annotations already declare readOnly, openWorld, idempotent, and non-destructive hints, the description enriches rather than repeats, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core action ('Returns hourly AIES maximum and available generation capability') followed by key qualifiers (outages, fuel class, date bound, units, pagination). There is no redundancy or fluff; every clause contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (per signal) and annotations cover safety, the description is complete for an agent to call the tool correctly. It specifies the data granularity, units, date-range limitation, pagination, and the specific content (capacity and outages). No critical detail needed for invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the request object's description covers the parameters), so the baseline is 3. The description adds the critical constraint that the date range is bounded to 31 days and clarifies that it is inclusive—details not explicitly stated in the schema. This compensates for the schema's brevity and provides additional semantic value for parameter interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and a detailed resource: 'hourly AIES maximum and available generation capability plus operating and mothball outages by fuel class.' This precisely distinguishes it from siblings like get_generation (which likely returns actual generation) and get_outages (general outages). The inclusion of 'by fuel class' and specific outage types makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance: it is for hourly capacity data, with a date range bounded to 31 days, and includes outage information. It implicitly signals when to use it (when required output is capacity and outages) but does not explicitly name alternatives or state when not to use it. The context is strong enough to guide selection without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: the positive/negative path sign convention follows AESO Current Supply Demand standards, and the inclusion of net interchange. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the core purpose and units (MW) before mentioning the sign convention. Every clause adds value; there is no filler. It is ideal in length and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a zero-parameter tool with a rich output schema (has output schema: true), the description provides everything needed to call the tool correctly: what data is returned (flows per path), the unit (MW), the inclusion of net interchange, and the sign convention. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4, and the description does not need to clarify parameter meanings because there are none. It adds no unnecessary param info, so 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), a clear resource ('current Alberta interchange flows by path in MW'), and includes net interchange. It distinguishes this tool from siblings like get_intertie_capability (which measures capability, not flows) and get_intertie_outages (outage status). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool provides current flows, which implies it is for real-time interchange data rather than capability or scheduled outages. However, it does not explicitly name alternative tools or state when not to use it. The context is clear but lacks explicit exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context: it specifies the exact data included, units (CAD/MWh and MW), and timezone (America/Edmonton). This provides value beyond the annotations and gives the agent expectations for the returned data without over-explaining.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('cohesive current-state view') and then lists the included data and essential metadata (units, timezone). Every clause earns its place; there is no filler or redundancy. It is both concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only snapshot tool with an output schema available, the description is complete. It identifies what data is returned, the units, and the timezone, which are the only contextual details an agent needs to decide to call and interpret its result. No additional prerequisites, side effects, or environmental dependencies are relevant given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by default and there is nothing to describe. The description does not need to add parameter meaning since none exist. A baseline of 4 is appropriate because the tool is parameterless and the description correctly focuses on output rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('cohesive current-state view of the Alberta electricity market') and enumerates the included data fields (pool price, system marginal price, load, generation, interchange, reserves). It clearly distinguishes itself from the sibling tools which handle individual data streams (e.g., get_pool_prices, get_load), making it obvious this is a composite snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a consolidated market overview ('cohesive current-state view') but does not explicitly state when to prefer this over individual getters or when not to use it. However, given the sibling set, the intent is clear enough that an agent would understand to use this when a high-level snapshot is needed. No explicit exclusions or prerequisites are given, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnly, openWorld, idempotent, and non-destructive hints, so the description only needs to add context. It adds the timezone (America/Edmonton) and interval semantics (exclusive end), plus the return structure (Total Outage MW plus per-fuel components). It doesn't discuss rate limits or error behavior, but with strong annotation coverage and an output schema, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The main purpose is front-loaded, followed by the timezone note and the alternative routing. Every sentence adds value and the structure is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema provided, the description doesn't need to explain return values. It covers the interval, timezone, and tool differentiation. For a nested-request tool with robust annotations and schema, nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both start and end have detailed descriptions including format and timezone interpretation. The description repeats the interval semantics but adds no new parameter-specific information. Baseline 3 applies because the schema already documents the parameters thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the exact resource (AESO generator outage capacity), granularity (hourly), scope (by technology/fuel), interval semantics ([start, end) with exclusive end), and explicitly contrasts with transmission outages by naming sibling tools. This clearly distinguishes it from get_approved_transmission_outages and get_long_range_transmission_outages 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names when not to use this tool ('For transmission planned outages') and provides two alternative tools. The purpose statement itself implies the use case (generator outage data), and the exclusion is clear. This gives an agent enough routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable context beyond annotations: timezone handling, the inclusive/exclusive interval semantics, and the maximum range, which informs expected response scope and avoids edge-case failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The core function and interval are stated first, followed by the alternative usage and constraints. Every word earns its place, and the structure is front-loaded for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return format is not needed. The description covers the essential behavioral aspects (what it returns, interval, timezone, range, and alternative). It could mention pagination behavior, but that is documented in the schema via limit/offset, so completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema already documents start/end inclusivity and timezone, the description adds the global range limit (366 days) and reinforces the interval syntax [start, end). With schema coverage at 100%, the baseline is 3; the added constraint and context justify a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns actual AESO hourly Pool Price observations in CAD/MWh for a specified interval. It also distinguishes itself from get_system_marginal_prices, which provides minute-level real-time pricing, so an agent can immediately tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to use the alternative (get_system_marginal_prices for minute-level pricing) and provides critical usage constraints: timezone (America/Edmonton) and maximum range (366 days). This leaves no ambiguity about when to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context: timezone handling ('America/Edmonton'), interval boundary semantics, and the 7-day range limit. It does not discuss pagination or response size, but the output schema and limit/offset parameters cover that. This is a solid addition beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The core functionality is front-loaded, followed by the routing alternative and key constraints. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential calling context: units, timezone, interval semantics, range limit, and the alternative tool. The output schema exists, so return values are documented. An agent has everything needed to correctly invoke this tool without further research.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (start/end have descriptions with timezone and inclusivity). The description adds value by specifying units ('CAD/MWh'), 'minute-level' resolution, and the 'Maximum range: 7 days' constraint, which are not in the schema descriptions. It also clarifies the inclusive/exclusive interval pattern. This goes beyond the schema's structured info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns'), resource ('AESO System Marginal Price (SMP) observations'), units ('CAD/MWh'), and interval semantics ('minute-level ... [start, end)'). It also explicitly differentiates from the sibling get_pool_prices, making the distinction clear 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit when-not-to-use instruction by directing users to get_pool_prices for hourly settlement prices, and sets a concrete constraint (maximum range 7 days). This gives an agent clear decision criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond these, such as the fact that historical start/end select publication windows (not outage intervals) and that they are 'tightly bounded because upstream navigation walks archive pages'. This explains non-obvious behavior that the annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long with zero redundancy. It front-loads the core purpose, then gives usage guidance, and finally clarifies distinctions. Every sentence earns its place, and the structure leads with the most critical information first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested request object, date-time params), the description covers purpose, usage, parameter semantics, and scope boundaries. An output schema exists, so return value details are not the description's job. Nothing essential is missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema defines start/end formats and defaults. However, the description adds crucial semantic clarity: it explains that start/end are for publication windows rather than outage intervals and clarifies the omission rule for the current report. This meaning is not present in the schema alone, so the description significantly enhances correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), a precise resource ('AESO-approved planned transmission outages'), and an explicit filter ('approval_status=approved'). It also distinguishes itself from sibling tool categories ('Distinct from generator outages and from long-range tentative outages'), making it clear what this tool is and is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Omit start/end for the current public publication' and 'Historical start/end select publication windows'. It also provides when-not guidance by naming the exclusions ('generator outages', 'long-range tentative outages'), which map to sibling tools, effectively routing the agent to the right alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![aeso-mcp MCP server](https://glama.ai/mcp/servers/bchoi-qwe/aeso-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bchoi-qwe/aeso-mcp)

Score Badge

Copy to your README.md:

[![aeso-mcp MCP server](https://glama.ai/mcp/servers/bchoi-qwe/aeso-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bchoi-qwe/aeso-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bchoi-qwe/aeso-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server