entsoe-mcp

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

No annotations are present, so the description shoulders the behavioral disclosure. It clearly explains the start/end boundary behavior and the `tz="local"` rejection with an acceptable alternative, but it does not disclose whether the operation is read-only, how zone validity is handled, or what happens on missing data. This is useful but partial.

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 three short sentences with no filler. The core purpose comes first, and the time semantics are formatted as scannable rule lines. Every sentence earns its place.

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 description nails the non-obvious time behavior, and an output schema exists so return-value structure does not need to be explained. On the other hand, the `aggregation` parameter has no explanation beyond its default, and there is no guidance on how missing zones or invalid endpoints will be reported. For a six-parameter tool with no annotations, this is decent but not 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?

The schema has 0% coverage, and the description adds real meaning for `start`, `end`, and `tz`, clarifying UTC defaults, inclusivity, and the IANA requirement. However, `endpoint`, `zones`, and especially `aggregation` (only shown with `default: "daily"` in the schema) remain undocumented, so the compensation is incomplete.

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 opens with 'Compare one endpoint across multiple zones,' which clearly identifies the verb, resource, and scope. It is distinguishable from siblings like get_series and list_zones, though it does not explicitly name an alternative.

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 gives explicit time-window semantics (UTC default, inclusive start, exclusive end) and concrete guidance for the tz parameter, including a rejection case and workaround. It does not explicitly state when to choose this tool over siblings such as get_series or get_generation, so usage context is mostly implied.

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

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

With no annotations provided, the description must disclose behavior. It clearly states this is a read-only diagnostic tool (showing coverage/lag) and hints at its role in checking data readiness. It doesn't disclose potential issues like rate limits or whether it only returns data for zones/endpoints with activity, but the core behavior is transparent.

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 a single, efficient sentence that packs a lot of information: what it shows, the granularity, and when to use it. No wasted words.

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?

For a diagnostic read-only tool with 2 optional parameters and no output schema, the description is fairly complete. It tells the agent what the tool does and when to call it. The gap is that it doesn't describe the return format or what specific coverage/lag metrics are included, but this is somewhat mitigated by the tool's apparent simplicity.

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 should compensate for the two parameters (zone and endpoint). The description mentions both 'endpoint × zone' in the context of what is shown, which implicitly defines what the parameters filter by. However, it doesn't explain how the parameters interact (e.g., are both required? what happens if one is null?), leaving some gaps in parameter semantics.

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 states a specific verb ('Show'), a concrete resource ('ingest coverage and lag'), and a clear granularity ('endpoint × zone'). It doesn't explicitly differentiate from sibling tools, but it provides enough specificity about what is shown to make the tool's purpose clear.

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 gives an explicit usage directive: 'call before queries if you're not sure whether the data is landed yet.' This is clear, actionable guidance on when to use the tool, effectively setting expectations for its purpose.

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

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.

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

With no annotations, the description carries the full burden of behavioral disclosure, and it does so well: it explains UTC defaults, inclusive/exclusive boundaries, timezone interpretation, currency semantics, and the resolved-window verification block. The only notable gap is that it does not explain the aggregation parameter's behavior or valid values, but overall it is transparent about edge cases.

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 long but information-dense and well-structured. It front-loads the core purpose, then covers temporal semantics, timezone behavior, and an alternative tool without redundancy. Every sentence adds practical value for invoking the tool correctly.

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?

Given that an output schema exists and sibling tools like list_zones and data_coverage are available, the description is largely complete: required params are documented, edge cases are covered, and the alternative tool is named. The only real completeness gap is the undocumented aggregation parameter, which prevents full self-sufficiency.

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, and it does for start, end, tz, and zone by adding semantics like UTC interpretation, inclusive/exclusive behavior, timezone conversion, and a concrete date example. However, the aggregation parameter is not described at all, despite having a non-obvious default of 'raw'. This is a clear compensating gap.

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 opens with a specific verb and resource: retrieving the day-ahead clearing price for a bidding zone in the zone's trading currency. It clearly distinguishes this from related tools and even names the closest alternative, get_derivation, for generation-weighted metrics. There is no ambiguity about what this tool returns.

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 gives explicit when-to-use guidance with concrete examples for time ranges and inclusive/exclusive boundaries. It also explicitly tells the agent when NOT to use this tool: for generation-weighted metrics, use get_derivation instead, and explains why that alternative is better suited. This is model routing guidance.

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

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

With no annotations, the description carries the full burden, and it does so thoroughly: no row cap, no pagination, currency column being authoritative despite fixed key names, mixed-currency behavior, row splitting per currency, correct vs incorrect aggregation across rows, and zero-emission row behavior. These are material behavioral traits an agent cannot infer from the schema.

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 long and information-dense, with a strong front-loaded purpose and well-placed examples. It is mostly efficient, but it repeats 'no pagination' near the end and some sections could be tightened; the length is largely justified by the multi-slug complexity.

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?

