Elecz Electricity Price Signal

best_energy_contract

Read-only

CONTRACT tool. Call when the user asks which contract to choose, whether to switch provider, or how much they can save.

Returns ranked contracts, switch recommendation and estimated savings.
Includes current spot price — no need to call spot_price separately.

Key fields:
- switch_recommended (bool)
- best_spot / best_fixed
- action.expected_savings_local_year
- decision_hint: yksi seuraavista —
    "spot_recommended"    matala kulutus, spot on halvin pitkällä aikavälillä
    "consider_fixed"      korkea kulutus + koholla oleva spot, fixed antaa varmuutta
    "stay_spot"           spot-hinta juuri nyt matala, kannattaa pysyä spotissa
    "compare_options"     ei selkeää suositusta, vertaile itse
    "switch_recommended"  laskettu säästö > 50 EUR/v vaihtamalla
    "spot_price_only"     ei sopimusvertailua (KR/JP/MX/US-zonet) — vain hinta näytetään
    "regulated_tariff"    säädelty tariffi (ZA/PH), ei vaihtomahdollisuutta

Contract comparison available in: FI, SE, NO, DK, DE, GB, AU, NZ.
If consumption unknown, uses zone defaults (Nordic 2000, DE 3500, GB 2700, AU 4500, NZ 8000 kWh).
Set heating="electric" for heat pumps/floor heating.

Tool priority:
- Current price only → spot_price
- Timing → cheapest_hours
- Contract/switching → best_energy_contract (this tool)

Args:
    zone: Contract comparison: FI, SE, NO, DK, DE, GB, AU-NSW/VIC/QLD/SA/TAS, NZ-NI/SI.
          Spot price only for all other zones.
    consumption: Annual electricity consumption in kWh.
    heating: "district" or "electric" (default: district).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`zone`	No	Market zone for contract comparison. Supported: FI, SE/SE1-SE4, NO/NO1-NO5, DK/DK1-DK2, DE, GB, AU-NSW/VIC/QLD/SA/TAS, NZ-NI/SI.	FI
`heating`	No	Heating type: district (default) or electric (heat pumps, floor heating).	district
`consumption`	No	Annual consumption in kWh. Defaults: Nordic 2000, DE 3500, GB 2700, AU 4500, NZ 8000.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already indicate read-only and non-destructive, but the description adds substantial behavioral context: it embeds spot price, includes decision_hint explanations, lists zone availability, and notes special cases (spot_price_only, regulated_tariff). This exceeds the annotation baseline.

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 headers and bullet points. It front-loads the core purpose and prioritizes critical info. Minor redundancy (tool priority section repeats some earlier guidance) prevents a perfect score.

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?

No output schema exists, so the description fully bears the burden of explaining return values. It covers key fields, decision_hint meanings, zone-wide availability, defaults, heating options, and tool priority, making it complete for a complex tool.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description restates parameter meanings and defaults with minimal new information (e.g., heating='electric' for heat pumps, zone defaults for consumption). It adds no significant semantics beyond the schema.

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 clearly states the tool selects contracts, provides switch recommendations, and estimates savings. It explicitly distinguishes from siblings by specifying tool priority: current price → spot_price, timing → cheapest_hours, contract/switching → this tool.

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 ('Call when the user asks which contract to choose, whether to switch provider, or how much they can save') and names alternatives with clear exclusions. Also details zone-specific behavior and consumption defaults.

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?