Elecz Electricity Price Signal

cheapest_hours

Read-only

TIMING tool. Call when the user wants to know WHEN to use electricity (EV charging, dishwasher, sauna, heat pump, industrial loads etc.). Also good for "is electricity cheap now?" questions.

Key agent fields:
- energy_state ("cheap" / "normal" / "expensive" / "negative")
- current_hour_is_cheap (bool)
- hours_until_next_cheap (0 = start now)
- cheap_window_ends, next_cheap_hour (UTC)
- best_3h_window (always the true-optimal fixed 3h/6h window)
- best_window (true-optimal CONTIGUOUS window sized to the `hours` param —
  use this, not cheap_hours, for "run this appliance for N hours straight"
  decisions; null if fewer than `hours` forecast rows are available)
- recommendation ("run_high_consumption_tasks" / "normal_usage" / "avoid")

Note: cheap_hours lists the N individually cheapest hours in the forecast
and is NOT guaranteed to be contiguous — it can include hours scattered
across the day, or (when the forecast has fewer than `hours` rows
available) can end up including comparatively expensive hours simply
because there aren't enough cheaper ones yet published. Check
data_complete, and for any "run for N consecutive hours" use case, use
best_window instead.

All timestamps are UTC — convert to local time before presenting.
data_complete: false = treat signals with caution.
Not available: AU, NZ, KR, KR-JEJU, ZA, PH-LUZ, PH-VIS, PH-MIN.

Args:
    zone: Any supported zone (see spot_price for full list).
          Use exact codes only — do not guess or abbreviate.
          AU, NZ, KR, KR-JEJU, ZA, PH-* return available: false.
    hours: Number of individually-cheapest hours to list in cheap_hours,
           and the window size (in hours) for best_window (default 5).
    window: Hours to look ahead (default 24).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`zone`	No	Electricity market zone code. AU, NZ, KR, ZA, PH-* return available: false. See spot_price for full zone list.	FI
`hours`	No	Number of cheapest hours to return. Default: 5. Range: 1–24.
`window`	No	Hours ahead to look. Default: 24. Range: 1–48.

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses subtle behaviors: cheap_hours may not be contiguous, can include expensive hours when forecast rows are few, data_complete affects trust, and all timestamps are UTC. This is substantial added behavioral context not available from structured fields.

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

Conciseness4/5

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

The description is long but well-structured with a clear 'TIMING tool' opener, labeled key fields, a note about cheap_hours behavior, and an Args list. It earns its length given the complexity, but could be slightly tightened without losing meaning.

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

Completeness5/5

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

With no output schema, the description fully explains the return fields (energy_state, current_hour_is_cheap, best_window, etc.), provides warnings about data completeness and UTC conversion, and covers unsupported zones. It gives the agent everything needed to use and interpret results correctly.

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

Parameters5/5

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

Even though schema coverage is 100%, the description adds critical semantics: hours controls both the cheap_hours list length and the best_window contiguous window size, window is the lookahead horizon, and zone must be an exact code. It also clarifies the relationship between arguments and returned fields.

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

Purpose5/5

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

The description opens with 'TIMING tool' and explicitly states when to call it ('when the user wants to know WHEN to use electricity' and 'is electricity cheap now?'). This clearly distinguishes it from sibling tools like spot_price (current price) and best_energy_contract (contract selection).

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance, including concrete use cases (EV charging, dishwasher, heat pump). It also gives exclusions and alternatives: tell the agent to use best_window instead of cheap_hours for contiguous run decisions, and warns about unsupported zones and data_complete=false.

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

All Elecz Electricity Price Signal tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0

Disambiguation5/5

Each tool serves a distinct user intent: current price (spot_price), timing/scheduling (cheapest_hours), and contract/switching advice (best_energy_contract). The descriptions explicitly cross-reference each other and include tool-priority guidance, eliminating any potential for misselection.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern and are descriptive compound nouns. While not verb_noun, the naming convention is uniform and predictable, making it easy to infer each tool's purpose.

Tool Count5/5

With 3 tools, the server is tightly scoped to its purpose: price, timing, and contracts. Each tool earns its place and there is no bloat or redundancy.

Completeness5/5

The tool set covers the core needs for an electricity price signal service: real-time price, optimal usage windows, and contract recommendations. No obvious gaps exist for the stated domain.

Resources

Need Help?