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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | ||
| end | Yes | ||
| start | Yes | ||
| to_zone | Yes | ||
| from_zone | Yes | ||
| aggregation | No | raw |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, and it adds useful semantics: start is inclusive, end is exclusive, times default to UTC, and tz='local' uses the from-zone's timezone. It does not cover behavior around aggregation or invalid/non-adjacent zone pairs, but the key temporal behaviors are explicitly disclosed.
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 compact and front-loaded with the core purpose, followed by dense, relevant timezone and inclusivity details. Every sentence earns its place with no repetition of the schema.
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?
The output schema covers return values, and the description covers the main data resource and timezone behavior, so a basic call can be made correctly. However, the optional aggregation parameter is unexplained, and there is no guidance for choosing this tool over related siblings, leaving the definition slightly incomplete for an agent encountering it cold.
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?
Schema description coverage is 0%, so the description must compensate for parameter semantics. It does clarify start/end inclusivity, UTC defaults, and tz='local' or IANA names, but it does not explain the 'aggregation' parameter beyond the schema default of 'raw', and it leaves the expected format of start/end implicit.
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 identifies the resource as cross-border physical flow in MW between two adjacent zones, which distinguishes it from zone-level tools like get_generation or get_load. It lacks an explicit verb like 'Gets' or 'Returns', but the tool name and the noun phrase together make the purpose unambiguous.
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 implies usage through 'between two adjacent zones' but does not explicitly state when to prefer this tool over alternatives or mention any sibling tools. There is no guidance on when not to use it, such as when a price spread or generation comparison is needed instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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.
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.
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.
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.