Environment & energy

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: results are nearest-first, default radius 25 km, and the cost model (free within daily allowance, then $0.002 USDC per call via x402), which is material to invocation decisions.

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?

Two sentences, both earning their place: the first carries purpose, scope and defaults; the second carries the pricing model. Front-loaded with the core purpose and 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?

With an output schema present, return values need not be explained, and the description does note classification and pollution risk plus nearest-first ordering. Pricing, defaults and coverage are all present; only explicit sibling routing and parameter-format nuances are missing for a tool that is otherwise well-specified.

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 100%, so all five parameters are already documented. The description restates the default radius, matching the schema, and adds no syntax or format detail beyond it (e.g. lat/lng string format or limit interaction with radius). Baseline 3 when the schema does the heavy lifting.

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?

States a specific verb and resource ('Designated bathing waters ... within a radius of a UK postcode or point'), plus scope, default radius, ordering, and returned fields. It is clearly a spatial-proximity query, which implicitly separates it from bathing-water__search and __site, but it never names or contrasts those siblings explicitly.

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?

Usage is implied by the spatial/radius framing and the postcode-or-lat/lng hint, but there is no explicit when-to-use guidance, no statement of when to prefer bathing-water__search or __site, and no mention of prerequisites. Adequate but with clear gaps.

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 safety and idempotency are covered. The description adds pricing information (free within daily allowance, then $0.001 USDC per call via x402), which is useful behavioral context. However, it does not detail rate limits, pagination, or result ordering, and no output format is described (though an output schema exists).

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 two concise sentences, front-loading the core purpose and then adding pricing. Every sentence earns its place with no redundancy or waste.

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 search tool with an output schema and rich annotations, the description covers the essential purpose and usage context. However, it does not mention result limits, pagination, or any constraints on the search (e.g., partial name matching, district vs. site name ambiguity). Given the existence of an output schema, return values need not be explained, but some procedural context is missing.

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 100%, and the schema already documents both parameters with descriptions. The description mentions 'by name or district' and 'by classification', which maps to the parameters but adds no syntax, format, or enum details beyond the schema (which already lists classification values). Baseline 3 is appropriate when the schema carries 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 uses a specific verb ('Find') and resource ('bathing waters') and articulates two clear search modes (name/district and classification). This distinguishes it from siblings like bathing-water__near, which would be a geospatial lookup rather than a name/classification search.

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 positive usage contexts ('Find bathing waters by name or district, and/or by classification') but does not explicitly state when to use this tool versus alternatives such as bathing-water__near. The distinction is implied by the search modes, but no exclusions or alternative mentions are 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context absent from annotations: the pricing model (free within daily allowance, then $0.001 USDC per call via x402), which materially affects an agent's call strategy.

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?

Two tight sentences: the returned payload is front-loaded, then the cost note. No filler or redundancy, though it could be marginally tighter.

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?

With an output schema present, the return shape need not be described; the rich annotations carry the safety profile; and pricing is disclosed. Everything an agent needs to call this correctly is available.

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 100% and the single 'id' parameter is documented in the schema as 'Bathing water id'. The description adds nothing about id format or sourcing, so the baseline of 3 is appropriate when the schema does the work.

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?

States a specific resource ('One bathing water') and enumerates what it yields (classification+year, pollution-risk forecast, sample date, water company, profile link), so the agent knows exactly what 'site' means. It implies the by-id lookup distinction from siblings bathing-water__near/search but never names them, so it falls short of full sibling differentiation.

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?

Usage is only implied: the 'by id' framing and the single required id parameter make the lookup nature obvious. There is no explicit when-to-use guidance and no pointer to bathing-water__search for discovering an id, which would have been the natural routing instruction.

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 cover readOnly, idempotent, openWorld, and non-destructive, so the safety profile is handled. The description adds genuinely new behavioral context: the cost model (free within the daily allowance, then $0.001 USDC per call via x402), which an agent needs for budgeting and auth decisions. It omits any note on result limits or how an unbounded magnitude window affects output size.

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?

Two tight sentences, front-loaded with the operation and its scope, followed by cost. Neither sentence is filler and nothing is repeated from the schema or annotations.

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?

With an output schema present, return values need no explanation, and annotations cover the safety profile, so the description only needs to convey scope and cost, which it does. The remaining gap is behavior when minmagnitude is omitted (does it count everything?) and any cap on returned counts.

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 100% and both parameters carry descriptions, so the schema does the heavy lifting. The phrase 'time and magnitude window' confirms the two dimensions but adds no format, default, or range detail beyond the schema. Baseline 3 applies.

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?

States a specific verb (count) and resource (earthquakes) plus the filter dimensions (time and magnitude window), which cleanly separates it from siblings like earthquakes__event, earthquakes__near, and the fixed m25-day/m45-week endpoints. It stops short of naming a sibling or stating distinguishing scope (e.g. whether it counts globally or takes a location filter).

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 says what it does but never says when to use it instead of earthquakes__near, m25-day, m45-week, or significant-week. There is no guidance on required vs optional filters or on choosing a count over a listing. The only context offered is pricing, which is not usage 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds information the annotations do not carry: the cost model (free within a daily allowance, then $0.001 USDC per call via x402), which is meaningful for an agent deciding whether to invoke. It stops short of describing what 'full detail' includes or any failure behavior for invalid ids.

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?

Two short sentences with zero waste: purpose first, operational cost second. Nothing is padded or repeated from the title.

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?

An output schema exists, so return values need not be explained, and the safety profile is covered by annotations. The one real gap is that the description never tells the agent where a valid USGS event id comes from, which is the only prerequisite for calling this tool successfully.

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 100% with a single 'eventid' parameter documented as 'USGS event id'. The description restates the same fact ('by USGS event id') without adding format, syntax, or sourcing guidance, so the baseline 3 applies when the schema does the heavy lifting.

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+resource ('Full detail for one earthquake') and names the lookup key ('by USGS event id'), which cleanly separates it from the collection-oriented siblings (count, near, m25-day, significant-week). It does not explicitly name an alternative tool, so it falls short of the top tier despite being 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?

There is no guidance on when to pick this over the sibling list tools, nor any statement that a valid event id must first come from a listing endpoint (e.g. earthquakes__near or earthquakes__m25-day). The only context offered is a billing/pricing statement, which is not usage routing.

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, openWorldHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds genuinely new behavioral context the annotations do not carry: the free daily allowance and the $0.001 USDC per-call x402 pricing, which materially affects invocation strategy.

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?

Two short sentences with zero filler; the substantive scope (magnitude, worldwide, past day) is front-loaded and the cost sentence follows. 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?

An output schema exists, so return-value explanation is not required, and the annotations cover the safety profile. The description supplies scope and cost, which is sufficient for a no-parameter, read-only tool; only the lack of sibling routing keeps it from a 5.

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 takes zero parameters and schema description coverage is effectively 100%, so there is nothing for the description to clarify about inputs. Baseline 4 applies for a parameterless tool.

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 (earthquakes), a numeric threshold (magnitude 2.5+), a geographic scope (worldwide) and a time window (past day), so an agent can distinguish it from siblings like earthquakes__m45-week or earthquakes__near. It stops short of naming those siblings explicitly, which keeps it at 4 rather than 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 explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The magnitude and timeframe constraints imply a use case, but an agent choosing between this and earthquakes__m45-week, earthquakes__significant-week, or earthquakes__count gets no routing help from the description.

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 readOnly, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds genuinely useful cost behavior (free within daily allowance, then $0.001 USDC via x402), which is a rate/quota signal not present in the structured fields.

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?

