entsoe-mcp

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

The description adds non-obvious behavioral details beyond the readOnlyHint/idempotentHint annotations: UTC defaults, start inclusive/end exclusive boundaries, and rejection of tz='local'. These are exactly the kind of edge-case behaviors an agent needs to avoid incorrect calls.

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 core sentence followed by three terse lines of boundary/timezone semantics. Every sentence adds useful information and there is no filler or 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?

Given that output schema covers return shape and annotations cover safety, the description covers the main calling gotchas around timezone handling and interval boundaries. The main missing piece is aggregation semantics, but the tool remains usable for typical calls.

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?

With 0% schema description coverage, the description partly compensates by explaining start, end, and tz semantics, and lightly defining endpoint/zones via the first sentence. However, aggregation is not described at all, and endpoint/zones are not tied to the list_endpoints/list_zones tools, leaving a partial 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 concrete verb and object: 'Compare one endpoint across multiple zones.' This clearly states the tool's action, resource, and scope, and distinguishes it from sibling tools like get_series or list_zones that are not specifically about cross-zone comparison.

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 does not say when to choose this tool over alternatives or when not to use it. The only usage-related note is the tz caveat, which is about parameter formatting rather than tool selection, so an agent gets no explicit routing guidance among the 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description does not contradict them. It adds a useful behavioral hint that this is a pre-query safety check, but it does not disclose details like how lag is measured or how missing coverage is represented.

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 focused sentence that front-loads the core behavior and immediately adds a practical usage tip. Every word earns its place; there is no redundancy or 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?

Given the rich annotations and the presence of an output schema, the description covers the essential purpose and the key when-to-use scenario. It does not enumerate valid endpoint or zone values, but the nullable filters and sibling list tools make that a minor gap rather than a blocking one.

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. The phrase '(endpoint × zone)' communicates that both parameters jointly define the scope and that they are likely optional filters, but it does not explain null/default behavior or how the parameters interact beyond the pairing.

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 action, 'Show ingest coverage and lag,' and clearly identifies the resource scope as '(endpoint × zone)'. This makes the tool's purpose distinct from sibling tools like get_series or list_endpoints.

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 states when to call the tool: 'call before queries if you're not sure whether the data is landed yet.' It provides clear context but does not mention when not to use it or name an alternative tool, so it stops short of full 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?

Annotations already declare a read-only, idempotent, non-destructive operation, so the description adds non-redundant behavioral detail: UTC default, start-inclusive/end-exclusive semantics, and tz='local' resolving to the FROM-zone timezone. This helps an agent avoid timezone misinterpretation.

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?

Three compact sentences deliver all essential semantics in a scannable format. There is no filler, repetition of schema defaults, or unnecessary detail.

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 timezone and interval semantics, which are the trickiest parts, and output/safety concerns are covered by schema and annotations. However, the aggregation parameter remains opaque, and there is no usage guidance relative to sibling tools, leaving the definition incomplete for a six-parameter API.

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?

With 0% schema description coverage, the description must compensate for parameter meaning. It explains start, end, and tz well, and from_zone/to_zone are contextually clear, but aggregation is completely undocumented with no allowed values or examples.

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 and resource: cross-border physical flow in MW between two adjacent zones. It is unambiguous and clearly distinct from sibling tools like get_generation or get_load.

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 intended use is implied by the resource definition, but the description never explicitly says when to choose this tool over alternatives or what it is not for. No exclusionary or comparative guidance is provided.

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?

Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable behavioral context: start inclusive/end exclusive, UTC default, timezone conversion, and the response's period block for verification. However, it does not disclose whether this tool has row caps or pagination (implying a gap, since get_derivation explicitly avoids them).

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 purpose and uses short, information-dense sentences. Every paragraph adds value—timezone rules, inclusive/exclusive boundaries, and the sibling tool pointer—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?

