mcpbeat Sign in

entsoe-mcp MCP Server

by entsoemcp Your server? Claim it
answering

entsoe-mcp is answering right now. Last checked 7 min ago. It exposes 14 tools.

European power-market data: day-ahead & balancing prices, load, generation, flows, outages. 47 zones

Uptime history 21 days of history · worst day 99%
21 days agonow
100.0%
Uptime 24h
92 of 92 checks
14
Tools
read from the server
110 ms
Response time
average over 24h
open, no key
Access
streamable-http

What changed 3

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 3 September 2026. No other catalogue keeps this.

3 Sep 3 tool descriptions were rewritten get_day_ahead_prices, get_derivation, get_tb_spread

Nothing serious here today

Today is the operative word: we check entsoe-mcp every 15 minutes and re-read its code on every release. Watch it and you find out the day that stops being true.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 7 min ago.

run in your terminal
claude mcp add entsoe-mcp --transport http https://entsoemcp.com/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "entsoe-mcp": {
      "url": "https://entsoemcp.com/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.entsoe-mcp]
url = "https://entsoemcp.com/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "entsoe-mcp": {
      "url": "https://entsoemcp.com/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "entsoe-mcp": {
      "url": "https://entsoemcp.com/mcp"
    }
  }
}

Available tools 14

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