This is a complex tool with nine parameters, multiple slug-specific behaviors, and no annotations, and the description covers output shapes, currency edge cases, filtering, timezone bucketing, and examples well. The notable gap is from_zone/to_zone, which are completely undocumented; with an output schema present, return-value details are not a missing piece, but parameter coverage is incomplete.

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 coverage is 0%, so the description must explain parameters, and it does for slug, aggregation, zone, psr_types, tz, start, and end with examples and constraints. However, from_zone and to_zone are never mentioned anywhere, leaving two of nine parameters unexplained despite the description's otherwise heavy compensation.

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 verb ('Compute') and resource ('generation-weighted market metrics server-side from landed Parquet') and enumerates the distinct slugs. It explicitly distinguishes itself from fetching hourly prices/generation client-side and from get_tb_spread, so an agent can tell exactly which tool to choose.

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 explicitly says 'Use this instead of fetching hourly prices + hourly generation yourself' and justifies it with 'no row cap and no pagination.' It also tells the agent to use get_tb_spread when only single-day top/bottom timestamps are needed, which is clear when-to-use vs alternative guidance.

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

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.

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.

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.

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.

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.

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.

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 transparently explains timezone defaults, inclusive/exclusive boundaries, and how to get a full calendar month by setting end to the first day of the next month. It does not mention any potential side effects, rate limits, or data-availability caveats, but the tool appears to be a read-only query, and the time semantics are a meaningful behavioral disclosure.

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-organized. It front-loads the core purpose in the first sentence, then moves to time-window semantics and timezone handling in clear, line-broken steps. Every sentence adds necessary information without fluff.

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 description covers the most complex and error-prone details (time boundaries and timezones) well, and the presence of an output schema removes the need to explain return values. Still, it leaves required parameters like zone completely unexplained and does not hint at valid aggregation values or point to sibling tools such as list_zones for zone identifiers. This makes the description incomplete for a first-time agent.

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 explain parameters. It adds valuable semantics for kind (actual | forecast | both), start/end (default UTC, inclusive/exclusive, month example), and tz (local or IANA). However, it provides no explanation for the required zone parameter or the aggregation parameter, which are left entirely to the schema's bare type definitions.

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 states that the tool returns actual or forecast load in MW, which is a specific resource and metric. It distinguishes the tool's subject (load) from siblings like get_generation, though it never explicitly names alternatives.

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 provides clear, concrete usage context for time parameters: start/end default to UTC, start is inclusive, end is exclusive, and tz can be passed to interpret times in a local timezone. It does not, however, provide any explicit guidance on when to choose this tool over sibling tools, so no exclusions or alternatives are stated.

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

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.

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

With no annotations provided, the description carries the full burden and delivers extensively: UTC default, start-inclusive/end-exclusive semantics, tz interpretation, aggregation transformations, and the concrete warning that SUM would 4x over-count PT15M-stored day-ahead prices. This goes well beyond what the input schema alone could communicate.

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 long but every section earns its place by explaining a parameter family, boundary condition, or exclusion. Bullet grouping and the day-ahead over-count caveat make it scannable and information-dense without redundancy.

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?

For a 9-parameter generic query with no annotations and no schema descriptions, the description is complete enough for correct invocation: it explains required time arguments, endpoint-dependent zone arguments, optional psr filters, aggregation modes, and the outage-family exception. An output schema exists, so return-value details do not need to be repeated in the description.

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%, but the description compensates fully: endpoint, zone, from_zone/to_zone, psr_types, tz, start/end, and aggregation are all explained with examples and behavioral nuance. It even clarifies which parameter shapes apply to which endpoint families.

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 opens with 'Generic time-series query for ANY registered series endpoint', naming a concrete verb, resource, and scope. It differentiates itself from sibling tools by framing itself as the registry-wide generic query, and explicitly separates outage-family endpoints by routing them to get_outages().

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?

It gives clear guidance: use for non-outage series endpoints, call list_endpoints() to discover the registered sets, and pass endpoint-specific zone/psr argument shapes. It explicitly says outage endpoints belong on get_outages(). However, it does not mention the specialized get_* sibling tools or state when an agent should prefer them over this generic tool, so alternative routing is not fully explicit.

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

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

With no annotations provided, the description carries the full burden and does a solid job: it explains the formula, DST-related 23/25-hour market days, strict date format requirements, and the returned metrics with currency/unit behavior. It does not cover error cases or data availability, but the disclosed operational details go well beyond what structured annotations would have supplied.

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 information-dense with no filler: formula, market-day nuance, date constraint, return semantics, and example X values are all packed efficiently. The most essential identifying phrase is front-loaded, and every sentence contributes operational value.

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?

