voltcast

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does this well by clearly flagging that carbon/balanced modes use a trailing historical production-mix profile, are experimental, and support no emissions-reduction claim. This prevents a likely misinterpretation of the carbon objective, adding meaningful transparency beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first front-loads the tool's purpose, and the second efficiently covers a critical caveat about the experimental modes. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose and an important behavioral caveat, but there is no output schema and the description does not explain what the returned ranked windows look like or when to choose this over sibling tools. Given the 7-parameter schema with nested objects, a bit more guidance on expected output or usage context 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?

Schema description coverage is 57%, with descriptions for count, tariff, objective, and duration_minutes. The description adds value by clarifying the objective parameter's experimental nature and 'household cost' semantics for tariff, but it does not compensate for the undocumented to, from, and zone parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: 'Rank Home+ action windows by household cost.' This clearly communicates the tool's core function and distinguishes it from sibling tools that fetch raw prices, forecasts, or carbon data, though it does not explicitly name a sibling for contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: when you need cheapest cost-ranked action windows rather than raw price/forecast data. However, it does not explicitly state when to prefer this tool over siblings like get_prices or get_forecast, nor does it mention any exclusions or prerequisites.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions the derived nature of the data but omits details like authentication, rate limits, or whether the data is cached.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no extraneous words, but it is too brief to convey necessary information. It achieves conciseness at the expense of completeness.

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 lack of output schema, annotations, and parameter coverage, the description is insufficient for an agent to use the tool correctly. It does not describe input usage or output structure beyond a high-level summary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain any parameter semantics. It fails to clarify what 'zone', 'to', or 'from' represent, leaving the agent to infer meaning from names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool's output: carbon intensity and green score from the live generation mix. While it doesn't explicitly differentiate from sibling tools like get_renewables, the resource is distinct enough that an agent can infer its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like get_renewables or get_forecast. The description lacks context about prerequisites or typical use cases.

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

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

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.

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.

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.

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

With no annotations provided, the description carries the full burden and does well by disclosing the return contents: TSO and Voltcast forecasts, q10-q90 bands, realized generation, and head-to-head verification. It goes beyond a simple 'get data' and explains the tool's comparative feature, though it omits error handling or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence that front-loads the main purpose and packs in relevant details (model name, bands, realized data, verification). The trailing 'Pro/Scale' is somewhat unstructured but does not waste significant space. It is concise given the amount of information conveyed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description explains the key return components (forecasts, bands, realized generation, comparison). It is complete enough for an agent to understand what will be received, though it lacks units or temporal resolution specifics. The sibling context is not fully addressed, but overall the description is robust.

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% for the three parameters, so the baseline is 3. The description adds no additional meaning about the zone, from, or to parameters, but the schema already provides sufficient semantic details (ISO 8601, bidding zone examples).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides day-ahead wind and solar generation forecasts, including both the TSO official forecast and Voltcast's own model, distinguished from siblings like get_prices or get_real_time_prices by its specific renewable generation focus. It names a concrete resource and deliverable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for renewable generation forecasts but does not explicitly state when to prefer this tool over siblings such as get_forecast or get_prices. No exclusions or alternative tool names are provided, leaving the selection to inference.

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

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

No annotations provided, so description carries full burden. It discloses 'No auth required' and implies it lists all supported zones, but lacks details on data freshness, rate limits, or completeness guarantees.

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?

Single sentence that is front-loaded with purpose and key details. No wasted words.

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 parameterless tool with no output schema, the description covers the essential: what it lists (zones with codes, names, capabilities) and that no auth is required. Could mention return format or pagination, but not necessary for such a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has 0 parameters with 100% schema description coverage. Baseline is 4; description adds no parameter info but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'list', the resource 'supported European bidding zones', and the output details 'codes, names, and capabilities'. It distinguishes from sibling tools which focus on prices, forecasts, etc.

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?

Explicitly states 'No auth required', indicating ease of use. Does not explicitly state when not to use or provide alternatives, but for a simple list tool, the context is clear.

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