Two sentences, front-loaded with the core scope and followed by the pricing note. Every clause earns its place with no 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 zero-parameter tool with an output schema and full annotation coverage, the description supplies scope plus cost context, which is enough to invoke correctly. Minor gap is the absence of explicit sibling routing, but return values and safety are otherwise covered.

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 takes zero parameters, so there is no parameter semantics to document; the baseline for a parameterless tool is 4. The 100% schema coverage and empty properties object confirm nothing is left unstated.

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?

States a precise verb-less but unambiguous resource with a clear magnitude filter (4.5+), geographic scope (worldwide), and time window (past 7 days). This cleanly distinguishes it from siblings like earthquakes__m25-day (lower threshold, 1-day window) and earthquakes__significant-week.

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 magnitude and time scope implicitly signal when this tool applies versus m25-day or significant-week, but there is no explicit when-to-use guidance, no named alternatives, and no exclusions. Usage is left to inference from the scope statement.

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 readOnly, idempotent, openWorld and non-destructive, so safety is covered; the description goes beyond that by disclosing the cost model (free within a daily allowance, then $0.002 USDC per call via x402), which is real behavioral context an agent needs before calling. It stops short of pagination or result-limit 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?

Two sentences, zero padding, with the functional scope front-loaded and the billing note deferred. Every clause 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?

An output schema exists, so return values need not be described; parameters are fully documented in the schema and annotations carry the safety profile. Adding cost and spatial scope makes this largely complete, with only minor gaps around result limits or pagination.

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 100%, so the schema already documents all five parameters, including the default radius of 20001 km and the YYYY-MM-DD format for starttime. The description only restates the radius/date concepts at a high level and adds no format or constraint detail beyond the 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?

States a specific verb-free but precise scope: earthquakes filtered by a point-radius and a start date. This distinguishes it from the fixed-window siblings (earthquakes__m25-day, m45-week, significant-week) and from earthquakes__count/event, but it never names or contrasts with them explicitly.

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 'within a radius of a point since a date' implies the spatial-proximity use case and implicitly separates it from the time-window siblings, but there is no explicit when-to-use statement, no named alternative, and no exclusion 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 readOnly, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds genuinely new context the annotations do not: the free daily allowance and the $0.001 USDC per-call x402 charge, which materially affects invocation decisions.

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?

Two short sentences: purpose first, cost second. Every clause earns its place with 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?

An output schema exists, so return values need not be explained. The description covers what the tool returns and its cost model; the one gap is defining 'significant' (the USGS feed criterion) and how it relates to the overlapping m45-week 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?

The tool takes zero parameters, so the baseline is 4; there is no parameter surface the description needs to compensate for. It neither adds nor omits anything meaningful here.

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?

States a specific resource (significant earthquakes), a scope (worldwide), and a time window (past 7 days). It is clear on its own, but it does not differentiate itself from the sibling earthquakes__m45-week, which also covers a weekly window, leaving the agent to infer what 'significant' means versus a magnitude threshold.

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 when-to-use or when-not-to-use guidance and no reference to any of the five earthquake siblings (count, event, m25-day, m45-week, near). The only decision-relevant content is the pricing note, which is a cost signal rather than 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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description usefully adds the commercial model (free within the daily allowance, then $0.002 USDC per call via x402), which is real context an agent cannot get from annotations or 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?

Two sentences, zero padding, with the core purpose front-loaded and the pricing caveat after it. Every clause 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?

With rich annotations, an output schema to explain the return shape, and no parameters, the description only needs to cover purpose and cost, which it does. It is slightly short on the usage/positioning dimension but complete for a zero-parameter snapshot 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?

The tool takes zero parameters, so there is no parameter semantics to explain and baseline credit applies. The description appropriately does not invent parameter details.

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?

States a specific resource ('bid-offer acceptances issued by the system operator') with a clear recency scope ('most recent'). No sibling tool covers acceptances, so an agent can identify this unambiguously against the many gb-electricity demand/generation/forecast 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?

The description gives no when-to-use guidance, no prerequisites, and names no alternatives. 'Most recent' implies a latest-snapshot semantic but there is no equivalent historical tool to steer between, and no statement of what question this answers.

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, open-world behavior. The description adds a genuinely useful trait not in annotations: it is free within a daily allowance and then costs $0.002 USDC per call via x402, which an agent needs for budget decisions. No return-format or refresh-cadence detail, but the output schema covers returns.

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?

Two sentences, zero filler. The core capability is front-loaded and the pricing caveat follows it.

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?

With an output schema handling return values, rich annotations, and an empty input schema, the description only needs to convey purpose and cost, which it does. The missing piece is routing guidance against the crowded sibling set of forecasts.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4.

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?

States a specific verb, resource, granularity and horizon: 'Forecast available generation capacity by fuel type for the next two weeks.' That distinguishes it from demand-forecast, wind-forecast and generation-now siblings. It does not explicitly contrast itself with adjacent forecast tools (margin-forecast, surplus-forecast), so it stops 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?

No statement of when to use this tool versus the many other gb-electricity forecasts (demand-forecast-14d, margin-forecast, surplus-forecast, wind-forecast). The only secondary sentence is about pricing, not selection context.

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 non-destructive, so the safety profile is covered. The description adds genuinely new behavior: the pricing/quota model (free within the daily allowance, then $0.001 USDC per call via x402), which is billing context an agent cannot get from structured fields.

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?

Two short sentences with zero waste: the scope is front-loaded and the cost note follows. Nothing is redundant and nothing needs to be cut.

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?

An output schema exists, so return values need no explanation, and the description covers scope plus cost. The remaining gap is sibling disambiguation against demand-outturn/demand-peak in a namespace of 30+ related tools, which is a real but moderate omission for a zero-parameter reader.

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 takes zero parameters, so the schema has nothing to document and the description has nothing to compensate for. Baseline 4 applies; no parameter meaning is missing or misleading.

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 (total national GB electricity demand) and its granularity (per day, recent days), which is more precise than the bare title. It does not, however, distinguish itself from close siblings such as demand-outturn, demand-peak, or demand-forecast, which an agent in this crowded namespace would need.

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 statement of when to choose this over the many sibling demand tools, nor any exclusion or prerequisite. 'Recent days' implies a recency scope but the agent is left to infer that this is the historical outturn aggregate versus the forecast variants.

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 readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds genuinely new context about the pricing model (free within a daily allowance, then $0.001 USDC per call via x402), which is useful behavioral information not present in structured fields.

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?

Two sentences, zero waste. The substantive scope statement is front-loaded and the pricing note follows as a secondary 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?

An output schema exists, so return values need not be explained. The description covers resolution, scope, horizon, and cost, which is sufficient for a no-parameter read tool; the only minor gap is explicit sibling differentiation.

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 takes zero parameters, so the schema/'description coverage' baseline of 4 applies. There are no parameter semantics for the description to elaborate or compensate for.

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?

States a specific resource (demand forecast) with resolution (half-hourly), scope (national and transmission), and horizon (next day). The 'next day' horizon implicitly separates it from siblings like demand-forecast-14d and demand-forecast-52w, though those siblings are never named explicitly.

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 horizon ('next day') implies when the tool applies, but there is no explicit when-to-use/when-not guidance and no reference to the longer-horizon forecast siblings. Usage is inferable but not 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description earns credit by disclosing the commercial behavior — free within a daily allowance, then $0.001 USDC per call via x402. That cost/rate detail is not derivable from any structured field. It stops short of describing return shape, though an output schema exists.

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?

Two short sentences, the scope statement front-loaded before the pricing note. Every sentence carries information and there is 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?

With no parameters and a provided output schema, the description carries a light load and covers scope plus pricing adequately. The one real gap is disambiguation from the sibling demand-forecast variants, which an agent needs to route 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?

