entsoe-mcp

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 (€/MW/day) and mean_spread (€/MWh = spread/X). Common X: 1, 2, 4.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`x`	No
`date`	Yes
`zone`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly discloses the SDAC market-day length (23/25 hours on DST-transition days), the strict bare-YYYY-MM-DD date requirement with rejection of time-bearing strings, and the two output metrics with units. This goes well beyond a bare definition, though auth and failure behavior are not covered.

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 well structured: the core definition and formula come first, then market-day nuance, then input format, then outputs. Every sentence earns its place with no filler or repetition.

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?

The description covers the essential operational context: formula, DST effects, date parsing strictness, return fields, and typical X values. It does not explain how to find valid `zone` identifiers, but the sibling list_zones partially covers that. Overall, this is a well-rounded definition for a calculation tool.

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 description coverage is 0%, so the description must add meaning to parameters. It does clarify `date` format and validation, ties `x` to the number of top/bottom priced hours, and gives common X values. `zone` is only used in the formula with no format detail, but the added semantics for the other parameters are substantial.

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 'Top-Bottom (TBx) spread — daily battery-arbitrage benchmark' and immediately gives the exact formula TBx = sum(top X priced hours) − sum(bottom X priced hours). This clearly states the verb/resource and the computed metric, and it is easily distinguishable from raw-price siblings like get_day_ahead_prices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use case is implied through 'daily battery-arbitrage benchmark' and the mention of common X values, but there is no explicit guidance on when to choose this tool versus get_day_ahead_prices or other derivation tools. An agent can infer the use case, but the description does not state when not to use it.

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?