Probabilistic price forecast (P50 curve; P10/P90 on Pro+) up to 7 days ahead. Home and grandfathered Free keys are scoped to their selected zone. Accuracy published daily at voltcast.com/accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | Yes | ||
| horizon | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses meaningful traits: output variants depend on plan (P10/P90 only on Pro+), Home and grandfathered Free keys are scoped to a selected zone, forecasts extend up to 7 days, and accuracy is published externally. It stops short of describing response shape, timezone, or units, so there is still some room.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The core behavior is front-loaded, the key-scoping caveat comes second, and the accuracy link is useful external context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description is arguably 'mature': it covers what the forecast looks like, the allowed maximum horizon, plan restrictions, and an accuracy resource. It is missing exact zone-value guidance and explicit default behavior for horizon, but these are partially addressed by the schema enum and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must help explain the parameters. It adds context for the forecast horizon ('up to 7 days ahead') and implies zone selection, but it does not explicitly map the `horizon` values `48h`/`7d` or explain how to look up valid zones. The `list_zones sibling partially compensates.
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 a probabilistic price forecast for future prices and introduces the P50/P10/P90 distinction, which separates it from price and real-time price siblings. It does not use an explicit verb phrase like 'retrieves' or 'gets', but the name get_forecast together with the description makes the resource 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?
Usage is implied: an agent should select this when it needs a forward-looking probabilistic price forecast rather than current or historical prices. However, the description does not explicitly say when to prefer it over get_prices or get_realtime_prices, nor does it frame any exclusion; the main operational note is about key scoping, not tool selection.
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.