Given the tool's complexity (timezone, exclusive end, alternative routing), the description is largely complete. It covers the main pitfalls and provides an output schema (so return format need not be explained). The missing aggregation parameter explanation and absence of pagination/row-cap info are minor gaps given the rich context provided.

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?

With 0% schema description coverage, the description must compensate. It thoroughly explains start, end, and tz semantics, but does not mention the 'aggregation' parameter at all. Zone is implied by 'bidding zone.' So it covers 3 of 5 parameters well but misses one entirely.

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 the tool returns 'day-ahead clearing price for a bidding zone' with currency specifics, and distinguishes it from the sibling get_derivation for generation-weighted metrics. It names the specific resource and scope, making it easy to differentiate from other get_* tools.

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?

Explicitly says when to use an alternative: 'If you're computing a generation-weighted price metric... use get_derivation(slug="capture_price", …) instead.' Also provides detailed start/end semantics with examples and timezone handling, giving clear conditions for correct usage.

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?

Beyond the readOnly/idempotent annotations, the description discloses significant behaviors: no pagination, no row cap, mixed-currency handling with per-currency row splitting, timezone bucketing, and default psr_types behavior. It even warns against summing price columns across currencies and explains that summing total_gen_mwh across split rows is correct. This is rich, non-obvious behavioral context.

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 dense and front-loaded with the core purpose, followed by concrete examples. Each paragraph contributes unique information, though it is a continuous block without headings and could be trimmed for the less-common slugs. It is appropriately sized for the tool's 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?

capture_price, tb_spread, and emissions receive detailed documentation, but negative_price_hours, residual_load, and res_share are merely listed without explanation. Combined with the absence of to_zone/from_zone semantics, this leaves meaningful gaps for an agent trying to select or configure the right slug, despite the presence of an output schema.

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?

With 0% schema description coverage, the description compensates thoroughly for most parameters: slug values, aggregation semantics, zone multi-zone behavior, psr_types examples, tz examples, and date formatting via examples. However, to_zone and from_zone are never mentioned, leaving two parameters without any semantic guidance.

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 action—'Compute capture price, capture rate, TBx battery-arbitrage spreads, and other generation-weighted market metrics server-side from landed Parquet'—and enumerates the available slug keys. It differentiates from get_tb_spread by explicitly routing single-day timestamp requests to that sibling. An agent can confidently tell this tool apart from other data endpoints.

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 states exactly when to prefer this tool: 'Use this instead of fetching hourly prices + hourly generation yourself and weighting them client-side' and justifies with 'no row cap and no pagination.' It also points to get_tb_spread for a different use case and references list_derivations() for slug keys, giving clear routing advice.

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?

Annotations already declare read-only/idempotent/non-destructive behavior, and the description adds useful runtime behavior: default UTC interpretation, inclusive start vs exclusive end, and timezone override semantics. It does not directly state whether this endpoint paginates or caps rows, though the get_derivation contrast implies it may.

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 organized into three focused sections—definition, time-boundary semantics, and alternative routing—with no filler. Each sentence adds necessary call or selection information, and the core metric is stated first.

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, and the description covers the subtle time-window behavior and the most important alternative endpoint. The remaining gaps are the values/behavior for aggregation and psr_types, which are meaningful but partially inferable or discoverable via sibling tools like list_psr_types.

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?