For a 3-parameter tool with an output schema present, the description covers the critical invocation details: parameter semantics, date formatting, formula, units, and currency fields. Minor gaps remain around allowable `x` range and zone identifier sources, but the description is otherwise sufficient for correct selection and invocation.

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, and it largely does. It clarifies that `date` must be bare YYYY-MM-DD and explains `x` through the formula and common values (1, 2, 4). `zone` is referenced as the market zone and tied to currency behavior, though a more explicit pointer to list_zones would have made it even stronger.

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 metric (Top-Bottom spread), defines it with an explicit formula, and ties it to a clear resource (day-ahead prices for a zone/date) and use case (battery-arbitrage benchmark). It is distinguishable from sibling tools like get_day_ahead_prices because it computes a derived benchmark rather than returning raw prices.

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 when the tool is useful via 'daily battery-arbitrage benchmark' and explicitly frames the computation over day-ahead clearing prices. However, it does not state when to prefer this over related tools like get_day_ahead_prices or compare_zones, nor does it give any exclusion criteria. Usage context is present but relies on inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that derivations are computed on-the-fly from Tier-2 Parquet, defines each derivation, notes the capture_rate/quality_factor alias, and mentions the zone='all' behavior for tb_spread. This is valuable behavioral context beyond the empty schema.

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 dense but front-loaded with the purpose. Every clause provides useful detail about a derivation, though the long run-on listing could have been more scannable as bullet points.

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?

For a parameterless list tool with an output schema, this is complete. It names the purpose, enumerates all currently available derivations, and explains key domain-specific semantics such as aliases and zone='all' behavior. The output schema covers return values, so no return-format description is needed.

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?

This tool has zero parameters and an empty schema with 100% coverage, so there is no parameter meaning to add. The description correctly frames it as a no-argument listing operation.

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 opens with a specific verb and resource: 'List computed-metric derivations available via get_derivation().' It then enumerates the exact derivations, which clearly differentiates it from sibling list tools like list_endpoints or list_zones and from the compute-oriented get_derivation tool.

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 phrasing 'available via get_derivation()' signals that this tool is the discovery entry point while get_derivation performs the actual computation. It gives clear contextual guidance but does not explicitly state when not to use alternatives.

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

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

With no annotations, the description carries the burden of behavioral transparency. 'List' and 'supported' clearly imply a non-destructive read-only enumeration. However, it does not explain output scope, whether family filters results, or auth/rate-limit context; this is acceptable for a simple catalog but not info-rmative.

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?

One short, front-loaded sentence with no filler or repetition. Every word contributes meaning.

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?

Although the tool is simple and has an output schema, the description omits the meaning and usage of the only optional parameter. It also provides no usage guidance against sibling tools, so an agent cannot confidently decide when to pass a family value.

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?

The only parameter 'family' has 0% schema description coverage, and the description does not explain how it affects results or what valid values look like. The phrase 'endpoint families' provides a weak semantic anchor but does not compensate for the missing documentation.

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 states a clear verb ('List'), a clear resource ('ENTSO-E endpoint families'), and a scope ('supported'). This differentiates it from sibling list_* tools such as list_derivs and list_zones, which operate on different resource types.

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?

No guidance is given about when to use this tool versus sibling list tools or get_* data tools. It does not explain when the optional family parameter is useful, nor any alternatives or exclusions.

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

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

With no annotations, the description carries the full burden and does so excellently. It discloses that source-native codes are NOT interchangeable with similar-looking B-codes, explains that counts_as_generation=False means net flow or net storage rather than production, and documents zone-specific taxonomy_note and endpoints fields. This goes well beyond a bare 'list' statement.

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 front-loaded with the core action, and every subsequent sentence adds a distinct behavioral or semantic fact. It is compact relative to the information density and contains no 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?

For a tool with one optional parameter and an output schema, the description is complete: it explains the parameter's effect, important data semantics, cross-zone comparison caveats, and special fields returned for certain zones. Nothing essential seems missing for an agent to call it correctly.

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 coverage is 0%, so the description must explain the zone parameter, and it does. It states that zone scopes the answer and enumerates what zone= additionally returns (taxonomy_note, per-code endpoints). This gives the agent meaningful semantic understanding of the only parameter.

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 opens with an explicit verb and resource: 'List production-type (psr_type) codes.' It distinguishes this from sibling list tools by naming the specific resource type and the optional zone scoping behavior, so an agent knows exactly what this tool returns.

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 gives clear usage context: pass zone= to scope the answer, and warns to check source and description before comparing codes across zones. It does not explicitly name alternatives or when-not-to-use scenarios, but the context is clear enough for selecting this tool.

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

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

With no annotations, the description must disclose behavioral details. It states a read-only list operation, but fails to mention that active_only defaults to true and cluster being null likely means all clusters, both of which materially affect results.

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?

Single sentence, clear verb-first structure, no filler. It is concise, though slightly under-specified for the two parameters.

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 structure, but the description omits parameter semantics and default filtering behavior. For an operation with two optional parameters and no annotations, this is insufficient for confident invocation.

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% and the description does not explain either parameter. cluster is ambiguous and active_only's effect is left to inference, so the description adds no meaning beyond parameter names and types.

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?

Description uses a specific verb ('List') and resource ('registered ENTSO-E bidding zones'), making the tool's function unmistakable. It also distinguishes itself from sibling list tools like list_derivations and list_psr_types by naming the exact resource type.

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 action is implied: use this when you need the set of bidding zones. However, there is no explicit guidance about when not to use it or how it compares to sibling tools such as compare_zones or data_coverage.

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