compare
compare_zones
Compare one endpoint across multiple zones. `start`/`end` default to UTC; `start` inclusive, `end` EXCLUSIVE. `tz="local"` is rejected (zones may differ); pass an explicit IANA tz like "Europe/Berlin" if you need wall-clock alignment.
crossborder
get_crossborder_flow
Cross-border physical flow (MW) between two adjacent zones. `start`/`end` default to UTC; `start` inclusive, `end` EXCLUSIVE. `tz="local"` uses the FROM-zone's timezone; or pass an IANA name.
data
data_coverage
Show ingest coverage and lag for (endpoint × zone) — call before queries if you're not sure whether the data is landed yet.
day
get_day_ahead_prices
Day-ahead clearing price for a bidding zone, in the zone's trading currency (EUR for euro zones; the per-row `currency` column and the response `unit` say which — GB=GBP, PL/RO/BG carry local-currency eras). `start`/`end` default to UTC; `start` inclusive, `end` EXCLUSIVE. For 'all of April 2026' use start=2026-04-01, end=2026-05-01 (end=2026-04-30 silently drops the final UTC day — and 1–2 local-time hours of April for European zones in CET/CEST). The response's `period` block shows the resolved window so you can verify (a 30-day month is 720 hours). `tz`: pass "local" to interpret start/end as wall-clock in the zone's timezone, or an explicit IANA name like "Europe/Berlin". The server converts to UTC at the boundary. If you're computing a **generation-weighted** price metric — capture price, capture rate, value factor, merchant-PPA achieved price — use `get_derivation(slug="capture_price", …)` instead. It runs server-side over the full window and returns monthly rows; no row cap, no pagination.
derivation
get_derivation
Compute **capture price**, **capture rate** (a.k.a. value factor / quality factor / Marktwertfaktor), **TBx battery-arbitrage spreads**, and other generation-weighted market metrics server-side from landed Parquet. Use this instead of fetching hourly prices + hourly generation yourself and weighting them client-side — server-side aggregation has no row cap and no pagination. `slug`: a key from list_derivations() — today: `"capture_price"`, `"negative_price_hours"`, `"residual_load"`, `"res_share"`, `"emissions"`, `"tb_spread"`. `tb_spread` returns monthly (default) or annual (aggregation='annual') Top-Bottom spreads TB1/TB2/TB4/TB6 in <currency>/MW per period — the sum of daily (top-x minus bottom-x hourly prices) over SDAC market days. The only slug accepting `aggregation`, and the only one accepting multi-zone `zone` ('all', a list, or CSV). Example — annual TB2 across every European market in ONE call: get_derivation("tb_spread", "2025-01-01", "2026-01-01", zone="all", aggregation="annual") For a single day's top/bottom hour TIMESTAMPS use get_tb_spread. `capture_price` returns monthly rows per (zone, psr_type, currency) with columns: currency, capture_price_eur_per_mwh, baseload_price_eur_per_mwh, quality_factor (the capture rate = capture/baseload), total_gen_mwh, n_hours. Months are bucketed by local time using the zone's IANA timezone. CURRENCY (capture_price and tb_spread alike): the `*_eur_per_mwh` / `tb*_eur_per_mw` key names are FIXED for API stability and do NOT track the actual unit — read the row's `currency` column, which is authoritative (EUR for euro zones, GBP for GB, PLN/RON/BGN for the PL/RO/BG local-currency eras). The response echoes it top-level as `currency`; a window spanning two currencies instead sets `unit` to null with `mixed_currency: true` and a `currencies` list. A month (or period) spanning a redenomination splits into one row PER CURRENCY, each computed only from that currency's hours — so never average or sum a price column across rows with different `currency` values. Summing `total_gen_mwh` across them IS correct: the split rows partition the month's hours rather than duplicating them. `quality_factor` is a ratio and stays comparable across currencies. `emissions` returns monthly rows per (zone, psr_type) with columns: generation_mwh, n_hours, emission_factor_kg_per_mwh, emissions_t_co2. Production-based; IPCC AR5 lifecycle factors. Zero-emission rows (nuclear, wind, solar, hydro, geothermal, marine) appear with emissions_t_co2 = 0 — useful for stacked charts. Filter via `psr_types=["solar","wind_onshore","wind_offshore"]` (or raw B-codes like "B16") to get only the technologies you care about. Defaults to all psr_types that have generation data. Example — Spain solar capture price, last 12 months: get_derivation("capture_price", "2025-05-01", "2026-05-01", zone="ES", psr_types=["B16"], tz="Europe/Madrid") Example — Germany 2024 emissions by fuel: get_derivation("emissions", "2024-01-01", "2025-01-01", zone="DE_LU", tz="Europe/Berlin") Returns 12 monthly rows in one call; no pagination.
derivations
list_derivations
List computed-metric derivations available via get_derivation(). Each derivation is a metric computed on-the-fly from one or more landed endpoints (Tier-2 Parquet). Today: capture_price (monthly VWAP capture price + baseload + capture rate per technology; "capture rate" is the industry-standard name for what the JSON response calls `quality_factor`), negative_price_hours, residual_load, res_share, emissions (monthly CO2 emissions per fuel using IPCC AR5 lifecycle factors, production-based), and tb_spread (monthly or annual Top-Bottom battery-arbitrage spread TB1/TB2/TB4/TB6 per zone on SDAC market days; accepts zone='all' for every zone in one call).
endpoints
list_endpoints
List supported ENTSO-E endpoint families.
generation
get_generation
Aggregated generation (MW) per production type. `start`/`end` default to UTC; `start` inclusive, `end` EXCLUSIVE. For a full calendar month set `end` to the first day of the next month. Pass `tz="local"` or an IANA name to interpret start/end as wall-clock in that timezone. If you're computing a **generation-weighted** price metric — capture price, capture rate, value factor, merchant-PPA achieved price — use `get_derivation(slug="capture_price", …)` instead. It runs server-side over the full window and returns monthly rows; no row cap, no pagination.
load
get_load
Actual or forecast load (MW). kind = actual | forecast | both. `start`/`end` default to UTC; `start` inclusive, `end` EXCLUSIVE. For a full calendar month set `end` to the first day of the next month. Pass `tz="local"` or an IANA name to interpret start/end as wall-clock in that timezone.
outages
get_outages
Generation-unit unavailability events (UMM). `start`/`end` default to UTC; `start` inclusive, `end` EXCLUSIVE. An outage is returned if it overlaps the window. Pass `tz="local"` or an IANA name to interpret start/end as wall-clock in that timezone.
psr
list_psr_types
List production-type (psr_type) codes. Pass zone= to scope the answer. Most codes are ENTSO-E's B01..B25 and mean the same thing in every ENTSO-E zone. A few are source-native (source != "entsoe") and exist only where that source publishes — they express concepts the B-codes cannot, so they are NOT interchangeable with a similar-looking B-code. Check `source` and read `description` before comparing a code across zones. Passing zone= also returns `taxonomy_note` for zones that mix taxonomies (e.g. GB), and per-code `endpoints` showing where each code comes from. Each code carries `counts_as_generation`: when False the figure is a net flow or net storage number, not production — do not sum it into a generation total.
series
get_series
Generic time-series query for ANY registered series endpoint. One tool covers every (non-outage) endpoint in the registry, so adding a new dataset (call `list_endpoints()` to see the current 14) gets an MCP surface automatically — no new tool to learn. Argument shape adapts to the endpoint: • single-zone (day_ahead_price, actual_load, generation_per_type, …) → pass `zone="DE_LU"` • cross-zone (crossborder_flow, scheduled_exchanges, net_transfer_capacity_dayahead) → pass `from_zone="DE_LU"` AND `to_zone="FR"` • psr-dependent (generation_per_type, wind_solar_forecast, installed_generation_capacity) → optionally filter via `psr_types=["solar","wind_onshore"]` `start`/`end`: UTC by default; `start` inclusive, `end` EXCLUSIVE (for "all of April 2026" use end=2026-05-01). Pass `tz="local"` or an IANA name to interpret as wall-clock in that timezone. `aggregation`: 'raw' (default — native PT15M/PT60M per endpoint), 'hourly' (AVG over quarters → one row per hour, useful for the growing list of PT15M-stored endpoints like DE_LU day_ahead_price), 'daily', or 'monthly'. For day-ahead prices specifically the auction still clears hourly even where stored at PT15M, so AVG=any-quarter; SUM would 4× over-count. Outage-family endpoints (different schema) stay on `get_outages()`.
spread
get_tb_spread
Top-Bottom (TBx) spread — daily battery-arbitrage benchmark. TBx = sum(top X priced hours) − sum(bottom X priced hours) over the day-ahead clearing prices for `zone` on `date`. The day is the SDAC market day (23/25 hours on DST-transition days). `date` must be a bare YYYY-MM-DD — time-bearing strings are rejected. Returns both `spread` (<currency>/MW/day) and `mean_spread` (<currency>/MWh = spread/X) in the zone's trading currency — see the response `currency`/`unit` (EUR for euro zones; GB=GBP). Common X: 1, 2, 4.
zones
list_zones
List registered ENTSO-E bidding zones.

