Day-ahead electricity prices in each zone's native currency and native market resolution. Requires an API key; Home starts at voltcast.com/register?plan=home.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO 8601 end (default: tomorrow) | |
| from | No | ISO 8601 start (default: yesterday) | |
| zone | Yes | Bidding zone code, e.g. 'DE-LU' | |
| resolution | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must relay all behavioral context. It does disclose that an API key is required and that data is in native currency and native market resolution, which is meaningful. It does not address limits, pagination, or whether the result is a list or single value, so there are still gaps.
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 every sentence carries information. The auth/registration note is concise and directly actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The is enough to understand domain and auth, but no output schema is provided, and the description does not explain what the result structure looks like or how the selected zone and date range shape the response. With four parameters and no output schema, a bit more clarity on the returned data shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents zone, from, and to with descriptions; only 'resolution' lacks a description. The description adds value with the 'native market resolution' terminology, supporting the resolution enum. However, it does not explain the resolution parameter's default or the impact of 'hourly' vs 'native'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns day-ahead electricity prices with native currency and native market resolution. This differentiates it from get_realtime_prices, which suggests current/real-time data. It does not name the exact sibling alternatives, but the day-ahead qualifier makes the core 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 description mentions a real requirement for an API key but does not explain when to use this tool instead of get_realtime_prices, get_forecast, or other siblings. No explicit when-to-use or when-not-to-use guidance. The day-ahead distinction is implied but left to the agent to infer.
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.