Elecz Electricity Price Signal

Ownership verified

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.

Status: Healthy
Last Tested: 2026-08-14 18:36
Transport: Streamable HTTP
URL

Glama MCP Gateway

Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.

MCP client

Glama

MCP server

Full call logging

Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.

Tool access control

Enable or disable individual tools per connector, so you decide what your agents can and cannot do.

Managed credentials

Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.

Usage analytics

See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.

100% free. Your data is private.

Tool Definition Quality

A4.8/5.0

Tool DescriptionsA

Average 4.7/5 across 3 of 3 tools scored.

Server CoherenceA

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.

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.

Tool Definition Quality

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.

Tool Definition Quality

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

Tool Definition Quality

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.

Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "maintainers": [{ "email": "your-email@example.com" }]
}

The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.

Discussions

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

Related MCP Servers

Elecz MCP Server
Energy Open Data
zemloai-ctrl
F
license
-
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 a month ago (2026-07-07 16:39 UTC)
2
Voltcast MCP Serverofficial
Energy Research & Data
Voltcast-com
A
license
-
quality
C
maintenance
Enables access to European electricity data including day-ahead prices, probabilistic forecasts, carbon intensity, and cheapest-window optimization for 43 bidding zones.
Updated a month ago (2026-07-16 22:15 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 4 months ago (2026-04-03 16:05 UTC)
9
MIT
euenergy-mcp
Energy Finance Open Data
adambenhassen
F
license
-
quality
B
maintenance
A read-only MCP server that exposes European day-ahead electricity prices for ~41 bidding zones via tools like hourly prices, cheapest hours, current price, and cross-zone summary, enabling AI agents to query energy market data.
Updated 2 months ago (2026-06-22 21:16 UTC)