The tool takes zero parameters, so there is nothing for the description to clarify and no schema gap to compensate for. Baseline 4 applies for a parameterless tool.

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?

States a specific resource and scope: daily peak demand forecast over a two-week horizon, which is more than a restatement of the name. However, it never distinguishes itself from close siblings such as gb-electricity__demand-forecast or demand-forecast-52w, so an agent must infer the horizon split from the tool name alone.

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 when-to-use guidance and no mention of alternatives, despite a dense cluster of sibling demand tools (demand-daily, demand-peak, demand-forecast, demand-forecast-52w). The agent gets no rule for picking this horizon over another.

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 cover read-only/idempotent/open-world semantics, and the description adds a genuinely non-obvious behavioral fact: the free daily allowance followed by $0.001 USDC per call via x402. That cost/rate-limit disclosure is real value beyond the structured fields, though update cadence and provisional-vs-settled status are not stated.

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?

Two sentences with no filler: purpose first, commercial terms second. Every clause 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?

With an empty param object and an output schema present, the description does not need to explain return values or inputs. It is nearly complete, missing only minor operational context such as refresh cadence or units.

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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The description rightly spends no words on parameters it does not have.

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?

States a specific verb (forecast), resource (demand), granularity (weekly peak) and horizon (year ahead). This granularity+horizon pairing is what separates it from siblings like demand-forecast-14d and demand-forecast, so an agent can route without opening the schema.

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 on when to choose this over the many adjacent siblings (demand-forecast, demand-forecast-14d, demand-daily, demand-peak, demand-outturn). The only selection-relevant sentence is about pricing, not applicability.

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 the safe-read profile (readOnly, idempotent, non-destructive, openWorld), so the description's main added value is the cost model: free within the daily allowance, then $0.001 USDC per call via x402. That is genuine behavioral context an agent cannot get from annotations or schema, though it does not cover cadence of publication or revision 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?

Two tightly packed sentences that front-load what the data is before pricing. No filler or redundant restatement of the title.

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?

With an output schema present, return values need no explanation, and with zero parameters there is nothing to document. Scope, cadence, window, and cost are all covered; only sibling-routing guidance is missing.

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 takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate beyond the absence of filters, which is not stated but also not needed.

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?

States the resource (national and transmission demand outturn), the temporal resolution (half-hourly), and the window (~2 days), which distinguishes it from siblings like demand-daily, demand-peak, and the demand-forecast family. The word 'Initial' is slightly ambiguous (initial estimate vs outturn revision) but the resource is identifiable.

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 'last ~2 days' hint implies recency, but there is no explicit guidance on when to pick this over demand-daily, demand-peak, or demand-forecast. An agent must infer the choice from the window alone.

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, open-world behavior, so the safety profile is covered. The description adds genuinely useful commercial context (free within the daily allowance, then $0.001 USDC via x402), but says nothing about units, timezone, resolution, or freshness of the peak figure.

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?

Two short sentences, front-loaded with what the tool returns before the pricing note. Nothing is padded, though the pricing sentence is generic boilerplate that could apply to any tool in the server.

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?

An output schema exists, so return values needn't be explained. However, for a tool embedded in a dense family of demand endpoints, the definition is incomplete on the one thing that matters most: how peak demand differs from demand-daily and the forecast variants.

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 takes zero parameters, so there is nothing for the description to disambiguate. The baseline for a no-parameter tool is 4 regardless of schema coverage.

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?

It names a specific resource and metric ('Daily peak transmission demand'), which is more than a tautology. But it does not distinguish itself from the eight sibling demand tools (demand-daily, demand-outturn, demand-forecast, etc.), so an agent cannot tell which demand variant this covers without opening the schemas.

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 when-to-use guidance at all. The entry gives no condition for choosing peak demand over demand-daily or demand-outturn, which is the central selection problem in this cluster of near-identical 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 establish read-only, idempotent, non-destructive behavior, so the description's job is to add beyond that — and it does: 15-second resolution, a one-hour window, and an explicit rate-limit/cost model (free within the daily allowance, then $0.001 USDC per call via x402). That pricing and cadence disclosure is real behavioral value not present in the structured fields.

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?

Two sentences, no filler: the data scope comes first and the cost condition second. Every clause carries information an agent needs before calling.

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?

With an output schema present, return values need not be explained, and with zero input parameters there is no schema gap to fill. The description covers what the resource is, its granularity, its window, and its cost — sufficient for an agent to decide and call 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?

The tool takes zero parameters, so the baseline is 4 per the rubric; there is nothing for the description to disambiguate. The window ('last hour') is a fixed scope rather than an argument, so no parameter semantics are needed.

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?

States a specific resource (grid frequency in Hz) with its sampling cadence and lookback window ('every 15 seconds, last hour'), which is enough to distinguish it from siblings like temperature, demand-*, or generation-now. It does not explicitly name a contrasting sibling, so it falls 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?

Usage is implied by the data scope (real-time frequency is only available for the last hour), and the pricing sentence tells the agent when calls become billable. There is no explicit when-to-use/when-not or named alternative among the many gb-electricity siblings, so this is minimum-viable rather than instructive.

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 readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds meaningful non-schema context: the pricing model (free within a daily allowance, then $0.002 USDC per call via x402), which is exactly the kind of cost/rate information annotations cannot express.

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?

Two short sentences, zero waste. The functional description is front-loaded ahead of the pricing detail, so an agent gets the 'what' 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?

With an output schema present and annotations covering safety, the description needn't explain return values. But 'recent history' is vague (how far back, what window), and the lack of any routing versus generation-now/generation-today leaves a real gap for a tool in a dense sibling cluster.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a parameterless tool is 4.

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?

States a specific resource and granularity: 'half-hourly generation by fuel type, recent history.' This clearly distinguishes a historical mix series from a snapshot. However, it never names the closely related siblings (generation-now, generation-today), leaving the agent to infer where this one fits.

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 phrase 'recent history' implies when this is appropriate versus a real-time or daily view, but there is no explicit guidance, no prerequisites, and no reference to the alternative generation tools. Usage is only weakly 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. Beyond that the description adds genuinely useful context an agent could not infer: the free daily allowance and the $0.001 USDC per-call x402 charge, plus the temporal windows returned. It stops short of noting freshness lag or update cadence hedging.

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?

Two sentences, zero filler, with the core scope front-loaded and the pricing caveat placed last where it belongs. Every clause carries information.

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?

With an output schema present, return-value detail is not the description's job; annotations carry the safety profile; there are no parameters to document. What remains for the description — scope, time grain, units, and cost — is all present and correct.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description's unit and time-window notes are output semantics, not input semantics, so no credit or penalty is warranted here.

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?

States a specific resource (current GB generation by fuel type) with concrete units (MW and %) and a time grain (latest 5-minute reading). It implicitly separates itself from siblings like generation-today and generation-history via 'current' and the 5-minute cadence, but never names or contrasts those siblings explicitly, and the trailing 'last half hour / 24 hours' is ambiguous about what exactly is returned over those windows.

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 choose this tool over generation-today, generation-history, or generation-today-adjacent siblings. The only conditional language concerns billing ('free within the daily allowance, then $0.001 USDC per call'), which is cost context rather than usage 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the cost model — free within a daily allowance, then $0.001 USDC per call via x402 — which an agent needs for budgeting or rate decisions.

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?

Two tight sentences, zero waste, with the core scope front-loaded and pricing relegated to the second sentence. Nothing is repeated from the title.

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?

