Transport & travel

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

Annotations already declare readOnly, idempotent and open-world, so the description usefully adds the cost/payment model (free within daily allowance, then $0.001 USDC per call via x402), which is not captured anywhere in the structured fields. It also lists returned fields. It does not discuss error behavior on invalid codes, 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 compact sentences, front-loading the resource and key before the field list and pricing. The field enumeration is slightly run-on but each element is informative.

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 lookup with a full output schema and complete annotations, the description is nearly sufficient, covering key format and cost. It would be stronger if it explicitly steered code-less queries to the sibling search/near 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?

Schema description coverage is 100% and the single 'code' parameter is already documented as ICAO/IATA/ident with examples. The description repeats this same triplet without adding format rules or fallback behavior, 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 a clear resource (airport) and lookup key (ICAO, IATA or ident), and enumerates returned fields. The title 'Airport by code' further distinguishes it, but the description itself never names the sibling lookups (near, search) it differs from.

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 'by ICAO, IATA or ident' implies a code-keyed lookup, but there is no explicit when-to-use guidance or routing to alternatives like airports__near or airports__search for location/name queries.

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, and non-destructive behavior, so the bar is lower. The description adds meaningful context by disclosing the cost model (free within daily allowance, then $0.001 USDC per call via x402) and summarizing return content, which is valuable for an agent managing paid 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 sentences, no wasted words. The first sentence is slightly awkward in phrasing but front-loads the core data description; the pricing clause follows succinctly. Overall appropriately sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity, full schema description coverage, rich annotations, and an output schema, the description is complete enough. It adds pricing context and a brief return summary; no critical missing piece would prevent correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the single 'country' parameter is documented as a '2-letter country code'). The description adds no additional parameter meaning, so the baseline score 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?

The description states the resource and scope: airport data aggregated by country, including counts by type, large airports, and regions. It is clear what data is returned, but it does not explicitly contrast this tool with siblings like airports__airport or airports__search, leaving the agent to infer when this aggregate view is preferable.

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. The description only describes the data returned and the pricing model; it never names alternatives or conditions under which this tool should be chosen over the many sibling airport tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety needs no restating. The description adds genuinely new behavioral context: the unit of the returned values (MHz) and the metered pricing model with its daily allowance and per-call charge, which annotations cannot express. It stops short of describing result shape or rate-limit behavior beyond price.

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 resource and its unit come first, the billing condition second. No filler, no repetition of the title, and nothing an agent must read past to find the core meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one required identifier), an output schema exists so return values need not be documented, and annotations carry the safety profile. Pricing and unit are disclosed, leaving only minor gaps like whether multiple frequencies are returned or how results are ordered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With a single parameter and 100% schema description coverage, the schema already explains that code accepts ICAO (EGLL), IATA (LHR) or an OurAirports ident. The description adds nothing about the identifier parameter, so the baseline 3 for schema-covered parameters 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?

