voltcast

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

Annotations already declare the tool read-only and non-destructive, so the description adds meaningful behavioral context beyond them: it uses current Voltcast curves, allows optional user tariff inputs, and discloses that carbon/balanced modes rely on a trailing historical production-mix profile rather than a forward forecast. The explicit 'no emissions-reduction claim' caveat is high-value transparency that prevents misuse.

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 with no filler. The core purpose and primary inputs are front-loaded, and the important methodological caveat is placed second, making the tool's limits immediately visible.

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 the tool's purpose, input mode, and key limitation clearly enough for an agent to select and invoke it confidently, especially with schema descriptions for count, tariff, objective, and duration_minutes. It does not describe the exact output structure, but the verb 'rank' plus the absence of an output schema makes the intended result reasonably inferable.

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%, so the description is not required to fully compensate for the schema, but it also does not explain the less-documented parameters like zone, to, and from. It adds some value by mentioning optional variable tariff inputs and the experimental objective modes, but it mostly mirrors schema descriptions rather than enriching them.

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 names a specific verb and resource: 'Rank household action windows by cost' using 'current Voltcast curves' and optional user-supplied tariff inputs. It also distinguishes itself from sibling tools by explicitly flagging that carbon/balanced modes are not forward carbon forecasts, which separates it from get_carbon and get_forecast.

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 gives clear usage context: use this tool to rank windows by cost or via experimental carbon/balanced modes, with optional tariff inputs. It includes an important exclusion by warning that the carbon/balanced modes are not forward carbon forecasts and support no emissions-reduction claim, though it does not explicitly name alternative sibling tools.

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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by stating the values are derived from the live generation mix, implying freshness, but it does not disclose behavior around time ranges or response limitations.

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 efficient sentence that front-loads the key output metrics and their units/scale. It contains no filler, though it does sacrifice important parameter context for brevity.

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 no output schema and zero parameter documentation, this description is incomplete. It does not explain what zone values are expected or how optional from/to affect the result, so an agent is left without enough context to invoke the tool reliably.

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 provides no meaning for the three parameters (zone, from, to) beyond their names. The units and green score range describe the output, not the inputs, leaving the required zone parameter completely unexplained.

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 resource: carbon intensity in gCO2eq/kWh and a green score on a 0-100 scale. It distinguishes itself from price- and renewables-focused siblings by describing the output as derived from the live generation mix, though it lacks an explicit verb.

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 is provided about when to use this tool versus siblings such as get_forecast or get_renewables. The description gives no context on selecting zones, time ranges, or alternatives, so an agent must infer usage entirely from the name and schema.

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?

Annotations already cover read-only and non-destructive behavior. The description adds value by disclosing the return content (P50 curve and uncertainty bands from the connected account) and pointing to an external accuracy publication. This extends the behavioral picture 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.

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

Three short sentences, front-loaded with the core purpose. The accuracy sentence adds a useful external reference and does not feel wasteful. Overall well-structured and appropriately sized.

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 no output schema, the description adequately names the return type (P50 curve, uncertainty bands) but leaves zone semantics and the full horizon options implicit. It is sufficient for a basic call but not fully complete for an agent to use without assumptions.

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 compensate. It only partially addresses the horizon parameter via 'up to 7 days ahead', leaving zone wholly unexplained and the exact enum values unmentioned. The only required parameter, zone, is completely undocumented.

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?

States a specific verb and resource: 'probabilistic price forecast'. The 'up to 7 days ahead' scope distinguishes it from real-time or historical price tools, and the mention of P50 curve and uncertainty bands further clarifies its forecasting role. Siblings like get_prices or get_realtime_prices are clearly different in 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?