With zero parameters, an output schema covering return values, and annotations covering safety, the description needs only to state scope and cost — both are present. It stops short of noting granularity (e.g., time resolution) or caveats such as data latency, which would fully round it out.

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 takes no parameters, so the schema cannot convey parameter meaning and the baseline is 4. The parenthetical examples of production types are the only semantic content and are illustrative rather than a formal parameter description.

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 gives a specific verb+resource+scope: actual generation by production type over the last 24 hours, with illustrative types (solar, wind, nuclear, gas). The 24h window implicitly separates it from siblings like generation-now and generation-history, but those alternatives are never named, so an agent must infer the distinction.

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 explicit when-to-use guidance and no comparison to the many sibling generation tools (generation-now, generation-history, wind-solar). The only extra sentence is about pricing, which is not selection 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely valuable behavioral context the annotations do not carry: the pricing model (free within a daily allowance, then $0.001 USDC per call via x402), which is exactly the kind of cost/limit disclosure an agent needs.

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?

Two tightly packed sentences with zero waste. The data scope is front-loaded and the cost caveat follows, which is the right ordering for an agent scanning for relevance first, cost second.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The remaining gap is sibling disambiguation against the many other gb-electricity forecast tools, which is the one thing an agent still cannot resolve from this definition alone.

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 takes zero parameters, so the baseline of 4 applies; there is nothing for the description to clarify and no schema gap to compensate for.

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?

Names the resource precisely — day-ahead indicated demand, generation, imbalance and margin — so the agent knows what data comes back. However, it offers no differentiation from overlapping siblings such as demand-forecast, margin-forecast, or surplus-forecast, leaving the agent to guess what 'indicated' means relative to those.

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 when-to-use guidance, no statement of when this composite view should be preferred over the narrower demand-forecast or margin-forecast siblings, and no prerequisites. The only second sentence addresses pricing, not 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful non-schema context: the pricing/quota model (free within the daily allowance, then $0.0005 USDC per call via x402), which an agent cannot infer from 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?

Two short sentences, front-loaded with what the tool returns and followed by the cost model. Every clause earns its place and nothing is padded.

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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile; a zero-param list tool is low complexity. The one missing piece is disambiguation from the sibling interconnectors 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?

The tool takes zero parameters and the schema is empty, so there is nothing for the description to clarify. Baseline 4 applies; no parameter-level claims are made or needed.

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?

States a specific verb+resource ('Every GB interconnector') and adds the returned attribute (the bidding zone it connects to), so an agent knows exactly what it gets. However, it does not distinguish itself from the near-identical sibling gb-electricity__interconnectors, which is a real ambiguity for a list 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?

No guidance on when to use this versus alternatives. With a sister tool literally named gb-electricity__interconnectors in the sibling set, the absence of any 'use this instead of X when Y' statement leaves the agent to guess which of the two to call.

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 cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuinely new behavioral context the annotations do not: the half-hourly cadence, newest-first ordering, and the pricing model (free within the daily allowance, then $0.002 USDC per call via x402).

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?

Two sentences with no filler: the resource/cadence/ordering come first, and the pricing caveat follows. Every clause carries information an agent can act on.

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?

An output schema exists, so return-value structure need not be restated. The description covers the domain, cadence, ordering, and cost model; only an explicit contrast with interconnector-list is missing.

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 takes zero parameters, so the parameter baseline is 4. No syntax or filtering semantics are needed, and nothing in the description attempts to invent them.

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?

States a specific verb+resource ('flows on each interconnector') with cadence (half-hourly), coverage (France, Norway, Netherlands, …), and ordering (newest first). Clear to an agent, though it never explicitly differentiates itself from the sibling gb-electricity__interconnector-list.

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?

Usage is implied by 'latest half-hourly flows' and 'newest first', so the agent can infer when to reach for it. However, there is no explicit when-to-use guidance nor a pointer to interconnector-list for the static catalogue, leaving selection to 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?

Annotations already cover read-only, idempotent, non-destructive, open-world traits, so the description is not carrying the safety burden. It adds genuinely new context by disclosing the pricing model (free within the daily allowance, then $0.001 USDC per call via x402), which an agent needs for cost-aware invocation, plus the day-2-to-14 data window.

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?

Two compact sentences with zero filler. The core purpose and data horizon are front-loaded, and the pricing caveat follows in second position where it belongs.

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?

With an output schema present, the description needn't document return values, and the annotations carry the safety profile. Purpose, horizon, and cost are all covered; the only missing piece is disambiguation from the similarly named surplus and indicated forecast tools.

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 takes zero parameters, so there is no parameter semantics for the description to explain; baseline 4 applies. The stated days 2–14 range and OCNMFD2 code give useful framing for what the parameterless call will return.

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?

States a specific verb+resource ('daily operating margin forecast') and pins the horizon to days 2–14 with the upstream data code OCNMFD2. It is clear what the tool returns, though it never names or distinguishes itself from the closely related gb-electricity__surplus-forecast sibling, which an agent could easily confuse with 'margin'.

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 when-to-use, when-not, or alternative guidance is given. The description implies forecasting usage but does not say how this differs from surplus-forecast, demand-forecast-14d, or indicated-forecast, all of which are plausible siblings for a grid-balance question.

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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description goes beyond them by disclosing the cost model (free daily allowance, then per-call x402 payment) and the half-hourly granularity, which materially affects whether an agent should call it repeatedly.

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?

Two tight sentences; the data scope is front-loaded and the pricing note follows. No filler or 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?

An output schema exists, so return values need not be explained, and the description covers scope, granularity, and cost. It stops short of resolving overlap with sibling price tools and omits any date-range or timezone conventions.

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 100% with two fully documented date params, so the baseline is 3. The phrase 'between two dates' merely restates the from/to pair and adds no format or boundary detail (timezone, max range) beyond the 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?

States a specific resource (Market Index Data) with granularity and units (half-hourly wholesale price in £/MWh and volume), which is concrete enough to distinguish it from the many other gb-electricity price/forecast siblings. It does not, however, explicitly differentiate itself from close siblings like gb-electricity__system-prices or indicated-forecast.

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 only guidance is commercial: free within the daily allowance, then $0.002 USDC per call via x402. There is no statement of when to use this tool versus system-prices or the various forecast tools, nor any prerequisite or exclusion.

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 readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful non-schema context: the free daily allowance and the $0.001 USDC per-call x402 pricing, which an agent needs to decide whether to invoke.

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?

Two tight sentences: the first front-loads what is returned, the second carries the pricing constraint. Nothing 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?

With an output schema present, return-value detail is unnecessary, and the read-only annotations plus the disclosed pricing make the description sufficient to call correctly. Only the missing link to the outages list keeps it from a 5.

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?

There is a single required parameter ('id') with 100% schema description coverage ('Message id from outages'). The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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?

States a specific resource ('one outage notice') and enumerates the content (plant, fuel, normal/available capacity, cause, event window), so the agent knows this is the single-record detail endpoint. The singular 'one' implicitly contrasts with the sibling list tool gb-electricity__outages, but the differentiation is not made explicit.

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?

Usage is only implied: 'one outage notice' suggests this fetches detail for a record obtained from the outages list, but no alternative tool is named and no condition for choosing it is stated. Adequate minimum-viable guidance for a simple lookup.

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, open-world, non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context beyond annotations: the cost model (free within daily allowance, then $0.002 USDC per call via x402), which matters for agent budgeting. It does not add rate limits or return shape, but an output schema exists.

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?

Two short sentences with the purpose and sibling routing front-loaded, followed by the cost note. Nothing is redundant or padded.

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 two-parameter, read-only list tool with an output schema and full annotation coverage, the description supplies everything an agent needs to invoke it correctly: scope, sibling routing, and cost. Only minor detail (e.g., ordering or volume of returned notices) is absent, which the output schema likely covers.

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 100%, so both 'from' and 'to' are already documented in the schema, including the ISO example. The description only restates the time-window concept without adding format or boundary semantics, so the baseline 3 is appropriate.

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?