Names the resource precisely (an airport's radio frequencies) and enumerates the concrete channel types (tower, ground, ATIS, approach), which distinguishes it from sibling tools like airports__runways or airports__navaids-near. The retrieval verb is implicit rather than stated, but the resource and scope are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description never says when to reach for this tool versus airports__airport, airports__runways, or the other airport siblings. The only conditional language concerns billing (free within the daily allowance, then $0.001 USDC), which is cost information, 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description usefully adds the billing behavior (free within the daily allowance, then $0.002 USDC per call via x402), which an agent cannot infer 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 tight sentences: the resource/scope and return content come first, the billing caveat second. No filler, nothing redundant, and the most important 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?

An output schema exists (covering return values) and annotations cover safety, so the description only needs purpose and operational caveats – both present, including pricing. The main omission is routing guidance relative to airports__near and the other navaid-adjacent 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?

Schema description coverage is 100% – lat, lng, postcode, radius_km and limit are all documented with defaults and the postcode alternative. The description adds no syntax or format detail 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?

The description states a specific resource (VORs, NDBs, DMEs and other navaids) and scope (within a radius of a point), and adds what is returned (frequency and associated airport). It is clearly distinguishable from airports__near or airports__frequencies by resource type, though it never names an 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?

There is no when-to-use or when-not-to-use guidance, and no reference to the sibling tools (e.g. airports__near for airports, airports__frequencies for a specific navaid's frequencies). The pricing sentence describes cost, 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 readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds genuinely non-structured behavior: the pricing model (free within daily allowance, then $0.002 USDC via x402) and result ordering (nearest first). It stops short of describing pagination or what happens with no location supplied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with what the tool returns and how it is scoped; the cost footnote is short and earns its place. No filler or repeated schema content.

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 the description covers resource, default filtering, ordering, and cost. The one gap is behavior when neither lat/lng nor postcode is provided, especially since zero parameters are required.

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 baseline is 3, and the description earns a bump by disclosing a default the schema omits: type defaults to large/medium/small. It also corroborates the lat/lng-vs-postcode alternative, though it adds no syntax or format detail for radius_km or scheduled.

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 (find airports near a point/postcode) plus the scope qualifiers that matter: which airport types are included by default, radius-based search, and nearest-first ordering. It clearly differentiates from siblings like airports__search (text lookup) and airports__navaids-near (different resource).

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 geometry of the description ('within a radius of a point or UK postcode'), but no explicit when-to-use, when-not, or named alternative (e.g., use airports__search for name lookup, or navaids-near for navaids) is given. An agent can infer the intent but must decide on its own when this beats the sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond that by disclosing the billing model (free daily allowance, then per-call x402 charge) and enumerating returned 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 compact sentences, front-loaded with the returned data before the pricing note. No waste, though the pricing clause is somewhat tangential to describing the resource.

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 further explanation. The description covers what the tool returns and its cost model; the main gap is the absence of guidance on choosing it over sibling airport 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?

Schema description coverage is 100%: the single 'code' parameter is fully documented as accepting ICAO, IATA or OurAirports identifiers. The description adds nothing about the parameter, so the baseline 3 is appropriate given the schema carries the burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the resource and its returned attributes: runway length, width, surface, lighting and each end's identifier, heading and elevation. It distinguishes itself from siblings like airports__airport and airports__frequencies by focusing on runways, though it never explicitly contrasts itself with 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?

There is no when-to-use guidance. The only contextual detail is pricing ('Free within the daily allowance, then $0.001 USDC per call via x402'), which tells the agent about cost but not when to choose this tool over siblings like airports__airport or airports__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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description goes further with genuinely additive context: result ordering ('biggest first') and the pricing model (free within a daily allowance, then $0.001 USDC per call via x402). It does not describe pagination or behavior past the result limit, keeping it out of the top score.

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?

A single front-loaded sentence: core search behavior first, then optional filters, ordering, and pricing. Every clause carries information; nothing is redundant.

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. The description still supplies criteria, ordering, and cost, making it largely self-sufficient for a 5-param search tool; only pagination/limit-exhaustion behavior is left unaddressed.

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 and the baseline is 3. The description echoes the facets and clarifies their and/or combination logic, but adds no syntax, format, or default 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 (Find) plus resource (airports) and enumerates the search facets: name/town, country, type, scheduled service. The 'biggest first' ordering and text-based matching implicitly distinguish it from sibling airports__near (proximity) and airports__airport (single lookup).

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 'and/or' phrasing and 'optionally by type or scheduled service only' clarify which filters combine, which implies how to use it. However, it never states when to choose this over airports__near or airports__airport, nor any exclusions, leaving the when-to-use decision 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context not present in annotations: a metered cost model with a few free samples per day and $0.001 USDC per call via x402, which materially affects how often 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 short sentences with no waste, front-loading the resource and scope before the pricing caveat. 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-value details are unnecessary, and zero parameters plus strong annotations mean little else is required. The description covers scope and cost; the only minor gap is that it does not note any coverage limits or freshness/update cadence for the 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; this is the baseline 4 for a no-parameter 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 (London air quality forecast) and its temporal scope (today and tomorrow), so an agent immediately knows what data it returns. It does not use an explicit verb, and no sibling tool covers air quality, so differentiation is trivial rather than earned.

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 tool is the sole air-quality endpoint among the siblings, so there is no alternative to route against and no when/when-not guidance is needed or given. The temporal scope (today/tomorrow) is the only selection-relevant detail, leaving this at minimum viable.

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 beyond that: the data is 'live' and the tool is pay-per-call (free samples, then $0.001 USDC via x402) — practically important for an agent deciding whether to 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 tight sentences: purpose front-loaded, cost/availability second. Nothing wasted, though it is slightly terse given it is the solo definition of the tool's behavior.

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 needn't be described, and the single parameter is fully documented. Purpose, liveness and pricing are covered; the only omission is routing guidance relative to the plural sibling, which is minor for a one-param read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'id' parameter is documented as a 'BikePoint id'. The description only implies that the id selects one station, adding no format or sourcing detail beyond the schema. Baseline 3 is appropriate when the schema carries the load.

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（live bikes, e-bikes, empty docks）and scopes it to 'one station', which contrasts implicitly with its plural sibling london-transport__bike-points. Clear verb-and-resource framing, though it never names the list alternative to make the distinction 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?

No when-to-use guidance, prerequisites, or mention of the obvious alternative (bike-points for a full list). Usage is only inferable from 'at one station'. No exclusions or selection criteria are given.

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-annotation context: the x402 pay-per-call model, the per-call cost, and the daily free-sample allowance, 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 short sentences: the scope/payload first, then the cost model. Every clause carries information 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 not be described, and the scope plus cost model are covered. The only gap is the relationship to the singular bike-point sibling, which an agent selecting between the two would 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?

There are zero parameters, so the baseline is 4. The description correctly offers no parameter detail, as there is nothing to document, and does not confuse the reader with phantom inputs.

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 (every Santander Cycles docking station) with its payload (live bike and space counts), which is clear. However, it never distinguishes itself from the sibling london-transport__bike-point (singular), leaving the agent to infer that this is the bulk/list variant.

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 bulk scope implies when to use it (when you want all docks rather than one), and the pricing note gives practical context for calling it. But there is no explicit when-to-use or comparison against bike-point, so guidance 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, openWorld, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations do not: a metered pricing model (free samples then $0.003 USDC per call via x402), which 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 with zero filler: the core capability is front-loaded, followed by the input formats and the pricing caveat. 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 only two required parameters, full schema coverage, and an output schema handling return values, the description needs little more. It covers input formats and cost; it could note whether a departure/arrival time can be supplied, but as written it is adequate for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value beyond the terse schema descriptions ('Origin'/'Destination') by specifying that inputs may be postcodes, stop ids, or 'lat,lon' pairs. That is actionable format guidance the schema lacks.

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: planning/journey options between two places, and even enumerates the accepted origin/destination formats. It is clearly distinguishable from arrival/status siblings by domain, but never explicitly contrasts itself with them, 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?

Usage is implied by the name and the point-to-point framing, but there is no explicit when-to-use, no prerequisites, and no named alternative (e.g., stop-arrivals for a single stop). An agent can infer the use case but gets no 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 cover read-only/idempotent/open-world, so the description's job is to add beyond that, and it does: it discloses the metered pricing model (a few free samples/day, then $0.002 USDC per call via x402). That cost/rate-limit context is genuinely useful for an agent deciding whether to call, though the payment flow's failure modes are not described.

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 waste: the capability is front-loaded and the pricing constraint follows. Nothing extraneous.

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 single parameter is fully documented in the schema. Adding usage routing versus stop-arrivals/line-status would make it fully complete, but for a one-param read tool it is largely sufficient.

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 gives concrete line-id examples ("victoria", "elizabeth", "northern"), so the description carries no additional param burden. Baseline 3 is appropriate for a single fully-documented parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("arrival predictions") and a clear scope ("every stop on a line"), which implicitly separates it from the sibling stop-arrivals (single stop) and line-status (operational status, not arrivals). It does not name those siblings explicitly, so sibling differentiation is inferred rather than stated.

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 scope phrase "every stop on a line" implies when to reach for this over stop-arrivals or line-status, but there is no explicit when-to-use statement, no exclusions, 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 safety (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds genuinely non-structural behavioral context: a metered pay-per-call model with a few free daily samples and $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 sentences, zero filler, front-loaded with the purpose and followed by the cost constraint. Every clause (scope, cost, payment rail) 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 described, and annotations cover the safety profile. Purpose, scope, and the unusual payment requirement are all covered; only error behavior for an invalid line id is unaddressed.

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 'line' parameter already documents format with examples ('victoria', 'elizabeth', 'northern'). The description only adds the implied constraint that exactly one line is queried; baseline 3 is correct when the schema carries the parameter 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 verb+resource ('Live status and disruption') and scopes it to 'one line', which implicitly separates it from siblings like tube-status and mode-status that cover multiple lines or a whole mode. It stops short of naming those alternatives, so sibling differentiation is inferential rather than 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?

The single-line scope implies when this tool is appropriate versus the broader tube-status/mode-status tools, but no when-to-use or when-not-to-use guidance is stated. The pricing note is present but is not 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?

Goes beyond the annotations (readOnlyHint, idempotentHint, openWorldHint) by disclosing the commercial/rate-limit behavior: a few free samples per day, then $0.001 USDC per call via x402. That is genuinely useful context an agent needs before calling, though the return-shape behavior is left to the output 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 waste. The functional purpose is front-loaded and the cost/model detail follows. Nothing extraneous.

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 the missing mode vocabulary and cost model. The only gap is the lack of explicit routing versus the tube-status/line-status 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?

Schema coverage is 100% but the schema description is only the generic label 'Mode' with no enum. The description compensates by enumerating the valid values (tube, overground, elizabeth-line, dlr, tram, bus), which the schema does not provide — real added value beyond the structured field.

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 clear verb+resource: 'Live status of every line for a mode.' The scope ('every line for a mode') implicitly differentiates it from the single-line line-status and tube-only tube-status siblings, but the differentiation is left to inference rather than stated outright.

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 mode enumeration hints at when this tool applies, but there is no explicit guidance on when to pick this over london-transport__tube-status or london-transport__line-status. Usage is implied by the scope 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 and openWorldHint, so safety is covered. The description adds genuinely non-structured behavioral context — the free-sample quota and $0.002 USDC per-call x402 cost — which an agent needs before invoking. It stops short of describing freshness or coverage of the disruption data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences: purpose and identifier format first, commercial/rate-limit terms second. No filler, no restatement of the title, and the most important 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?

For a one-parameter read tool with an output schema (so return values need not be described) and full annotation coverage, this covers purpose, id format, and cost. The one gap is disambiguation from london-transport__road-status, which would help the agent pick correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single 'road' parameter ('Road id'), so the baseline is 3. The description goes beyond that by supplying concrete id examples ('a2', 'a406'), which clarifies the expected identifier format rather than merely restating 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 and scope ('Current disruption on a road corridor') and gives concrete road-id examples ('a2', 'a406'), which is enough for an agent to know what it returns. It does not distinguish itself from the sibling london-transport__road-status, which an agent could easily confuse for the same task.

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 exclusions, and no reference to the obvious alternative (london-transport__road-status). The only contextual note is the pricing model, which says nothing about when this tool is the right choice.

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 and non-destructive behavior, so the bar is lower. The description adds genuinely useful context beyond them: a free-sample allowance followed by a per-call charge of $0.001 USDC via x402, which tells the agent this call has a real cost and an auth/payment path.

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, with the scope stated first and the cost model second. Every clause carries information an 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?

An output schema exists, so return values need not be described, and there are no parameters to document. The one meaningful gap is routing relative to the road-disruption sibling, which the description never addresses.

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 4 applies. The description correctly avoids inventing parameter talk for a parameterless endpoint.

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: 'Live status of major London road corridors' is concrete and unambiguous. It does not, however, differentiate itself from the sibling london-transport__road-disruption, which an agent could easily confuse with it.

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 road-disruption, mode-status, or line-status, all of which report status-like data. The only usage-adjacent information is a pricing model, not a selection criterion.

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 behavior, so the safety profile is covered. The description adds valuable context annotations cannot: a free-sample quota and a paid x402 flow at $0.001 USDC per call, which tells the agent about cost and rate limiting 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 sentences, zero filler, and the front-loaded sentence describes the return content while the second carries the payment caveat. 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, return values need not be described, and the single parameter is fully documented in the schema. Purpose and payment behavior are covered; only explicit when-to-use/alternative routing 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 coverage is 100%, with the single 'stop' parameter documented as a NaPTAN StopPoint id and an example ('940GZZLUOXC'). The description adds nothing 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?

The description names a specific resource (a station) and enumerates the fields it returns (lines, modes, facilities, child stops), which lets an agent distinguish it from stop-arrivals, stop-search, and stops-near. It is clear but phrased as a noun list rather than a verb, so the action ('fetch details') is only implied.

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 use this tool versus alternatives like stop-search or stops-near, nor any prerequisites. The agent must infer usage purely from the returned-fields list.

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). The description adds genuinely new behavioral context the annotations do not carry: a free-sample quota and a per-call x402 payment of $0.002, 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 with zero waste: purpose front-loaded, 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 not be explained, and the one required parameter is fully documented. The only real gap is the missing routing guidance against line-arrivals.

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 stop parameter is documented with a NaPTAN example, so the schema does the heavy lifting. The description adds nothing about the parameter; 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: live arrival predictions scoped to a stop or station. This clearly separates it from line-status and mode-status siblings, but it never explicitly contrasts with london-transport__line-arrivals, which is the closest lookalike.

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 offers only commercial framing (free samples then $0.002 USDC via x402) and no when-to-use guidance. An agent choosing between stop-arrivals and line-arrivals gets no criteria from the text.

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 this as a safe, idempotent, open-world read, so the safety profile is covered. The description adds genuinely useful context beyond the schema: a free-sample quota and a $0.001 USDC per-call cost via x402. It stops short of describing result limits or matching 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 tight sentences: purpose front-loaded, then the pricing caveat. Nothing is wasted and the most decision-relevant information comes 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, and the description covers purpose and cost. It is nearly complete for a one-parameter search, with the only gap being the matching semantics of the query (exact vs partial).

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 parameter q is documented as "Name", so the schema carries the burden. The description's "by name" merely echoes the schema without adding syntax, matching mode (prefix/fuzzy/exact), or format guidance. 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 (Find) and resource (stations and stops) qualified by the search mode (by name). An agent can tell it apart from a detail lookup like london-transport__stop, but it never explicitly distinguishes itself from london-transport__stops-near, which is a genuine ambiguity.

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?

"By name" implies the usage mode and contrasts implicitly with the geo-based stops-near sibling, but there is no explicit when-to-use or when-not-to-use statement and no mention of the alternative. Usage is inferable, 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 readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful commercial context (a few free samples per day, then $0.002 USDC per call via x402), which functions as a quota/payment disclosure, but it says nothing about behavior once the free quota is exhausted or about result ordering/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 short sentences, front-loaded with the capability before the pricing note. Nothing is padded, though the billing sentence is secondary to the core description.

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 semantics. The description covers what the tool returns (stations/stops), the spatial constraint, and the cost model, leaving only sibling differentiation unaddressed.

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 and radius (metres, default 200) are already fully documented in the schema. The phrase 'within a radius of a point' only restates what the parameters convey, adding no format or edge-case detail beyond the schema. 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 concrete verb+resource and a spatial scope: 'Stations and stops within a radius of a point.' An agent can distinguish this geo-radius query from name-based siblings like london-transport__stop-search or london-transport__stop. It stops short of naming or contrasting 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?

The description gives no when-to-use guidance or alternatives. The second sentence is pricing/rate-limit information, not usage direction, so the agent gets no help choosing between this and stop-search or stop-arrivals.

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 non-destructive, so the safety profile is covered. The description usefully adds the metered-payment behavior (a few free calls per day, then $0.001 USDC via x402), which is real behavioral context an agent cannot get from the 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 tight sentences: purpose first, then cost model. Zero filler and the key facts are 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?

An output schema exists and annotations are rich, so the description needn't explain return values or safety. For a no-parameter live-read tool, purpose plus payment model is nearly enough; the missing piece is distinguishing it from the similarly named tube/line/mode status 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 (empty object schema), so by the rubric the baseline is 4. There is nothing for the description to clarify 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 (status) and resource (every Tube line) with the 'live' qualifier, so an agent knows it's a real-time feed. However, it does not distinguish itself from close siblings like london-transport__line-status and london-transport__mode-status, which sound like overlapping resources.

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 line-status or mode-status, nor any prerequisite or exclusions. The only usage-adjacent information is the free-sample/pricing note, which is a cost constraint rather than a selection 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 cover readOnly, idempotent, openWorld, and non-destructive, so the bar is lower. The description adds genuinely useful context beyond them: the pay-per-call x402 pricing/allowance model and the caveat '(whichever it measures)' signalling that not all sensors exist at every station and fields may be absent.

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, output scope front-loaded, and the pricing sentence earns its place by warning of a metered cost. Zero 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 no explanation, and annotations carry the safety profile. The one shortfall is the absence of any routing against the four sibling tide tools, which an agent would still need to resolve elsewhere.

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 both 'units' (metric|english) and 'station' (NOAA CO-OPS id) documented in the schema itself. The description adds no syntax, format, or default detail 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?

Names a specific resource set (water temp, air temp, wind, air pressure) and the scope (latest, reported at a station), which is clearly distinct from a sibling like water-level or predictions. It does not, however, explicitly contrast itself with those siblings, so an agent still has to infer the split.

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 never says when to pick conditions over predictions, station, stations-near, or water-level. The only conditional content is pricing ('free within the daily allowance, then $0.002 USDC'), which is cost guidance 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 cover readOnly, idempotent, openWorld and non-destructive traits, so the bar is lower. The description earns credit by disclosing the billing model (free daily allowance, then $0.002 USDC via x402) and the 7-day horizon, which are real behavioral facts absent 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 tight sentences with the core capability front-loaded and the pricing caveat second. No filler and no 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?

Output schema exists so return values needn't be explained, and annotations plus schema cover safety and parameters. The description adds the two things an agent can't get elsewhere: scope horizon and cost model.

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 the schema already documents days, datum, units, and station. The description restates the 7-day limit but adds nothing on datum or units of measurement, 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 verb+resource: predicted high/low tide times and heights, with a scope limit (up to 7 days from today). It distinguishes itself implicitly from tides__water-level via 'Predicted' vs observations, but never names a 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?

No when-to-use guidance and no alternatives named. An agent cannot tell from the text whether to use predictions, conditions, or water-level for a given question; only the word 'Predicted' hints at the future-facing case.

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 (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds genuinely new context: the free-tier allowance and the $0.001 USDC per-call x402 pricing, which materially affects whether an agent should call it. It does not describe result limits or what happens on zero matches, but the output schema covers the return shape.

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 purpose then the cost model, with no filler. Every clause carries information an 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?

With an output schema present, return values need not be explained, and the description covers purpose, filters, and the cost model. It is slightly thin on edge cases (no-match behavior, result caps) for a search tool, but nothing essential 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%, so both parameters are already documented ('station name contains' and '2-letter state'). The description only restates that they are combinable filters; that is baseline-correct but adds no new syntax or matching 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?

States a specific verb (search) and resource (NOAA tide stations) plus the filter dimensions (name and/or state). It is not identical to its siblings tides__station and tides__stations-near, but it never explicitly says how it differs from them, 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?

Searching by name and/or state is implied, and the cost caveat hints that this is a lookup call. However, there is no explicit when-to-use guidance versus tides__stations-near (proximity) or tides__station (single known station), 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 the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's real contribution is disclosing the access model: free within a daily allowance, then $0.001 USDC per call via x402. That payment/access requirement is exactly the kind of behavioral context 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 with no waste, and the functional content is front-loaded before the pricing note. The opening is a noun-phrase fragment rather than a full statement, which is a minor structural weakness but not verbose.

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 annotations carry the safety semantics. The description covers purpose and cost, leaving only the absence of sibling-routing guidance as a gap, which is already accounted for under usage guidelines.

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 in the schema as a NOAA CO-OPS station id. The description adds no syntax, format, or example 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?

The description enumerates what the tool returns for a station (location, time zone, products offered, tidal datums), which clearly identifies it as a station-metadata lookup. Combined with the title it is unambiguous, but it never states a verb and does not distinguish itself from siblings like tides__search or tides__stations-near.

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 named alternatives. The only contextual sentence concerns pricing, not selection between this and the other tides__ tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-structured behavior: nearest-first ordering and the billing model (free within the daily allowance, then $0.001 USDC per call via x402), which the agent cannot learn 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 dense sentences with no filler: the geographic scope and default radius come first, then the ordering and cost. Every clause carries information an 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?

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description adds the ordering and pricing context that structured fields lack; only the precise mechanics of the 'daily allowance' remain 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 description coverage is 100%, so lat, lng, limit and radius_km are already documented, and the description only restates the 50 km default that the schema already gives. The one addition beyond the schema is result ordering ('nearest first'), which is useful but minimal. 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 and resource: NOAA tide-prediction stations within a radius of a point, returned nearest-first. An agent can distinguish it from tides__station (single station) and tides__search, 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?

Usage is implied by the phrasing 'stations near a point,' which tells the agent this is the proximity lookup, and the pricing note hints at when cost applies. However, there is no explicit when-to-use/when-not guidance or routing to tides__station or tides__search for other cases.

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 and non-destructive semantics, so the bar is lower. The description adds genuinely new behavioral context: a free daily allowance followed by $0.002 USDC per call via x402, plus the fact that the payload includes the latest reading. It does not mention rate limits, latency, or data freshness beyond that.

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?

A single dense sentence that front-loads the resource and resolution before the pricing detail. No filler, though the pricing clause in the same sentence slightly crowds the core capability.

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. Cost and the hour window are covered; what remains thin is any hint about data recency/latency or how station ids should be sourced, which siblings like tides__search would supply.

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 four parameters and their defaults, making 3 the baseline. The description adds one fact not in the schema — the max of 72 hours — but nothing about datum choices, units, or station id format.

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: 'Observed 6-minute water levels' with the resolution and the inclusion of the latest reading. The word 'Observed' implicitly separates it from the sibling tides__predictions, but no sibling is 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?

No when-to-use guidance relative to tides__predictions, tides__conditions, or tides__station. The only contextual statement is a pricing/allowance note, which tells the agent about cost, not about 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new context the annotations omit: the pricing/quota model ('a few free samples a day, then $0.001 USDC per call via x402'), which materially affects whether and how 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 tight sentences: the first front-loads purpose and payload, the second adds the cost model. No filler, nothing redundant with 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?

A single-parameter lookup with an output schema, so return values need no description, and the annotations plus the cost note make it largely self-contained. The only residual gap is not indicating where a caller obtains a STATS19 index, which is a minor omission given the sibling tools cover searching.

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 'id' parameter is already documented in the schema. The description reinforces that the id is a STATS19 collision index, adding modest semantic value, but introduces no format example or source for obtaining the id, so it stays at the baseline 3.

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 ('One reported collision by its STATS19 index') and enumerates the returned attributes (date, time, severity, vehicles, casualties, road, conditions). This clearly distinguishes it from the spatial sibling uk-road-safety__near without needing to open 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?

The phrase 'by its STATS19 index' implies the caller must already hold an index, giving implied usage. However, it never names the alternative (uk-road-safety__near for proximity lookups) or states when this is preferred over it, so the routing guidance is inferred rather than explicit.

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

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

Annotations already cover the safe-read profile (readOnlyHint, idempotentHint, non-destructive), so the description's main added value is the pricing/rate-limit disclosure ('a few free samples a day, then $0.003 USDC per call via x402'), which is genuinely useful behavioral context an agent cannot get from the schema. It does not state what happens when results exceed pagination limits, but for a read-only aggregate call the disclosure bar is met.

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?

A single sentence enumerates the output dimensions first and the pricing model last, which is well front-loaded. It is dense but not padded; nothing here is filler, though the pricing clause could arguably live in tool metadata rather than the description.

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 a fully documented schema and an output schema present, the description only needs to cover scope, defaults, and cost. The five-year-default behavior is covered and output values need not be explained. The missing piece is routing guidance among the four sibling collision 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?

Schema description coverage is 100%, so both parameters (code = ONS local authority district code, year = one year only) are already documented. The description adds the useful semantic that the year parameter is optional and that omitting it produces a five-year total rather than an error, but adds no format or syntax detail beyond that.

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-implied resource (collision totals for a local authority district) and enumerates the dimensions of aggregation (severity, year, road class, speed limit, light, weather, surface, urban/rural). An agent can immediately tell this is an aggregate query over a district, distinct from the point/collision-level siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives no explicit when-to-use guidance and never mentions the sibling tools uk-road-safety__collision, __lsoa, or __near, which is exactly where guidance is most needed given four tools over the same dataset. The only decision-relevant hint is the 'five-year (or one-year)' phrasing, which implicitly signals the time-scope tradeoff.

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 safety is covered. The description meaningfully adds what the annotations do not: a metered pricing model (a few free samples per day, then $0.002 USDC per call via x402) and a bounded result set ('50 most recent'), both of which affect how an agent should budget and 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, front-loaded with the subject matter and time span before the commercial terms; nothing is redundant. The pricing clause is useful but slightly tangential to the tool's function, keeping it just short of a 5.

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-only tool with an output schema and safety annotations already covering the return contract, the description is close to sufficient. It discloses cost and result limits, but omits error behavior for invalid LSOA codes and any routing hint against its three 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?

Schema coverage is 100% for the single `code` parameter, so the baseline is 3, but the description goes beyond the schema by explaining what the parameter denotes — a 2021 LSOA, a neighbourhood of roughly 1,500 people — which tells the agent what geographic granularity it is requesting. It still does not describe the code's format or give an example.

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: collisions within a 2021 LSOA, with the temporal window (five years) and the result cap (50 most recent). The scope ('neighbourhood of ~1,500 people') implicitly distinguishes it from the local-authority sibling, but no sibling is named, so the differentiation is left 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?

There is no explicit when-to-use or when-not-to-use guidance and no reference to the alternatives (uk-road-safety__collision, __near, __local-authority). The pricing sentence describes cost, not the conditions under which this tool should be chosen over a broader collision query.

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, and the description adds genuinely new behavioral context: a five-year data window, the breakdown returned (totals by severity and year), and crucially the commercial constraints — a few free samples per day then $0.003 USDC per call via x402. Rate limits and cost are exactly the kind of trait 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 sentences, front-loaded with the core capability followed by the cost model; almost nothing is wasted. The first sentence is heavily packed with several clauses, which slightly hurts readability, but every clause conveys real 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 the return format need not be spelled out, yet the description usefully previews what comes back. Combined with annotations covering safety and the description covering cost and data window, an agent has enough to call it correctly; only the sibling-selection 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?

Schema description coverage is 100%, so the schema already documents lat, lng, year, limit, postcode and radius_m. The description restates the radius default/max but adds no syntax, format, or interaction detail (e.g. that year accepts one value only, or how postcode and lat/lng are prioritized). Baseline 3 applies 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?

The description names a precise capability: reported collisions within a radius of a UK postcode or point, with totals by severity/year plus recent collision detail. That is far more specific than the title and clearly scoped by radius geographies. It does not explicitly distinguish itself from siblings like uk-road-safety__lsoa (area-based) or uk-road-safety__collision (single record), 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?

Usage is implied by the geography model ('within a radius ... of a UK postcode or point') and a default radius is given, which tells an agent how to invoke it. However, there is no explicit when-to-use statement and no routing to alternatives such as the LSOA or single-collision siblings, 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.