voltcast

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

With no annotations provided, the description carries full burden for behavioral transparency. It fails to disclose whether the tool is read-only, what happens if no window is found, authentication requirements (though 'Pro+' hints at tiers), rate limits, or side effects. The description only hints at the data source but lacks depth.

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, well-structured sentence that conveys the core idea without redundancy. It is front-loaded with the primary action. However, it could be slightly more informative without sacrificing conciseness, e.g., by mentioning the output (returned windows) or input constraints.

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 has 5 parameters, no output schema, and no annotations, the description is insufficient for an agent to fully understand usage. The description does not explain return format, edge cases, or how to interpret the results. The agent lacks context for error handling or expected output structure.

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 has only 40% parameter description coverage (count and duration_minutes have descriptions; to, from, zone do not). The tool description adds no additional parameter details, leaving the undocumented 'to', 'from', and 'zone' parameters ambiguous. While 'zone' might be inferred from the context of geographic zones, the description does not clarify date range parameters or how 'count' interacts with the search algorithm.

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's purpose: 'Find the cheapest contiguous time window(s) to run a load, over published prices + forecast (Pro+).' It specifies a verb (find), resource (cheapest contiguous time windows), and context (prices, forecast, Pro+ tier). It effectively distinguishes itself from sibling tools like get_prices (which only retrieves raw prices) and get_forecast (which only retrieves forecasts).

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 lacks any guidance on when to use this tool versus alternatives. It does not mention preconditions (e.g., need for Pro+ tier), exclusion criteria (e.g., when raw price data is needed), or conditions where the tool might not be appropriate. No explicit when-to-use or when-not-to-use hints are provided.

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.