States a specific resource ('outage and unavailability messages') and the scope ('published between two times'), and explicitly distinguishes itself from the singular sibling by noting that individual records are fetched with 'outage'. An agent can tell it apart from gb-electricity__outage without opening either schema.

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?

Clearly frames the use case (messages in a time window) and routes to the alternative ('fetch each with outage') for per-id retrieval. No explicit exclusions or preconditions are given, but the selection context is clear.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's main added value is the pricing model — free within the daily allowance, then $0.001 USDC per call via x402 — which is genuinely important for an agent to know before calling. It omits any note on data freshness or update cadence, which keeps it short of a 5.

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?

Two short sentences, zero waste, with the resource and time horizon front-loaded and the billing caveat second. Every clause 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?

For a zero-parameter read tool with an output schema that already documents the return shape, the description covers purpose, horizon, and cost adequately. The remaining gap is the lack of differentiation from the other gb-electricity forecast tools, which matters given how many similar siblings exist.

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 takes zero parameters, so the baseline is 4. The description correctly adds no parameter detail and instead specifies the forecast horizon baked into the resource, which is the only input-like information relevant here.

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?

States a specific resource and verb ('generating plant surplus forecast') plus a distinct horizon ('days 2–14'), which separates it from the daily/history sibling tools. It does not, however, differentiate itself from the adjacent 'margin-forecast' or 'capacity-forecast' tools, which an agent could easily confuse for the same thing.

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 says nothing about when to reach for this tool versus margin-forecast, capacity-forecast, or indicated-forecast. The only selection hint is the implicit day-2–14 horizon; there are no exclusions or alternatives 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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the free daily allowance and the $0.002 USDC per-call x402 charge, which tells the agent this call has a metered cost. It does not mention pagination or latency, so not a 5.

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?

Two sentences, zero filler, and the data scope is front-loaded ahead of the cost note. Every clause carries information the agent needs.

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, one-parameter tool with an output schema covering the return shape, the description is nearly complete: it states the data, the granularity, and the billing model. Only minor operational details (timezone of the settlement date, response size for a full day) are absent.

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 100% and the schema documents the single required 'date' parameter with its format, so the baseline is 3. The description's phrase 'every settlement period of a day' slightly reinforces that the date selects a whole day rather than an instant, but adds no format or timezone detail.

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?

Names the specific resource (system sell/buy price plus net imbalance volume) and the granularity (every settlement period of a day), so an agent knows exactly what data comes back. It doesn't explicitly differentiate from the nearby pricing sibling market-index, which keeps it from 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 when-to-use statement, no prerequisite, and no routing to or away from alternatives such as market-index or demand-outturn. The only supplementary context is a billing note, which is cost guidance rather than selection 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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's job is to add what they don't say. It does: it discloses the commercial behavior — free within a daily allowance, then $0.001 USDC per call via x402 — which is meaningful cost/throttling context an agent needs before calling.

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?

Two short sentences with zero filler: the measurement and its reference baseline come first, the cost model second. Every clause 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?

With an output schema present, return values need no explanation, and a zero-parameter tool removes input ambiguity. The description covers purpose, comparative baseline, and pricing; the only omission is the temporal coverage/window of 'daily' values, a minor gap.

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 takes zero parameters, so there is nothing for the description to disambiguate; the schema is complete at 100% coverage. Baseline 4 applies with no 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 states a concrete verb+resource pair ('Daily GB average temperature') and adds a comparison scope ('against seasonal reference values') plus a rationale ('drives demand'). It is clear enough to distinguish from wind-forecast or demand-daily, though it never names a sibling explicitly.

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 pick this tool over the many nearby gb-electricity siblings (demand-daily, demand-forecast, system-prices). The parenthetical '(drives demand)' hints at relevance to demand analysis but is not a usage rule or an alternative-selection cue.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds a behavioral trait the annotations do not: the cost/rate-limit model (free within the daily allowance, then $0.001 USDC per call via x402), which materially affects whether an agent should invoke it.

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?

Two sentences, front-loaded with what the tool returns before the pricing caveat. Efficient and free of padding, though the parenthetical enumeration is the only content-bearing clause.

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?

An output schema exists, so return shape need not be described, and with zero parameters and rich annotations the structured fields carry most of the burden. The description adequately covers scope and cost; the only meaningful omission is routing guidance against the overlapping forecast siblings.

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 takes zero parameters, so the schema baseline of 4 applies. There is nothing for the description to disambiguate, and it correctly adds no spurious parameter language.

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?

States a specific verb-less resource ('system operator warnings and notices') and enumerates what qualifies as a warning: margin notices, SO-SO trades, capacity warnings. However, it never distinguishes this from the semantically overlapping siblings gb-electricity__margin-forecast and gb-electricity__capacity-forecast, leaving an agent to guess whether a 'margin notice' belongs here or there.

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 when-to-use, when-not-to-use, or alternative-tool guidance is given. The only conditional in the text is a pricing threshold, which is about cost, not about when this tool is the right selection over the many other gb-electricity 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 read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely useful behavioral context not present in structured fields: the free daily allowance and the $0.001 USDC per-call x402 cost after it, which an agent needs for cost-aware invocation.

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?

Two sentences, zero waste, and the substance (what it returns, resolution, horizon) is front-loaded before the pricing detail. Every clause 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?

With an output schema present, return values need not be explained, and the parameterless schema needs no coverage. Annotations carry the safety profile and the description supplies horizon and cost, leaving nothing an agent needs in order 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?

The tool takes zero parameters, so there are no parameter semantics to document; baseline 4 applies. The description correctly avoids inventing inputs and instead spends its words on horizon and cost.

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?

States a specific verb+resource (wind generation forecast) with resolution (half-hourly) and horizon (~2 days), which differentiates it from siblings like demand-forecast or generation-now. It does not explicitly distinguish itself from the nearby gb-electricity__wind-forecast-peak or wind-solar, leaving that comparison to inference.

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 ~2-day half-hourly horizon implies when this tool is appropriate versus longer-horizon or peak-focused siblings, but no alternative is named and no when-not-to-use condition is given. Usage is implied rather than 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, covering the safety profile. The description adds a genuinely useful behavioral trait not in the annotations - the cost model and payment mechanism (x402, $0.001 USDC per call after a daily free allowance) - which factors into invocation decisions. It stays silent on horizon, timezone and granularity, so it adds value but not rich 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?

Two sentences, zero waste. The functional statement is front-loaded and the billing note follows as secondary 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?

With an output schema present, return values need no explanation, and with zero parameters there is nothing to document on the input side. The definition covers purpose and cost adequately; only forecast horizon/units would add marginal 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 tool takes zero parameters and the schema is an empty object, so there are no parameter semantics for the description to explain. Baseline 4 applies for a no-parameter tool; the description correctly avoids inventing arguments.

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+resource ('Forecast peak wind generation') with the scope qualifier 'for each day', so an agent knows it returns a daily peak series rather than a raw time series. It does not explicitly distinguish itself from the sibling gb-electricity__wind-forecast or gb-electricity__wind-solar, leaving the peak-vs-full-series distinction to inference.

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 only guidance is commercial: 'Free within the daily allowance, then $0.001 USDC per call via x402.' There is no statement of when to choose this tool over gb-electricity__wind-forecast, no hint about the forecast horizon, and no prerequisites 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is covered. The description usefully adds commercial behavior beyond that: free within the daily allowance, then $0.002 USDC per call via x402, which tells the agent about a metering/payment constraint not present in any structured field.

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?