With zero schema description coverage, the description compensates only partially: it explains start/end/tz in detail, but leaves psr_types and aggregation undefined in terms of accepted values or effect. zone is self-explanatory, and 'per production type' hints at psr_types, but aggregation remains ambiguous.

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 opening line names the returned metric—aggregated generation in MW per production type—and the title supplies the verb, so an agent can tell this is a generation-query endpoint. It differentiates from get_derivation for price-metric work, but it does not explicitly contrast with other generation-adjacent siblings such as get_load or get_series.

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 conditions: use a UTC or tz-interpreted window, remember end is exclusive, set end to the next month's first day for a full calendar month, and route generation-weighted price metrics to get_derivation with the capture_price slug. This is explicit when-to-use and when-not-to-use guidance with a named alternative.

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?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description supplements this with meaningful behavioral detail: `start` is inclusive while `end` is exclusive, the UTC default is stated, and timezone interpretation via `tz` is explained. It also gives a concrete calendar-month example, which goes well beyond the structured annotation data.

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, front-loaded with the core purpose, and uses clear formatting to separate the `kind` options from the time semantics. The calendar-month tip is the only extra detail, and it is practical and relevant. No sentence is wasted.

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 the output schema exists and annotations cover safety, the description explains most of what an agent needs: purpose, units, `kind` choices, time boundaries, and timezone handling. The main gap is the `aggregation` parameter, whose values and effect are never described, plus the format of `zone` is left to inference despite the `list_zones` sibling.

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 carries the burden of explaining parameters. It does explain `kind`, `start`, `end`, and `tz` clearly, including boundary and timezone semantics. However, it omits any meaning for `zone` and `aggregation`, and accepts having no enums for those fields, leaving the agent without guidance on valid aggregation values.

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 'Actual or forecast load (MW)' and immediately defines the key discriminator `kind = actual | forecast | both`. This names a specific resource (load) and a specific unit, clearly distinguishing it from sibling tools like `get_generation` or `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.

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

The description gives operational context: it explains that `kind` selects actual, forecast, or both, and explains the time window semantics. However, it never states when to prefer this tool over alternatives or when not to use it, leaving the choice to be inferred mainly from the resource name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds substantive behavioral context: default UTC interpretation, inclusive/exclusive boundaries, overlap filtering, and tz parameter behavior. It explains exactly how the time window is interpreted, which is non-obvious and valuable. No contradictions with annotations.

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, with the core purpose stated first and timezone details separated in a code block. It uses concise syntax (backticks for parameters) and avoids fluff. The structure front-loads the essential semantics, making it easy to scan. It is slightly dense but appropriately sized for the 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?

For a 6-parameter tool with 0% schema coverage, the description is incomplete. It thoroughly covers the time window behavior but omits explanations for `kind` and `min_mw`, which are not self-evident. The output schema exists, so return format is covered, and annotations cover safety. However, the missing parameter semantics leave gaps that an agent would need to infer or probe.

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 explains the semantics of start, end, and tz (inclusivity, exclusivity, overlap, timezone conversion). However, it says nothing about the `kind` parameter (default 'generation') or `min_mw` filter, leaving their meaning entirely to schema field names. The description adds value for time-related params but does not fully compensate for the 0% coverage across all 6 parameters.

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 'Generation-unit unavailability events (UMM)', clearly stating the tool returns generation outage data. The verb 'get' and resource 'outages' are specific, and the title reinforces this. It does not explicitly differentiate from siblings like get_generation or get_load, but the domain of outages is distinct enough that an agent can infer when to use it. A score of 4 reflects clarity without explicit sibling comparison.

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 detailed guidance on timezone handling and window inclusivity (start inclusive, end exclusive, overlap semantics) but offers no guidance on when to choose this tool over alternatives. It never mentions sibling tools like get_generation or get_series, nor states conditions that would favor one over the other. This is a significant gap for a tool with many siblings.

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?

The description goes well beyond the readOnlyHint/idempotentHint annotations: it explains inclusive/exclusive time ranges, UTC default, tz interpretation, aggregation semantics (AVG over quarters, SUM over-counting 4× for day-ahead prices), and per-endpoint native resolution. These are exactly the behavioral nuances an agent needs to avoid incorrect calls.

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?

Despite its length, the description is densely informative and well-structured: purpose first, then endpoint shapes as bullets, then time semantics, then aggregation rules. Bullets and short examples make the long content skimmable, and nearly every sentence adds necessary value given the schema provides nothing.

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 complex, polymorphic 9-parameter tool with zero schema-level documentation, the description is remarkably complete. It covers all parameter families, gives concrete endpoint examples, explains timezone edge cases, and warns about aggregation pitfalls. The output schema exists, so return-value documentation is unnecessary, and the pointer to list_endpoints() covers endpoint discovery.

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?

With schema description coverage at 0%, the description carries the full burden—and it delivers. Every parameter is explained with meaning and examples: endpoint shapes for zone/from_zone/to_zone, optional psr_types filtering, start/end inclusivity, tz semantics, and aggregation options plus caveats. This is exemplary compensation for an empty schema.

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 leads with a specific, unambiguous statement: 'Generic time-series query for ANY registered series endpoint.' It further clarifies scope by excluding outages and pointing to list_endpoints() for the current registry. This clearly distinguishes the tool's breadth from more specialized siblings.

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: any non-outage series endpoint, with get_outages() called out as the alternative for outage data. It also explains endpoint-shape selection (zone vs. from_zone/to_zone, psr_types). However, it does not address the dedicated sibling tools like get_load or get_day_ahead_prices, so an agent could be uncertain whether to prefer this generic tool or its specialized siblings.

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?

Annotations already declare readOnlyHint and idempotentHint, so the description's additional context is valuable rather than redundant. It discloses non-obvious behavior: time-bearing date strings are rejected, the market day can be 23/25 hours on DST-transition days, and returned units depend on the zone's trading currency. No contradiction with annotations.

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: it opens with the benchmark label and formula, then adds date constraints, return semantics, and common values. Every sentence conveys necessary information with no filler or repetition.

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 read-only derived metric with an output schema, the description is complete enough to invoke correctly without reading the schema. It explains what is computed, the day model, date validation, returned fields, units, and common parameter values. The only minor omission, exhaustive zone codes, is addressable via the sibling list_zones tool.

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 carry parameter meaning and largely does. It defines x via the formula and lists common values (1, 2, 4), explains date formatting and DST behavior, and ties zone to day-ahead clearing prices. It does not enumerate valid zone values, but the sibling list_zones covers that 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 states a specific derived metric and defines it mathematically: 'TBx = sum(top X priced hours) − sum(bottom X priced hours) over the day-ahead clearing prices for zone on date.' It also names return fields and clarifies this is a battery-arbitrage benchmark, distinguishing it from raw price or flow siblings like get_day_ahead_prices and get_crossborder_flow.

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 intended use is made explicit through the 'daily battery-arbitrage benchmark' framing and the detailed definition of what the tool computes. It also gives practical constraints such as the bare YYYY-MM-DD date format and the SDAC market-day convention. It does not name sibling alternatives or state when not to use it, but the context is clear enough to guide selection.

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?

Annotations already mark the tool as read-only, non-destructive, and idempotent abstract. The description adds behavioral context beyond that by noting derivations are 'computed on-the-fly' from Tier-2 Parquet endpoints, and by clarifying the quirk that the JSON response calls 'capture rate' by 'quality_factor'. The 'Today:' qualifier also signals the set of derivations may evolve.

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 purpose and then gives a detailed but purposeful enumeration of the available derivations. It is longer than a simple list, but each parenthetical adds meaningful semantic value, such as unit context, IPCC factors, and zone behavior. It could be restructured for readability, but no sentence is 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 parameterless catalog tool with a rich output schema And annotations, the description is complete: it names every current derivation, explains what they compute, relates them to get_derivation(), and flags naming quirks. An agent has enough context to call the tool and interpret the returned derivation names.

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 tool has zero parameterscm in its input schema, so the baseline is 4. The description does not need to explain parameters; it instead documents what derivations will appear, which is the relevant semantic content for a list operation. The passing mention of zone='all' for tb_spread is about a derivation's behavior via get_derivation(), not about this tool's parameters.

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 the specific verb 'List' and the resource 'computed-metric derivations available via get_derivation()', which is a concrete, non-tautological statement. It also distinguishes itself from sibling tools by framing its output as the catalog of derivations used by get_derivation, not as endpoints or data series.

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 makes the usage context clear: use this tool to see which computed-metric derivations exist for get_derivation(). It does not explicitly state 'use this before calling get_derivation' or contrast with list_endpoints, but the connection to get_derivation and the enumerated list strongly implies the intended workflow.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds domain scope ('ENTSO-E') and the meaning of the listing, but it does not disclose additional behavior such as pagination, response size, or filtering semantics.

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, tightly worded sentence with no filler. The primary action is front-loaded and every word contributes to the 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?

For a read-only listing tool with an output schema, a no-argument invocation is usable, but the optional 'family' parameter is not explained and there is no usage context relative to sibling tools. This leaves a material gap for an agent deciding whether and how to filter.

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 the undocumented 'family' parameter. The phrase 'endpoint families' weakly implies that 'family' relates to endpoint families, but it never explains accepted values, formatting, or filtering behavior.

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 the action ('List') and the object ('supported ENTSO-E endpoint families'), which is a specific resource. It does not fully distinguish itself from sibling list_* tools beyond the word 'endpoint', so it falls just short of a 5.

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?

There is no guidance on when to use this tool versus siblings, nor any explanation of when to supply the optional 'family' filter. The description only states what the tool does, not when or how to choose it.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral context beyond them: source-native codes are not interchangeable, counts_as_generation=false means net flow/storage not production, and passing zone= yields taxonomy_note and endpoints. This is valuable, non-obvious behavior.

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 longer than average, but every sentence earns its place: it front-loads the core purpose, then provides essential caveats about taxonomy interoperability and generation semantics. No filler or redundant restatement of the schema is present.

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 the simple single-parameter schema, the existence of an output schema, and strong safety annotations, the description covers all relevant behavior: scoping, taxonomy differences, per-zone notes, endpoints, and counts_as_generation semantics. Nothing critical is missing for an agent to call the tool 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 description coverage is 0%, so the description must compensate. It explains that zone scopes the answer and that providing it adds taxonomy_note and endpoints. However, it does not specify the expected zone value format or what happens when zone is omitted, leaving a small semantic 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 immediately states the specific verb and resource: 'List production-type (psr_type) codes.' It also clarifies the optional scope via zone and distinguishes the tool's content from siblings like list_zones and list_endpoints by describing the code-focused output.

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 clearly tells the agent when to pass zone= and warns about cross-zone comparison caveats. It does not explicitly name alternative tools or state when not to use this tool, but the usage context is strong enough for an agent to decide correctly.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the 'registered' scope, implying that the result is limited to registered zones, but it does not disclose behaviors like the active_only default or any filtering semantics. No contradiction with annotations.

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, tightly written sentence with no fluff. Every word contributes, and 'registered ENTSO-E' adds meaningful specificity beyond the title. It is appropriately concise for a simple list operation.

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?

While an output schema exists and annotations cover safety, the description and schema together fail to explain the two optional parameters. An agent cannot determine what 'cluster' should be set to or what active_only=true means. The missing parameter semantics and lack of usage guidance make the tool definition incomplete for correct 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 is silent about both parameters. The schema provides only types and defaults for 'cluster' and 'active_only', with no explanation of what values they take or what effects they have. This leaves the agent unable to correctly set or interpret these parameters.

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 action ('List') and resource ('registered ENTSO-E bidding zones'), which clearly distinguishes it from sibling tools like compare_zones or list_derivations. The addition of 'registered ENTSO-E' goes beyond the title and gives concrete scope.

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 provided on when to use this tool over alternatives. It does not mention that one might first list zones before using get_day_ahead_prices or compare_zones, nor does it give any exclusions or preferences. The agent must infer usage entirely from the tool name.

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