Endpoints

URLTransportStateLatencyChecked
https://entsoemcp.com/mcp streamable-http answering 142 ms 7 min ago

Alternatives to entsoe-mcp

same job, measured the same way
Dryos
by dryos

Live US power market prices, load, generation, weather and permits for AI agents.

5 tools answering
Energy Charts
by pipeworx-io

Energy-Charts (Fraunhofer ISE) MCP — European electricity generation, prices, and capacity.

41 tools answering
Voltcast
by voltcast

European day-ahead electricity prices (43 zones), accuracy-published forecasts, carbon, optimize.

7 tools answering
LowlandData EU Marketplaces
by adrienhq

GDPR-clean marketplace listings and prices from 18 European countries. No seller personal data.

answering
LowlandData EU Marketplaces
by lowlanddata

GDPR-clean marketplace listings and prices from 18 European countries. No seller personal data.

answering
Polymarket MCP
by 0xchron

Read-only Polymarket prediction market data for AI agents.

174 installs/wk local only
Helium MCP Server - News, Markets & AI
by connerlambden

Real-time news with bias scoring, live market data, and AI-powered options pricing

10 tools answering
Predict — Prediction Market Data for AI Agents
by gocreativeai-predict

Live prediction markets: Polymarket + Kalshi prices, odds, order books. Pay-per-call USDC, no key.

5 tools answering

entsoe-mcp — questions

Answers built from our own checks of this server.

What can entsoe-mcp do?
It exposes 14 tools, read directly from the server on our last check. Among them: compare_zones, data_coverage, get_crossborder_flow, get_day_ahead_prices, get_derivation, get_generation and 8 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is entsoe-mcp working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 92 of 92 checks got a reply (100.0%), average response time 110 ms. The bar chart above shows every period we have measured.
How do I connect entsoe-mcp?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does entsoe-mcp need an API key?
No. entsoe-mcp completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 14 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is entsoe-mcp?
It answers our handshake in 110 ms on average, which is faster than 82% of all working MCP servers we measure. That puts it in the quick quarter of the ecosystem. The comparison comes from our own checks across the whole registry, every 15 minutes.