Two short sentences, the core purpose is front-loaded, and the secondary pricing note is properly subordinated. 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?

An output schema exists, so return shape need not be explained, and the tool has only two required date params. The description covers purpose and cost, but omits the lag/estimation caveat implied by 'actual or estimated' (e.g., data freshness or revision) that an agent might need.

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 100% for both parameters, so 'from' and 'to' are already fully documented as YYYY-MM-DD dates. The description's 'between two dates' adds no format, boundary, or range semantics beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource: wind (on/offshore) and solar generation with a date range, and the word 'Actual or estimated' implicitly separates it from the sibling forecast tools (wind-forecast, wind-forecast-peak). It stops short of naming any alternative, so it is clear but not fully self-differentiating.

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 no when-to-use guidance, no prerequisites, and no exclusions or alternatives, despite several overlapping siblings (wind-forecast, generation-history, generation-today). The only constraint conveyed is the two-date range, which is already implied by the parameters.

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 establish the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint). The description adds genuinely new behavioral context not present in annotations: the output cadence (hourly then 6-hourly), the ~9 day horizon, and the x402 pricing model with a free daily allowance followed by per-call charges.

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?

Two compact clauses with zero filler, and the substantive content (granularity, horizon, variables) is front-loaded ahead of the billing note.

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?

An output schema exists, so return-value explanation is not required, and the description covers cadence, horizon, variables, and cost. Minor gaps remain around coordinate formatting and timezone/units, but for a two-parameter lookup tool this is close to 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 100%, so lat/lon are already documented in the schema and the baseline is 3. The description adds nothing about coordinate format, precision, or units beyond what the schema provides.

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 (weather forecast) and scopes it precisely: hourly-then-6-hourly granularity, ~9 days, and the variables returned (temperature, wind, cloud, precipitation, symbol). It does not, however, differentiate itself from the obvious sibling global-weather__forecast-complete or us-weather__forecast, leaving the agent to infer the boundary.

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 choose this tool over global-weather__forecast-complete or the us-weather forecast variants. The only conditional content is billing ('free within the daily allowance, then $0.002 USDC per call'), which is cost information rather than usage 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context that structured fields do not: the cost model ('free within the daily allowance, then $0.003 USDC per call via x402'), which tells the agent about rate limits and paid overflow. It doesn't, however, describe response granularity or time-horizon 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?

Two tightly packed sentences with no waste: content scope first, commercial constraint second. Every clause earns its place and the most decision-relevant information is front-loaded.

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?

With an output schema present, return values need no explanation, and annotations cover the safety profile; the description supplies the missing pieces (forecast fields, pricing/allowance). The remaining gap is the absence of explicit differentiation from global-weather__forecast.

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 100% (both lat/lon documented), so the schema already carries parameter meaning and baseline is 3. The description adds nothing about coordinate format, units, or expected ranges, so it neither helps nor hurts.

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?

States a specific verb+resource ('Full forecast') and enumerates the fields it adds (humidity, pressure, fog, UV, precipitation ranges), so the agent knows this is the detailed variant. However, it never names the sibling global-weather__forecast or explicitly contrasts itself with it, so differentiation must be inferred from 'Full'.

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 word 'Full' implies this is the richer option versus global-weather__forecast, but there is no explicit when-to-use/when-not guidance, no statement of prerequisites (beyond the cost note), and no named alternative. Usage is only 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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds a genuinely useful behavioral trait they do not: the cost model ('free within the daily allowance, then $0.001 USDC per call via x402'), which affects an agent's decision to call.

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?

Two tight sentences, purpose front-loaded ahead of the cost note. Nothing is wasted and the key facts come 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?

An output schema exists so return values need no explanation, annotations cover the safety profile, and the cost model is disclosed. Only the absence of alternative-routing guidance keeps it short of 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 100%, so lat/lon/date are already documented, and the description adds only the vague phrase 'for a point and date'. Baseline 3 when the schema carries parameter meaning.

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?

States the specific resources returned (moonrise, moonset, moon phase) and the input domain (a point and date). This clearly distinguishes it from the sibling sun tool, though it never names the alternative explicitly.

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 pricing sentence gives useful context on cost exposure, but there is no explicit when-to-use, when-not-to-use, or routing guidance (e.g. relative to global-weather__sun or forecast). Usage is only 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?

Annotations already declare readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: a regional coverage limit (Nordic and North Sea waters) and a pricing model (free within daily allowance, then $0.002 USDC via x402), both of which affect whether an agent should call it.

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?

Two sentences, zero filler, and the data/resource statement is front-loaded ahead of the pricing caveat. Every sentence carries distinct information.

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?

An output schema exists, so return-value detail is not required, and annotations carry the safety profile. The description covers geographic scope and cost, leaving only minor gaps (coordinate format, units) that the schema partially handles.

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 100% with only lat/lon, both documented in the schema, so the baseline is 3. The description adds no coordinate format, unit, or valid-range detail beyond what the schema already states.

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 set (wave height and direction, sea temperature and currents) and scopes it to Nordic and North Sea waters, which cleanly separates it from global-weather__forecast and global-weather__moon/sun. It states clearly what data comes back but never names a sibling to route against.

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 when-to-use guidance and no mention of when an agent should prefer global-weather__forecast or any other sibling over this tool. The geographic scoping is the only implicit selection hint, and it is not framed as a usage rule.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context not present in the annotations: a free daily allowance with a $0.001 USDC per-call x402 charge above it, which tells the agent about rate/cost constraints before invoking.

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?

Two short sentences, front-loaded with what the tool returns before the billing note. Every clause carries information; the pricing sentence is relevant rather than filler, though it could arguably be moved to a separate billing field.

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?

With an output schema present, return values need no explanation, and annotations carry the safety profile. Purpose, input scope and cost model are all covered; only edge details such as what happens when the daily allowance is exhausted or how x402 payment is settled are omitted, which is minor for a simple lookup.

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 100% and all three parameters (lat, lon, date) are documented in the schema, including the default for date. The description's 'for a point and date' merely restates that mapping without adding format, range, or unit detail, so the baseline 3 applies.

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 data set (sunrise, sunset, solar noon) scoped to a point and date, which an agent can easily tell apart from siblings like global-weather__moon or global-weather__forecast. It stops short of explicitly naming a sibling or the boundary condition that selects this one, so it is clear but not fully differentiated.

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 explicit when-to-use or when-not-to-use guidance, and no alternative is named (e.g. use global-weather__moon for lunar data). The phrase 'for a point and date' weakly implies the input shape but is not usage guidance; the rest of the text is about pricing.

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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavioral context the annotations lack: the metered pricing model (daily free allowance, then $0.001 USDC via x402), which affects how an agent should budget 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?

Two short sentences with no padding, and the resource identification leads. The awkward first clause slightly blurs the opening but nothing 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?

An output schema exists, so return values need not be described, and the schema fully covers the single parameter. However, for a lookup-by-code tool there is no mention of invalid/missing code behavior, and the purpose statement is too imprecise to tell the agent what it will actually get back.

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 100% with a single 'area' parameter documented as 'Flood area code'. The description adds nothing beyond that (no format, prefix, or valid-code hints), so the baseline of 3 is appropriate.

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 clause is garbled — it looks like a list of return fields (description, river or sea, polygon reference) rather than a statement of purpose — but 'for one flood area' implies a single-area lookup by code. It does not distinguish itself from siblings such as uk-flood__flood-areas-near or uk-flood__warnings, so an agent must infer the difference.

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 when-to-use guidance, no prerequisites, and no mention of the sibling flood tools. The only conditional information is billing ('free within the daily allowance, then $0.001 USDC per call'), which is a cost note, not usage 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the cost model (free within a daily allowance, then $0.002 USDC per call via x402), which affects how an agent should batch or budget calls. It still says nothing about result shape or result-count limits.

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?

