Explicitly labeled real-time market prices (currently WEIM), kept separate from day-ahead curves. Requires an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO 8601 end (default: now) | |
| from | No | ISO 8601 start (default: last 24h) | |
| zone | Yes | Market reference code, e.g. 'US-WEIM-AZPS' | |
| market | No | Optional market filter, e.g. 'weim' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It adds the API key requirement and current market scope (WEIM), which is useful, but it does not mention rate limits, response format, pagination, or any potential side effects. This is a modest but non-trivial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no redundant information. Every word contributes to understanding the tool's scope or requirements, making it exceptionally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 params, all schema-described, no output schema), the description provides adequate context: real-time price retrieval, WEIM market focus, and API key requirement. It does not explain return value structure or default behaviors beyond schema defaults, but these gaps are partially covered by the schema and the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context that the tool returns real-time WEIM prices, which aligns with the zone and market parameters, but it does not explain any parameter behavior beyond what the schema already provides. No additional parameter-level detail is supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving real-time market prices, explicitly scoped to WEIM, and distinguishes it from day-ahead curves via the sibling get_prices. The verb+resource is implied by the name and confirmed by the description, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The mention of 'currently WEIM' and 'separate from day-ahead curves' implies this tool is for real-time prices, but it does not explicitly state when to choose this over get_prices or other siblings. It provides no direct alternative guidance, only a subtle contrast, so usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool addresses a distinct data domain or action: zone discovery, price retrieval (day-ahead vs real-time), forecasting, carbon intensity, renewables generation, and cost-optimized scheduling. Even closely related tools like get_prices and get_forecast are clearly separated by their descriptions.
The get_ prefix is used consistently for data retrieval, and list_zones follows the expected list_ convention. The only outlier is cheapest_window, which would fit the pattern better as get_cheapest_window, but the inconsistency is minor.
Seven tools is well-scoped for an electricity market data API. Each endpoint represents a meaningful capability without redundant or filler tools, and the count supports both simple lookups and more advanced optimization workflows.
The toolset covers zone discovery, day-ahead and real-time prices, probabilistic forecasts, carbon intensity, renewables generation, and load scheduling. Minor gaps exist around historical data and broader market detail, but core workflows are well supported.