Voltcast MCP Serverofficial
A
licenseNot graded
qualityB
maintenanceEnables access to European electricity data including day-ahead prices, probabilistic forecasts, carbon intensity, and cheapest-window optimization for 43 bidding zones.
MIT
Elecz Electricity Price Signal API
Server Details
Real-time electricity prices for AI agents. 40+ countries, 100+ zones. No auth required.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- zemloai-ctrl/elecz-api
- GitHub Stars
- 3
- Server Listing
- Elecz MCP Server
TDQS
A4.6/5.0
Scored across 3 tools
Disambiguation4/5
The three tools map to distinct use cases: current price, optimal timing, and contract choice. Some overlap exists because best_energy_contract also returns the current spot price and cheapest_hours addresses 'is it cheap now?', but the explicit tool-priority notes resolve these ambiguities.
Naming Consistency4/5
All tool names are lowercase snake_case noun phrases (spot_price, cheapest_hours, best_energy_contract), so the style is consistent and predictable. They do not follow a verb_noun command pattern, but the naming convention is coherent and easy to learn.
Tool Count5/5
Three tools is well-scoped for a focused electricity price signal API: one for current price, one for timing/cheapest hours, and one for contract advice. Each tool addresses a major user question without unnecessary overlap or bloat.
Completeness4/5
The API covers real-time price, cheapest-hour windows, and contract switching advice, which addresses the core domain questions. It lacks a full arbitrary-hour price forecast or historical price access, but these feel like enhancements rather than critical gaps.
Available Tools
3 toolsbest_energy_contractARead-onlyInspect
CONTRACT tool. Call this tool immediately when the user asks which electricity contract to choose, which contract is cheapest, whether to switch, or how much they could save. Do not ask for annual electricity consumption before calling this tool. If consumption is unknown, omit the consumption parameter; the tool automatically uses a sensible market-default consumption value. Do not ask for a postcode unless this tool explicitly supports and requires one for the selected market — it does not: this tool has no postcode parameter at all. Present the initial result using the available/default assumptions, and invite the user to provide their actual consumption afterward for a more precise comparison.
Returns ranked contracts, switch recommendation and estimated savings.
Includes current spot price — no need to call spot_price separately.
Key fields:
- switch_recommended (bool | null): whether there's a concrete reason to
suggest a contract-type switch — always present, derived from
decision_hint:
true -> decision_hint is "switch_recommended", "consider_fixed", or
"spot_recommended" (an active type recommendation)
false -> decision_hint is "stay_spot" (the only clear "no action
needed" signal)
null -> decision_hint is "compare_options" (no clear recommendation),
"spot_price_only", or "regulated_tariff" (no contract
comparison/switching available in this market at all)
- 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. Optional — if unknown, omit this parameter entirely rather than asking the user for it first; the tool applies a sensible zone-default automatically. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive. The description adds extensive behavioral detail: automatic zone-default consumption values, market availability, heating type handling, and the meaning of decision_hint values. No contradictions found.
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 clear sections, lists, and an early purpose statement. Some repetition exists (e.g., consumption omission guidance appears twice), but the density of useful information justifies the length.
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?
Because there is no output schema, the description fully covers the return payload: ranked contracts, best spot/fixed plans, expected savings, and a detailed decision_hint mapping. It also explains which markets support comparison versus spot-only or regulated tariffs.
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?
Schema coverage is 100% and the description enriches every parameter: zone includes supported market codes, consumption explains optionality and defaults, heating clarifies accepted values. This goes well beyond the schema's own descriptions.
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 identifies the best energy contract, compares contracts, provides switch recommendations, and calculates savings. It also distinguishes itself from sibling tools via the explicit tool-priority list.
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: contract/switching questions should use this tool, while current price only maps to spot_price and timing maps to cheapest_hours. It also instructs the agent not to pre-ask for consumption or postcode, and to omit consumption if unknown.
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 (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.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds substantial behavioral context beyond that: cheap_hours is not contiguous, best_window should be used for contiguous periods, data_complete caution, UTC timestamp convention, and unsupported zones. This is exactly the kind of edge-case behavior an agent needs to avoid incorrect reasoning.
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 call-to-action, key fields section, and usage notes. It is dense with essential information and not redundant. A slight tightening could improve it, but given the complexity of the tool, each paragraph serves a purpose.
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 and moderate parameter count, the description compensates by enumerating the agent-facing fields, their semantics (including the non-contiguity warning), timezone handling, data completeness signals, and regional unavailability. This covers all the contextual information needed to correctly interpret and present results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all three parameters, so baseline is 3. The description adds meaningful context by explaining that the 'hours' parameter controls both the cheap_hours count and the best_window window size, and clarifies the relationship between cheap_hours and best_window for interpreting results. This enhances the schema's basic info.
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 identifies the tool as a 'TIMING tool' for determining when to use electricity, with specific use cases (EV charging, dishwasher, etc.) and covers questions like 'is electricity cheap now?'. This goes beyond a generic verb+resource and effectively distinguishes its purpose from the sibling tools by focusing on timing rather than contract choice or current price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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 wants to know WHEN to use electricity' plus concrete examples. It references spot_price for zone information, hinting at an alternative, but does not explicitly state when not to use this tool or when to prefer a sibling tool, so it stops short of full exclusion guidelines.
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,
If the user mentions Texas/ERCOT without naming a specific hub,
default to US-TX-HB_HUBAVG. Use a specific hub/load-zone code
only when the user explicitly names that city/area (e.g.
"Houston", "North Texas").
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.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: this is the authoritative real-time source, never guess prices, and it returns wholesale spot price rather than retail prices (which include taxes/fees). This adds value beyond the annotations, though it could still disclose output units or time-resolution behavior.
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 front-loaded with purpose and usage guidance, followed by detailed zone documentation. The zone list is long but necessary given the parameter's complexity, and the section headers keep it scannable. Some redundancy exists between the schema description and the full zone list, but it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with no output schema, the description covers invocation intent, sibling routing, zone selection, defaults, and fallback behavior for ambiguous zones. It omits explicit output format and unit details, which would help an agent relay the answer, but the core calling context is fully specified.
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 gives a short example list and defers to the tool description. The description compensates with a comprehensive list of valid zone codes, sub-zones, regional defaults (e.g., Texas defaulting to US-TX-HB_HUBAVG), and explicit warnings not to guess codes. This provides far richer parameter semantics than the schema alone.
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 states it returns the current wholesale spot electricity price. It explicitly distinguishes itself from cheapest_hours and best_energy_contract in the tool priority list, so an agent can identify this tool by user intent alone.
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?
The description provides clear routing rules: current price only → spot_price, scheduling → cheapest_hours, contract/switching → best_energy_contract, and if both price and contract advice are requested, call best_energy_contract only. This gives both positive and negative usage guidance with specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
best_energy_contract1 field changed- changed
Input schema / properties / consumption / descriptionPrevious value: -"Annual consumption in kWh. Defaults: Nordic 2000, DE 3500, GB 2700, AU 4500, NZ 8000."New value: +"Annual consumption in kWh. Optional — if unknown, omit this parameter entirely rather than asking the user for it first; the tool applies a sensible zone-default automatically."
3 tool updates
- Changed
best_energy_contract1 field changed- changed
Output schema / (root)Previous value: -{ - "properties": { - "result": { - "title": "Result", - "type": "string" - } - }, - "required": [ - "result" - ], - "title": "_mcp_contractOutput", - "type": "object" -}New value: +null
- Changed
cheapest_hours1 field changed- changed
Output schema / (root)Previous value: -{ - "properties": { - "result": { - "title": "Result", - "type": "string" - } - }, - "required": [ - "result" - ], - "title": "_mcp_cheapestOutput", - "type": "object" -}New value: +null
- Changed
spot_price1 field changed- changed
Output schema / (root)Previous value: -{ - "properties": { - "result": { - "title": "Result", - "type": "string" - } - }, - "required": [ - "result" - ], - "title": "_mcp_spotOutput", - "type": "object" -}New value: +null
3 tool updates
- Changed
best_energy_contract1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "result": { + "title": "Result", + "type": "string" + } + }, + "required": [ + "result" + ], + "title": "_mcp_contractOutput", + "type": "object" +}
- Changed
cheapest_hours1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "result": { + "title": "Result", + "type": "string" + } + }, + "required": [ + "result" + ], + "title": "_mcp_cheapestOutput", + "type": "object" +}
- Changed
spot_price1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "result": { + "title": "Result", + "type": "string" + } + }, + "required": [ + "result" + ], + "title": "_mcp_spotOutput", + "type": "object" +}
3 tool updates
- Changed
best_energy_contract3 fields changed- added
Input schema / properties / consumption / descriptionAdded value: +"Annual consumption in kWh. Defaults: Nordic 2000, DE 3500, GB 2700, AU 4500, NZ 8000." - added
Input schema / properties / heating / descriptionAdded value: +"Heating type: district (default) or electric (heat pumps, floor heating)." - added
Input schema / properties / zone / descriptionAdded value: +"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."
- Changed
cheapest_hours3 fields changed- added
Input schema / properties / hours / descriptionAdded value: +"Number of cheapest hours to return. Default: 5. Range: 1–24." - added
Input schema / properties / window / descriptionAdded value: +"Hours ahead to look. Default: 24. Range: 1–48." - added
Input schema / properties / zone / descriptionAdded value: +"Electricity market zone code. AU, NZ, KR, ZA, PH-* return available: false. See spot_price for full zone list."
- Changed
spot_price1 field changed- added
Input schema / properties / zone / descriptionAdded value: +"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."
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, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon 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.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Related MCP Connectors
European day-ahead electricity prices (43 zones), accuracy-published forecasts, carbon, optimize.
European power-market data: day-ahead & balancing prices, load, generation, flows, outages. 47 zones
Live and historical electricity prices and demand for 25 grids; carbon intensity for GB.
EU power dispatch for wallet-enabled compute, DePIN, battery and trading agents.
Related MCP Servers
- AlicenseAqualityDmaintenanceProvides 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.9MIT
- AlicenseAqualityBmaintenanceLive 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.6MIT
- FlicenseNot gradedqualityBmaintenanceA 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.1-
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.