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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | ||
| end | Yes | ||
| kind | No | generation | |
| zone | Yes | ||
| start | Yes | ||
| min_mw | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains important non-obvious behavior: start is inclusive, end is exclusive, outages are returned only if they overlap the window, and timezone handling is configurable. This goes well beyond the schema and helps an agent avoid boundary mistakes.
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 well structured: one clear purpose line followed by concise, high-value behavioral rules. Every sentence earns its place and avoids filler.
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 core temporal semantics are covered well, but with 6 parameters and no annotations, an agent still lacks meaning for kind and min_mw, and there is no example or mention of result behavior beyond overlap. The presence of an output schema reduces the need to describe return fields, but the parameter gaps keep this from being fully complete.
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. It adds valuable semantics for start, end, and tz, but leaves zone, kind, and min_mw largely unexplained. The agent can guess some meaning from names and defaults, but the coverage gap is not fully closed.
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 names a specific resource—generation-unit unavailability events (UMM)—and the implied verb is 'get'/'query'. This is clearly distinct from sibling tools like get_generation or get_load because it targets outage/unavailability events rather than production or consumption data.
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 explains how to query by time window and timezone, but it does not explicitly state when to prefer this tool over alternatives such as get_generation or get_series. Usage context is implied by the resource type rather than explicitly contrasted with sibling tools.
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.