entsoe-mcp

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.

Input Schema

TableJSON Schema

Name	Required	Default
`tz`	No
`end`	Yes
`zone`	Yes
`start`	Yes
`psr_types`	No
`aggregation`	No	raw

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral disclosure burden. It usefully reveals UTC default behavior, inclusivity/exclusivity, and timezone interpretation. However, it does not disclose pagination, row caps, rate limits, or what happens for large windows, and only implies such differences for get_derivation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and every sentence earns its place: a one-line summary, precise temporal semantics, timezone guidance, and a routing note to the relevant alternative. It is front-loaded and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return shape, so that omission is acceptable. The description covers the critical time semantics and the main sibling tool alternative, but leaves aggregation parameter values, psr_types handling, and endpoint pagination/cap behavior implicit. For a 6-parameter tool with no annotations, this is adequate but not complete.

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 description coverage is 0%, so the description must compensate. It adds real meaning for start, end, and tz, and 'per production type' hints at psr_types. However, zone is not explained, and aggregation values beyond the default 'raw' are never specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource as aggregated generation in MW per production type, which makes the tool's output clear and distinct from raw load or price endpoints. It lacks an imperative verb like 'Retrieve', but the meaning is unambiguous and not a tautology.

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?

The description gives concrete usage guidance: start is inclusive, end is exclusive, timezone handling is explained, and it explicitly routes users away from this tool toward get_derivation for generation-weighted price metrics. It does not broadly compare against get_load or get_series, but the key alternative is clearly named.

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

All entsoe-mcp tools Inspect

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

A3.9/5.0

Disambiguation3/5

Several dedicated getters (get_day_ahead_prices, get_generation, get_load, get_crossborder_flow) overlap with the generic get_series, which explicitly covers the same endpoint families, creating some choice ambiguity. However, the tool names and cross-references like get_derivation vs get_tb_spread and compare_zones vs get_series help an agent distinguish the specific purpose of each tool. Overall there is real overlap, but the descriptions mostly steer an agent correctly.

Naming Consistency5/5

Tool names are lowercase snake_case and consistently follow verb-first patterns: get_ for data retrieval, list_ for reference/discovery, and compare_/data_ for cross-cutting utilities. No mixed casing or erratic verb styles appear. data_coverage is a minor pattern deviation but still reads naturally alongside the other names.

Tool Count5/5

Fourteen tools is well within the appropriate range for an ENTSO-E data platform: several list_ discovery tools, specialized getters, a generic get_series to prevent endpoint-specific tool explosion, plus data_coverage and compare_zones. The count feels comprehensive without being bloated, and the generic query tool keeps the surface scalable.

Completeness5/5

The tool surface covers the core read-only ENTSO-E workflows: endpoint discovery, zone/psr_type reference data, raw time-series via get_series, outages, cross-border flows, load, generation, prices, and server-side derivations. It also adds operational safeguards like data_coverage and analytical shortcuts like compare_zones and get_derivation. There are no obvious dead ends or missing lifecycle stages for the stated domain.

Resources

Need Help?