Elecz Electricity Price Signal API
Server Details
Real-time electricity prices for AI agents. 40+ countries, 100+ zones. No auth required.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- zemloai-ctrl/elecz-api
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Tool Definition Quality
Average 4.6/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: best_energy_contract for contract recommendations, cheapest_hours for identifying low-price time slots, and spot_price for current pricing. There is no overlap in functionality, and the descriptions explicitly differentiate their use cases.
All tool names follow a consistent snake_case pattern with descriptive, action-oriented terms (best, cheapest, spot). The naming is uniform and predictable across the set.
Three tools is reasonable for an energy signal server, covering key user queries about contracts, pricing, and timing. It feels slightly thin but well-scoped, as each tool addresses a distinct aspect of energy decision-making without unnecessary redundancy.
The tools cover core energy information needs: contract selection, price timing, and current rates. Minor gaps exist, such as historical price analysis or broader energy usage insights, but the set supports essential workflows without dead ends.
Available Tools
3 toolsbest_energy_contractARead-onlyInspect
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 ("spot_recommended" / "fixed_recommended")
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).
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | FI | |
| heating | No | district | |
| consumption | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses zone-specific behavior (contract comparison only in listed zones, otherwise spot price only), default consumption values per zone, heating parameter, key return fields, and that it includes current spot price. Annotations are minimal, but the description provides comprehensive behavioral context.
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 well-structured with bold labels, bullet points, and clear sections (key fields, zone availability, defaults, tool priority). It is front-loaded with the core purpose and use cases, and every sentence adds value without redundancy.
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 no output schema, the description adequately explains return fields (switch_recommended, best_spot, best_fixed, expected savings, decision_hint). It covers zone limitations, consumption defaults, heating parameter, and tool priority, making it complete for an AI agent to use correctly.
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?
With 0% schema description coverage, the description fully explains each parameter: zone (list of contract comparison zones and fallback to spot price), consumption (annual kWh, defaults per zone), heating (district/electric). It adds default values and usage context not in the schema.
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: a contract tool for choosing contracts, switching providers, and estimating savings. It distinguishes itself from sibling tools (cheapest_hours, spot_price) by specifying when to use each.
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?
Explicit guidance on when to use this tool vs alternatives: 'Current price only → spot_price; Timing → cheapest_hours; Contract/switching → best_energy_contract.' Also notes that it includes spot price, so no need to call spot_price separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cheapest_hoursARead-onlyInspect
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
- recommendation ("run_high_consumption_tasks" / "normal_usage" / "avoid")
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 cheapest slots to return (default 5).
window: Hours to look ahead (default 24).
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | FI | |
| hours | No | ||
| window | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint. The description adds valuable context: data_complete flag meaning caution, timestamps in UTC, and unsupported zones. It does not mention rate limits or caching but is sufficient for read-only context.
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 well-structured with sections for purpose, key fields, notes, and arguments. It is somewhat long but each part adds value. It front-loads the purpose and usage context.
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?
Despite no output schema, the description lists key response fields (energy_state, recommendation, etc.), compensating for missing return documentation. It covers unsupported zones and data_complete flag. Minor omission: no explanation of best_3h_window or interpretation of recommendation.
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?
Input schema has 0% description coverage, so the description compensates well: it explains zone must use exact codes and lists unsupported zones, and mentions defaults for hours and window. However, it does not explain that 'hours' means number of cheapest slots or 'window' means look-ahead horizon.
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 it is a TIMING tool for electricity usage, with specific examples like EV charging and 'is electricity cheap now?'. However, it does not explicitly distinguish from sibling tools spot_price and best_energy_contract, relying on name and context alone.
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 explicitly says when to use it ('when the user wants to know WHEN to use electricity') and provides example queries. It lacks explicit when-not-to-use and does not mention alternative tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spot_priceARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | FI |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns wholesale spot price (retail includes taxes/fees) and is the authoritative real-time source. No contradictions, but could mention more behavioral details like 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?
Well-structured: purpose first, then tool priority, then argument details. The zone list is necessary but makes the description lengthy. Could be slightly more concise, but the structure is good.
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 simple one-parameter tool with no output schema, the description covers purpose, usage, valid parameter values, and important notes. No gaps.
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?
With 0% schema coverage, the description provides an exhaustive list of all valid zone codes with important usage notes (e.g., exact codes required, sub-zones). This fully compensates for the lack of schema documentation.
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 explicitly states it is the 'PRICE NOW tool' for current electricity price, specifies the verb 'call when the user asks for the current electricity price', and distinguishes it from siblings (cheapest_hours, best_energy_contract).
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?
Clear when-to-use guidance: use for current price only, cheapest_hours for scheduling, best_energy_contract for contract advice. Also advises to call best_energy_contract only if both price and advice are needed.
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.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!