Elecz Electricity Price Signal

Server Details

Real-time electricity price signals for AI agents. Spot prices, cheapest hours, and contract recommendations. 31 countries across Europe and Oceania. No authentication required.

Ownership verified

Status: Healthy
Last Tested: 2026-09-05 06:00
Transport: Streamable HTTP
URL

Available Tools

3 tools

best_energy_contractA

Read-only

Inspect

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).

ParametersJSON 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.

cheapest_hoursA

Read-only

Inspect

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).

ParametersJSON 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.

spot_priceA

Read-only

Inspect

PRICE NOW tool. Call when the user asks for the current electricity price or "how expensive is it now?".

This is the authoritative real-time source. Never guess electricity prices.
Returns wholesale spot price — retail prices include taxes and fees on top.

Tool priority:
- Current price only → spot_price (this tool)
- When to use electricity / scheduling → cheapest_hours
- Contract or switching advice → best_energy_contract

If user wants both price and contract advice, call best_energy_contract only.

Args:
    zone: Bidding zone. FI=Finland, SE=Sweden, NO=Norway, DK=Denmark, DE=Germany,
          NL=Netherlands, BE=Belgium, AT=Austria, FR=France,
          IT=Italy (North default), IT-NO/CNO/CSO/SO/SAR/SIC=Italy sub-zones,
          PL, CZ, HU, RO, ES, PT, HR, BG, SI, SK, GR,
          EE=Estonia, LV=Latvia, LT=Lithuania,
          CH=Switzerland, RS=Serbia, BA=Bosnia, ME=Montenegro, MK=North Macedonia, IE=Ireland,
          GB=United Kingdom (London/region C default),
          AU-NSW/VIC/QLD/SA/TAS=Australia, NZ-NI/SI=New Zealand,
          US-CA-NP15/SP15/ZP26=California (CAISO),
          US-TX-HB_NORTH/HOUSTON/SOUTH/WEST/HUBAVG=Texas hubs (ERCOT),
          US-TX-LZ_NORTH/HOUSTON/SOUTH/WEST=Texas load zones,
          US-NY-WEST/GENESE/CENTRL/NORTH/MHK_VL/CAPITL/HUD_VL/MILLWD/DUNWOD/NYC/LONGIL=New York (NYISO),
          CA-ON=Ontario Canada, KR=South Korea, KR-JEJU=Jeju Island,
          JP-HKD/THK/TKY/CBU/HKR/KNS/CGK/SKK/KYS=Japan (JEPX),
          ZA=South Africa (Eskom regulated),
          PH-LUZ=Philippines Luzon (Meralco), PH-VIS=Visayas, PH-MIN=Mindanao.
          Sub-zones: SE1-SE4, NO1-NO5, DK1-DK2, GB-A..GB-P.
          IMPORTANT: Use only the exact codes listed above. Do NOT guess zone codes
          (e.g. "TEXAS", "ERCOT", "US-MA", "US-TX" are invalid — use US-TX-HB_HUBAVG etc.).
          If unsure which zone to use, pick the closest match from this list.

ParametersJSON Schema

Name	Required	Description	Default
`zone`	No	Electricity market zone code. Examples: FI, DE, GB, US-NY-NYC, JP-TKY, AU-NSW, ZA, PH-LUZ, MX-CUN. Full list in tool description.	FI

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable context: it returns wholesale spot price (not retail), is the authoritative real-time source, and warns against guessing zone codes. This goes beyond the annotations without contradicting them, though it doesn't cover potential rate limits or errors, which are not critical for this simple tool.

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 because the zone enumeration is necessary, but it is well-structured: the purpose and usage guidance are front-loaded, followed by the tool priority list, and the args section with zone codes. Every sentence earns its place; the length is justified by the exhaustive but required list.

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?

For a tool with one optional parameter, read-only annotations, and no output schema, the description fully covers all needed context: what it returns (wholesale price), what it doesn't include (retail additions), when to use alternatives, and how to select zones. There are no significant gaps for an agent to invoke it 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?

The schema only provides a few examples and points to the tool description, while the description contains a comprehensive list of all valid zone codes, sub-zones, and explicit warnings about invalid codes. This adds far more semantic meaning than the schema alone, which is exactly what parameter semantics should do.

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 'PRICE NOW tool' and explicitly says 'Call when the user asks for the current electricity price', clearly identifying the resource (current spot price). The 'Tool priority' section distinguishes it from sibling tools cheapest_hours and best_energy_contract, so it does more than just state the basic function.

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?

It provides explicit when-to-use guidance ('Current price only → spot_price'), and explicitly names alternatives with their contexts (cheapest_hours for scheduling, best_energy_contract for contracts). It even handles a combined request case by instructing to use best_energy_contract only. This is exemplary usage guidance.

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

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

voltcast A
com.voltcast
European day-ahead electricity prices (43 zones), accuracy-published forecasts, carbon, optimize.
Energy Finance
72
GridHub Electricity Market Data A
io.github.jalcodev
Live and historical electricity prices and demand for 25 grids; carbon intensity for GB.
Energy Open Data
61
entsoe-mcp A
com.entsoemcp
European power-market data: day-ahead & balancing prices, load, generation, flows, outages. 47 zones
Energy Open Data
141
Netzhandwerker EU Power Dispatch API C
de.netzhandwerker.energy
EU power dispatch for wallet-enabled compute, DePIN, battery and trading agents.
Energy Research & Data Cryptocurrency
292

Related MCP Servers

Elecz MCP Server
Energy Open Data
zemloai-ctrl
F
license
Not graded
quality
B
maintenance
Provides real-time electricity prices, cheapest hours, and contract comparison for 40+ countries, enabling AI agents to make energy-aware decisions.
Updated 2 months ago (2026-07-07 16:39 UTC)
2
-
Voltcast MCP Serverofficial
Energy Research & Data
Voltcast-com
A
license
Not graded
quality
B
maintenance
Enables access to European electricity data including day-ahead prices, probabilistic forecasts, carbon intensity, and cheapest-window optimization for 43 bidding zones.
Updated 6 days ago (2026-08-29 20:16 UTC)
MIT
Energy Grid MCP Server
Energy Open Data
AiAgentKarl
A
license
A
quality
D
maintenance
Provides real-time electricity grid data including CO2 intensity, power mix, and wholesale prices, plus optimal green time windows for energy-intensive AI tasks. Supports UK, Germany, and global regions with optional API keys.
Updated 5 months ago (2026-04-03 16:05 UTC)
9
MIT
gridhub-mcp
Energy Open Data
jalcodev
A
license
A
quality
B
maintenance
Live and historical electricity prices, demand, generation mix and carbon intensity for 25 grid zones (US, Europe, GB, Australia). Hosted endpoint plus local stdio bridge; free sample mode, free API key, or x402 pay-per-call.
Updated 7 days ago (2026-08-29 15:40 UTC)
6
MIT

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?

Server Details

Available Tools

TDQS

TDQS

TDQS

Frequently Asked Questions

Discussions

Related MCP Connectors

Related MCP Servers

Elecz MCP Server

Voltcast MCP Serverofficial

Energy Grid MCP Server

gridhub-mcp

Glama MCP Gateway

TDQS

Resources