Two compact sentences with zero filler, and the core spatial purpose is front-loaded before the commercial detail. Every sentence carries distinct information.

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?

With an output schema present and annotations covering the safety profile, the description need not explain return values, and it does cover spatial scope plus an unusual x402 billing constraint. The remaining gap is sibling disambiguation against uk-flood__warnings-near and uk-flood__flood-area, which share the same domain.

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 100%, with lat, long and the dist radius (default 5 km) all documented in the schema itself, so the baseline is 3. The description adds no format details (e.g. decimal degrees, coordinate system) or interpretation of the radius beyond what the schema already provides.

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?

States a specific verb and resource ('flood alert and warning areas') plus the spatial scope ('within a radius of a point'), so the agent knows it returns area polygons, not station readings. However, it never distinguishes itself from the very similar sibling uk-flood__warnings-near, which by name sounds like it retrieves overlapping 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 gives no when-to-use context, no prerequisites, and no guidance on choosing between this tool and siblings such as uk-flood__warnings-near, uk-flood__flood-area, or uk-flood__stations-near. The only routing information present is the pricing note, which is not usage 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond the annotations: the free daily allowance and the $0.002 USDC x402 cost after that, which tells the agent this is a metered/paid endpoint and to avoid redundant 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?

Two short sentences with zero filler; the purpose is front-loaded and the pricing caveat follows immediately. 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?

With an output schema present and full parameter documentation, the description does not need to explain return values, and it covers cost behavior. The remaining gap is sibling disambiguation against uk-rivers__rainfall-near, which is the one thing an agent could plausibly get wrong here.

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 100%, so lat, long and dist are already documented in the schema (including the default radius of 5 km). The description adds no parameter meaning beyond that, so the baseline 3 applies.

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 ('Rainfall stations') and scope ('near a point'), so an agent knows it returns nearby rain gauges. However, it does nothing to distinguish itself from the near-identical sibling uk-rivers__rainfall-near (nor from uk-flood__stations-near), leaving a real disambiguation gap for an agent picking between namespaces.

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 when-to-use or when-not-to-use guidance, no mention of how it relates to the sibling 'stations-near' or 'uk-rivers__rainfall-near' tools, and no prerequisite context. The only 'guidance' is pricing, which is a cost note rather than selection 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond them by disclosing the pricing model (free within the daily allowance, then $0.002 USDC per call via x402), which an agent needs before invoking.

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?

Two short sentences with zero waste, front-loading what the tool returns before the cost note. Every clause 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?

For a one-parameter read tool with a full output schema and complete annotations, the description covers purpose and cost. It is not quite complete on sibling differentiation, but nothing essential to correct invocation is missing.

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 100% for the single riverName parameter, including a format example. The description's phrase 'named river' mirrors the schema without adding syntax or edge-case detail, so the baseline of 3 applies.

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?

States a specific verb+resource: monitoring stations on a named river. The 'by river' scoping implicitly separates it from location-based siblings like uk-flood__stations-near and uk-rivers__stations-near, though it never names them.

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 requirement of a river name implies when this tool applies, but there is no explicit when-to-use guidance or routing against the many sibling station tools (uk-flood__stations-near, uk-flood__station, uk-rivers__stations-near). Usage must be inferred.

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 openWorldHint, so the safety profile is covered. The description does add genuinely new behavior — the metered pricing (free within daily allowance, then $0.002 USDC per call) and the 'currently in force' active-only filter — but says nothing about freshness or update cadence.

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?

Two short sentences with the scope statement front-loaded and the cost note last; every sentence carries information. The only cost is the conflation of severe and non-severe warnings in the opening clause.

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?

With an output schema present, return values need no explanation, and annotations cover the read-only profile. The description supplies scope and pricing, leaving only the sibling-differentiation gap relative to uk-flood__warnings.

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 takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No syntax or format detail is needed or missing.

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?

It names the resource (flood warnings currently in force) but supplies no verb, leaving it ambiguous whether the tool lists, searches or fetches. The scope sentence is also muddled: the tool is named 'severe-warnings' yet claims to return both severe and ordinary flood warnings, which blurs its boundary against the sibling uk-flood__warnings.

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 on when to choose this over uk-flood__warnings or uk-flood__warnings-near, nor any precondition. The agent must infer the distinction from the name alone.

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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description does add genuine behavioral value with the pricing model (free within the daily allowance, then $0.001 USDC via x402), which is exactly the kind of context annotations cannot carry, but it says nothing about rate limits, auth, or failure behavior for an unknown reference.

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?

Two sentences, zero waste. The content summary is front-loaded and the pricing caveat is appended where it belongs, so an agent gets the essential information in the first clause.

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?

With an output schema present, return values need not be explained, and the description's field list plus pricing makes it callable as-is. The remaining gap is sibling disambiguation against uk-rivers__station and uk-flood__station-latest, which this crowded tool family would benefit from.

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 100% and the schema itself supplies the format example ("1491TH"), so the description need not repeat it. The description adds no syntax, casing, or lookup guidance beyond the schema, making a baseline 3 appropriate.

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?

States a concrete resource ("one monitoring station") and enumerates the returned content (location, river, typical range, measures), so the agent knows what it retrieves. However, it does not distinguish itself from close siblings like uk-rivers__station or uk-flood__station-latest, which an agent could easily confuse it with.

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?

Usage is only implied: call this when you already have a station reference and want detail. There is no explicit when-to-use, no pointer to uk-flood__river-stations or stations-near for discovering a reference, and no statement of when a sibling (station-latest for current readings) is preferable.

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 cover readOnly, idempotent, openWorld and non-destructive, so the bar is low, and the description adds genuinely useful context beyond them: the maximum 4-week history window and the monetization model (free within the daily allowance, then $0.003 USDC per call via x402). It does not describe pagination or truncation behavior when the result set exceeds _limit.

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?

Two tight sentences, zero filler, with the resource and lookback window front-loaded and the cost note trailing where it belongs.

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?

An output schema exists, so return values need not be explained, and the description covers the resource, the time window, and cost. The remaining gap is result-set handling (pagination/truncation at _limit) for what is a time-series history endpoint.

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 100%, so the baseline is 3. The description adds one real constraint not present in the schema – that `since` cannot go further back than 4 weeks – but says nothing about `_limit` behavior or station reference format beyond what the schema already documents.

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?

States a specific verb+resource ('Readings from a station') and scopes it with the since date-time and a 4-week lookback, which distinguishes it from uk-flood__station-latest and uk-flood__station. It stops short of naming those siblings explicitly, so an agent must infer the boundary between this and the latest-reading 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 4-week lookback constraint and the pricing note imply when this tool is appropriate (historical series rather than current conditions), but there is no explicit when-to-use vs when-not, and no alternative sibling is named. Usage is inferable but not 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond the annotations: the pricing model (free within daily allowance, then $0.002 USDC per call via x402). It does not describe response shape, but an output schema exists.

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?

Two sentences, zero waste, with the core purpose front-loaded before the cost note. Every clause 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?

For a single-parameter read tool with full annotations and an output schema, the description covers purpose and cost adequately. It stops short of clarifying what 'every measure' returns or how it differs from the sibling station tool, but the structured fields carry the rest.

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 100% and the single 'station' parameter is documented with an example in the schema, so baseline 3 applies. The description adds no syntax, format or example detail beyond what the schema already provides.

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?