Provides clear context that this tool is for forecasting, but gives no explicit guidance on when to use it versus alternatives. It does not mention exclusions or reference sibling tools, so an agent must infer when to choose forecast over real-time or other price tools.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds value by stating native currency and resolution of returned data, plus the need to connect an account. It does not contradict annotations and provides useful behavioral context.

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 core purpose is front-loaded, and the account requirement is added succinctly. Every word contributes.

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 read-only tool with four params (one required), annotations cover safety, and schema provides defaults for to/from. The description covers purpose, return characteristics, and a prerequisite. It does not mention behavior when no account is connected or invalid zone handling, but these are minor gaps given the annotations and schema.

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 coverage is 75% with descriptions for to, from, and zone; resolution lacks a description. The description does not elaborate on any parameter beyond what the schema provides, so it adds minimal semantic value. Baseline 3 is appropriate given high schema coverage.

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 states specific verb 'get' and resource 'day-ahead electricity prices', with scope per zone. It distinguishes from get_realtime_prices by specifying day-ahead and native market resolution. Clear and 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?

Implied usage via 'day-ahead' and the account requirement, but no explicit guidance on when to use this vs siblings like get_realtime_prices or get_forecast. It does not name alternatives or exclusion conditions.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the API key requirement and the 'currently WEIM' scope limitation, which are useful behavioral details not present in structured data.

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, no fluff. The first sentence states the core purpose and differentiation; the second covers the auth prerequisite. Every word 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 4-parameter tool with no output schema, the description, combined with annotations and full schema coverage, gives an agent everything needed to call the tool correctly. It could mention the response format, but 'market prices' in the name and description makes that implicit.

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 parameters are fully documented in the schema itself. The description adds no additional meaning about parameters, which 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.

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

The description clearly identifies the tool as returning real-time market prices, currently limited to WEIM, and explicitly distinguishes it from day-ahead curves. This differentiates it from sibling tools like get_prices without needing to open the schema.

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 provides clear context: this is for real-time (WEIM) prices, not day-ahead, and requires an API key. It stops short of explicitly naming sibling tools or giving a when-not-to-use rule, but the real-time vs. day-ahead contrast gives adequate guidance.

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?

Annotations already mark the tool read-only and non-destructive. The description adds valuable context beyond those annotations: account entitlement is required, and the response contents are specified (forecast sources, uncertainty bands, realized values, verification). It does not contradict the annotations, though it stops short of describing units, timezone, or granularity.

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 carry meaningful content: the first catalogs the output, and the second notes the entitlement requirement. It is compact and front-loaded, though the first sentence is somewhat dense.

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?

With no output schema present, the description does a good job of describing response contents and the access requirement. It does not state temporal resolution, units, or whether all listed components are always included, but for a simple three-parameter read-only tool these omissions are minor.

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 coverage is 100%, so zone, from, and to are already documented in the schema. The description adds no parameter-specific nuance beyond implying the day-ahead context; the baseline score of 3 applies.

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 returns day-ahead wind and solar generation forecasts and lists the included data: TSO forecast, Voltcast model with uncertainty bands, realized generation, and verification. This distinguishes it from siblings like get_prices or get_carbon, though it lacks an explicit verb and does not directly contrast with the similar-sounding get_forecast.

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 can infer to call this when renewable generation forecast data is needed. However, there is no explicit when-to-use or when-not-to-use guidance, nor any comparison with siblings such as get_forecast. The only concrete usage note is the entitlement prerequisite.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the description adds value by disclosing that no auth is required and that the scope is limited to European zones. These traits go beyond what the annotations provide and are consistent with them.

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 totaling roughly twenty words, with zero waste. The verb and subject are front-loaded, the output contents are specified in the first sentence, and the auth note in the second sentence removes a potential access barrier. Every word 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 zero-argument, read-only enumeration tool with no output schema, the description is complete: it states scope (European), return contents (codes, names, capabilities), and access requirements (none). An agent can call it safely with no further information and knows what to expect back.

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?

With zero parameters and 100% schema coverage, the baseline is 4. The description reinforces the no-filter semantics with 'all supported', and the empty input schema carries the rest of the burden. No parameter documentation is needed here.

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 verb ('List'), a specific resource ('all supported European bidding zones'), and the output contents ('codes, names, and capabilities'). It is clearly distinguishable from siblings like get_prices, get_carbon, and get_forecast, which retrieve time-series data rather than a zone reference catalog.

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 usage context is implied — this is evidently the discovery tool an agent would call first to learn valid zone codes before using price/forecast siblings — but it is never stated explicitly. There is no when-to-use guidance connecting this tool to the siblings that likely require a zone parameter, and no exclusions are given.

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