States a specific verb+resource: latest readings from every measure at a station, which distinguishes it from history-oriented siblings like uk-flood__station-history. It does not explicitly name or contrast with the closest sibling (uk-flood__station), so it falls 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?

The word 'Latest' implies current-state retrieval as opposed to the historical variant, but no when-to-use guidance or explicit alternatives are given. The agent must infer the boundary against uk-flood__station and uk-flood__station-history.

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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description usefully adds the pricing/allowance model, which no annotation provides and which an agent must know before calling. It stops short of covering result volume or the effect of a large dist.

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?

Two sentences, front-loaded with the resource and location scope before the pricing caveat. 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?

An output schema exists, so return-value explanation is not required, and the description names the station categories returned plus the cost model. What is missing is any hint about the maximum usable radius or expected result counts for an open-world spatial query.

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 100% (lat, long, dist all documented with the km default), so the schema carries parameter meaning. The description adds nothing about coordinate format or a maximum radius, so baseline 3 applies.

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?

States the resource (river level, flow, tidal and rainfall monitoring stations) and the spatial scope ('near a point'), which separates it from uk-flood__river-stations and uk-flood__rainfall-near. It does not explicitly name those siblings, so a reader must infer the distinction from the resource wording alone.

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 only guidance is commercial: free within the daily allowance, then $0.002 USDC per call via x402. There is no statement of when to prefer this over uk-flood__rainfall-near, uk-flood__tide-gauges or uk-flood__river-stations, nor any note on radius or result-count limits.

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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds a genuinely useful behavioral fact the annotations cannot convey: the pricing model (free within a daily allowance, then $0.001 USDC per call via x402). It does not discuss rate-limit ceilings or result freshness, but the cost disclosure is meaningful added 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?

Two short sentences with zero waste. The scope statement is front-loaded ahead of the commercial detail, so the agent gets the 'what' first and the 'cost' second.

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?

An output schema exists, so return fields need not be explained, and the cost model is disclosed. The description stops short of noting coverage limits (England only, tidal gauges only) as an explicit exclusion, but for a zero-parameter listing tool this is close to 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 tool takes zero parameters, so there is no parameter surface for the description to explain. Baseline of 4 applies; nothing is misleading or missing.

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?

Names a specific resource ('tidal level monitoring station') and bounds it geographically ('in England'), which implicitly separates it from the river-station siblings. It reads as a noun phrase rather than stating the verb (list/retrieve), but the operation is 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?

No guidance on when to pick this over sibling tools such as uk-flood__river-stations, uk-flood__stations-near, or uk-flood__station. The agent must infer from the phrase 'tidal level' alone that this is the tidal-station listing.

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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavioral context: geographic coverage is England only, and it discloses the pricing model (free within daily allowance, then $0.002 USDC per call via x402), which matters for planning repeated 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?

Two short sentences, front-loaded with what the tool returns and followed by cost. Every clause carries information an agent can act on; nothing is padding.

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?

An output schema exists, so return values need no explanation, and the description supplies scope (England) and cost. The only gap is that it never positions itself against the severity- or location-filtered siblings, so routing among the uk-flood tools is left partly to guesswork.

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 takes zero parameters, so the schema baseline of 4 applies and there is nothing for the description to disambiguate. No parameter detail is needed or missing.

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?

States a specific resource and scope: all flood alerts and warnings currently in force, in England. It does not explicitly contrast itself with close siblings such as uk-flood__severe-warnings or uk-flood__warnings-near, though 'every ... currently in force' implies an unfiltered full list.

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 when-to-use guidance and no exclusions. With siblings like uk-flood__severe-warnings (severity-filtered) and uk-flood__warnings-near (location-filtered), the description should say when this unfiltered national list is the right pick, but it leaves that to 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?

Annotations already cover readOnly, idempotent, openWorld, and non-destructive hints, so the bar is lower. The description adds genuinely non-structured behavioral context: the cost model (free within a daily allowance, then $0.002 USDC per call via x402) and the 'in force' filter meaning only currently active alerts are returned, which is meaningful for an open-world read.

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?

Two short sentences with the core capability front-loaded and zero padding. The pricing sentence consumes roughly half the description, which is justified for a paid x402 endpoint but is slightly disproportionate to the functional payload.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. Coverage is close to complete for a 3-parameter geo query, though it omits geographic coverage limits (UK only) and how results distinguish alerts from warnings or rank by distance.

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 100%, so lat, long, and dist with its default of 5 are fully documented in the schema itself. The description only restates the geospatial model ('radius of a point') without adding unit conventions, coordinate format, or radius bounds, so the baseline of 3 applies.

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?

States a specific resource ('Flood alerts and warnings in force') and a spatial scope ('within a radius of a point'), which implicitly separates it from the unfiltered sibling uk-flood__warnings. It does not explicitly name a sibling or call out the severe-only variant, so it falls 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?

No when-to-use or when-not-to-use guidance is provided. An agent must infer from the phrase 'near a point' that this is the right tool when it has coordinates, and there is no direction on how it differs from uk-flood__warnings, uk-flood__severe-warnings, or uk-flood__flood-areas-near.

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 establish readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema context: the free daily allowance and the $0.002 USDC x402 charge after it. It stops short of saying what happens when a station has no measure of the requested type.

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?

Two sentences, both load-bearing, with the core behavior front-loaded ahead of the cost note. Slightly dense in the first sentence but no padding or restatement of the title.

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?

An output schema exists, so return values need not be explained. For a two-param read-only lookup the description covers purpose and cost adequately; only empty-result and unknown-station behavior are left unstated, which is a minor gap.

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 100% and the type param already enumerates 'level | flow | rainfall | groundwater', which the description merely restates. The phrase 'for each measure of a type' hints that results may be multiple per station, but no added syntax or format detail beyond the 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?

States a specific verb and resource: the latest reading per measure of a given type at a station. It is distinguishable from uk-rivers__readings in spirit (latest vs. historical) but never names or contrasts those siblings, so the agent must infer the boundary from naming alone.

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 on when to choose this over uk-rivers__readings, uk-rivers__station, or uk-flood__station-latest, and no prerequisites stated beyond the pricing note. The only conditional content concerns billing, not tool 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 cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful non-structured context: the free daily allowance and the $0.003 USDC per-call x402 charge, which matters for an agent deciding whether to call. It does not disclose default radius behaviour or result ordering, but the pricing disclosure is substantive.

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?

Two tight sentences with zero filler, front-loading what the tool returns before the cost note. Every clause 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?

An output schema exists, so return-value detail is unnecessary, and annotations carry the safety profile. The description covers location flexibility and cost, but for a tool whose name collides with uk-flood__rainfall-near it lacks any disambiguation, which is the one real gap.

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 100%, with each of the four parameters (lat, lng, postcode, radius_km) documented, so the baseline is 3. The description only restates the either/or nature of postcode vs point that the schema already conveys, adding no new format or constraint detail.

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?

States a specific resource (nearest rain gauges) and output (latest rainfall totals) plus accepted location inputs, so the agent knows exactly what it returns. However, it does nothing to distinguish itself from the near-identical sibling uk-flood__rainfall-near, leaving ambiguity about which provider's rainfall data to use.

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 when-to-use guidance, no prerequisites, and no mention of when to prefer the sibling uk-flood__rainfall-near or uk-rivers__stations-near. The only contextual guidance is commercial (free tier / per-call price), which is not selection 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 cover readOnly, idempotent, openWorld, and non-destructive, so the bar is lower. The description adds genuinely non-structured context: a metered pricing model (free within daily allowance, then $0.002 USDC per call via x402) and the default ordering. It stops short of describing pagination or truncation behavior, but the pricing disclosure is a real value-add.