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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so credit here goes to the added distinction that tracked buses carry an expected time and `delay_seconds` while untracked ones fall back to timetabled time with source `gtfs_scheduled`. That is genuine behavioral context beyond the structured fields, though no rate limits or auth requirements are mentioned.

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 question of what the tool returns, with no filler. The parenthetical is slightly dense but each clause carries distinct information.

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

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

With an output schema present, return format need not be explained, and annotations carry the safety profile. What is missing is coverage of the undocumented input parameters, especially the required `atcocode`, which leaves the definition only minimally adequate for a 4-parameter tool.

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

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

Schema description coverage is 0% for 4 parameters, so the description must compensate and largely does not. It explains the alternate values of `board`, but `atcocode` (the required identifier), `limit`, and `minutes_ahead` receive no explanation at all, leaving the agent to guess their format and units.

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

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

The description states a concrete resource and scope: 'What is leaving ... a bus stop', with the board='arrivals'/'both' variant spelled out. The word 'bus' implicitly separates it from the sibling rail_departures, though it never names or contrasts that 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?

It clarifies the board parameter's alternative modes (departures/arrivals/both), which is useful usage context, but gives no guidance on when to prefer this tool over siblings like live_buses or rail_departures. Usage is only implied by the tool name and resource.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuine behavioral detail beyond that: the current location is only returned 'if it is running,' which tells the agent to expect a nullable/conditional field. It does not mention rate limits, auth, or pagination.

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

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

Two sentences with no filler. The payload description (what you get back) is front-loaded, and the sourcing instruction for the parameter follows immediately.

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 enumerated. Given the single-parameter, read-only nature of the tool, the description covers what is returned and where to get the input; only identifier formatting and the not-running edge case are left implicit.

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

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

Schema description coverage is 0% and there is one parameter, so the description carries the burden of explaining trip_id. It does add real value by telling the agent where to obtain the ID, but gives no format, example, or constraint on the identifier itself.

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 returned resource concretely: every stop on a bus journey, its running days, and the current vehicle position. It implicitly distinguishes itself from siblings by naming bus_departures and live_buses as the sources of the trip_id rather than as competing lookups, though it never states the retrieval verb directly (e.g. 'get the full service for a trip').

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

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

It gives a clear actionable context: 'Take trip_id from bus_departures or live_buses,' which routes the agent to the prerequisite tools and therefore implies when this tool is appropriate. It does not state exclusions or what to do if the trip is not running beyond the conditional phrasing.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds useful domain context (coverage area, why `path` is more reliable) but says nothing about pagination via `limit`, what happens when all filters are omitted, or how multiple filters combine.

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?

Front-loaded with the resource and scope, then filtering options, then the path tip. Every sentence carries information, though the trailing parenthetical could be trimmed slightly.

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

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

The output schema exists, so return-shape explanation is not required. Still, for a nine-parameter, zero-optionality-required tool, the description leaves unit semantics, default behavior and filter-combination rules unspecified, which is a meaningful gap for correct invocation.

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

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

Schema description coverage is 0% for nine parameters, so the description must compensate and does so only for `path` (encoded polyline, sourced from plan_journey's leg_geometry) and loosely for lat/lon/radius, mode, operator and line. `limit`, `radius` units and `path_radius` remain unexplained in both places.

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

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

It states a concrete verb+resource ('Planned works, incidents and line status') and enumerates the covered transport modes and geography. However, it never differentiates itself from adjacent service tools like train_service, bus_service or rail_departures, so an agent must infer the boundary.

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

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

It gives explicit routing guidance for the path-vs-line choice ('line numbers repeat across towns, so this is more reliable than `line`'), which is genuinely actionable. It stops short of saying when to prefer this tool over siblings such as bus_service or live_buses, so the guidance is partial.

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, so the safety profile is covered. The description adds genuinely new behavioral facts: results are ordered nearest-first, each bus links to `trip_id`, `delay_seconds` is present only 'where tracked', and `radius` is capped at 10000 metres. It still says nothing about result limits or rate behavior, keeping it below 5.

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

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

A single tightly packed passage that front-loads the core query (buses near a point) before trailing details about radius cap, linkage fields, and filters. Every clause carries information; no filler.

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

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

With an output schema present and annotations covering the safety profile, the description only needs to add the query semantics, which it does well (ordering, linkage fields, radius cap, filters). The only gap is coordinate format/defaults, a minor omission for a 5-parameter spatial query.

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

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

Schema description coverage is 0%, so the description carries the burden and mostly delivers: it gives `radius` units (metres) and an upper bound of 10000, an example value for `line` ("52"), and the meaning of `operator` filtering. It leaves `lat`/`lon` conventions (likely WGS84) and the default radius implicit.

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

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

States a specific verb+resource with scope and ordering: buses on the road within a radius of a point, nearest first, each linked to its trip and delay. This clearly distinguishes it from siblings like nearby_stops/nearby_stations (stops, not vehicles) and bus_departures (scheduled departures, not live positions).

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: it notes you can filter by `line` or `operator`, which suggests the live-vehicle-lookup context, but it never states when to choose this over `nearby_stops`, `bus_departures`, or `bus_service`, nor any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety and idempotency profile is covered. The description adds the return-content hint (CRS codes) but says nothing about result ordering, how many stations are returned by default, or how proximity is ranked.

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 tight sentence that front-loads the resource and the radius constraint, then names the downstream consumer. 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?

An output schema exists, so return values need not be explained, and the read-only nature is covered by annotations. The only shortfall is that `limit`/ordering behavior is never surfaced, a minor gap for a simple proximity lookup.

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

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

Schema description coverage is 0%, so the schema titles alone must carry the load. The description clarifies `radius` (metres) and that lat/lon define a point, but `limit` is never mentioned, leaving one of four parameters undocumented.

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 (rail stations within a radius of a point) and names the value returned (CRS codes). The word 'Rail' implicitly separates it from nearby_stops, but it never explicitly contrasts the two, so an agent must 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 phrase 'with their CRS codes for rail_departures' hints at the workflow where this tool feeds rail_departures, which is useful context. However, there is no explicit when-to-use or when-not-to-use statement and no comparison against nearby_stops or search_places.

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

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds that results are ordered nearest-first, which is genuine behavioral context, but says nothing about radius defaults, result limits, or truncation 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, scoping and ordering front-loaded with no filler. Slightly dense back-half about atcocode/towards, but nothing wasted.

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

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

With an output schema present, return-value explanation is not required, and annotations cover safety. The gap is the undocumented `limit` parameter and the absence of any radius size guidance, leaving an agent to guess at result volume.

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

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

Schema description coverage is 0%, so the description must carry the load: it explains `radius` (metres) and implies the lat/lon point, but leaves `limit` (and its default of 20) completely unexplained. Partial compensation only.

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

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

The description uses a specific verb-and-resource framing ('Bus, tram and rail stops within `radius` metres of a point, nearest first') and names the ordering, which lets an agent recognize the tool distinct from nearby_stations. It stops short of explicitly contrasting itself with the 'stations' sibling, so 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?

It hints at a follow-on workflow by noting each stop has an `atcocode` for bus_departures and a `towards` direction, which implies this is the discovery step before departures. However there is no explicit when-to-use/when-not guidance and no statement of how it differs from nearby_stations or search_places.

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, so the bar is lower, and the description still adds real value: the geographic coverage boundary, the precise meaning of the 422 outside_coverage error, and the fact that live bus positions are included (implicitly real-time data). It doesn't discuss limits, result counts, or how live data ages, so it isn't exhaustive.

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?

Four tight sentences, front-loaded with the core purpose before the caveats. The parameter semantics are packed into clauses rather than prose padding; every sentence earns its place, though the density is high.

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 format need not be described, and the description covers coverage limits, error semantics, and the two non-obvious parameters. The main remaining gap is the undocumented limit and include_steps parameters for an 8-parameter tool.

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

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

Schema description coverage is 0% across 8 parameters, so the description must carry the load. It usefully documents datetime (ISO 8601, defaults to now) and arrive_by (interpret datetime as latest arrival), but says nothing about limit, include_steps, or the four required coordinate parameters, leaving half the surface undocumented.

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 (public transport journeys between two points) and enumerates what the result contains (walking, fares, live bus positions). This clearly separates it from siblings like live_buses, nearby_stops, or rail_departures, so an agent can route without opening the schema.

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

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

Gives a concrete when-not-usable condition: coverage is limited to South/West Yorkshire and West Sussex, and elsewhere returns 422 outside_coverage, explicitly clarifying that this means 'not covered' rather than 'no route'. It stops short of naming alternative sibling tools for uncovered areas or for adjacent needs.

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, and open-world behavior. The description adds useful behavioral detail about the data returned—expected times, platforms, cancellations, delay reasons, and station messages—which helps set expectations for the live National Rail feed.

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 what the tool does and then the key parameter detail. No filler or repetition.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. However, the description omits the semantics of limit and minutes_ahead and does not help an agent choose between this and sibling rail tools, leaving meaningful gaps.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains crs_code format with an example and board values, but leaves limit and minutes_ahead undocumented, which is only partial compensation for the coverage gap.

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

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

The description states a specific verb and resource: live trains leaving or arriving at a station, with expected times, platforms, cancellations, and delay reasons. It does not explicitly differentiate from siblings like train_service or disruptions, though the rail and station focus is clear.

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

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

The description gives clear context: use it for live departure or arrival boards at a station, and it explains the board parameter for switching to arrivals or both. It does not provide explicit when-not-to-use conditions or name alternative tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: results are ranked by size when names collide, and lat/lon converts the ordering to distance-from-point.

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

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

Three tight sentences, front-loaded with what the tool finds, then ranking behavior, then the optional distance-sorting hint. No filler.

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

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

An output schema exists, so return structure need not be described. Purpose, ranking and sorting are adequately covered; the remaining gap is the undocumented `limit` cap and the pairing requirement for lat/lon, which an agent may need to call correctly.

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

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

Schema coverage is 0%, so the description carries the burden. It explains the query format (full or partial postcodes, e.g. "S1") and the effect of lat/lon, but says nothing about the `limit` parameter or whether lat/lon must be supplied together, leaving half the parameters undocumented.

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

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

The description states a specific verb ("Find") and enumerates the resource types searched (towns, villages, postcodes, stops) plus the search axis ("by name"). This implicitly separates it from proximity-based siblings like nearby_stops and nearby_stations, though 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?

Usage is implied: it is the name-search tool, and the note about supplying lat/lon hints at how to prefer distance ordering. There is no explicit when-to-use versus when-not, and no alternative tool is referenced for name vs proximity lookups.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description's extra content (live status, expected/actual times, platform) is largely return-value detail that the output schema already carries, leaving only the mild conditionality of 'a train running today' as genuinely new behavioral context.

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

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

Three short sentences, front-loaded with the payload description and closing with the actionable parameter hint. No filler.

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

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

With an output schema covering the return shape and annotations covering safety, the definition is nearly self-sufficient for a one-parameter read tool. A brief note on behavior for trains not running today would close the remaining 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 0%, so the schema alone leaves `trip_id` undefined. The description compensates by stating where the value comes from (rail_departures), which is exactly the missing semantic an agent needs, though it doesn't describe format or validity constraints.

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 and scope: 'Every station one train calls at,' which tells an agent this enumerates the calling pattern of a single rail trip. It implicitly distinguishes itself from rail_departures (the originator of trip_id) and from bus_service, though it never draws that contrast 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?

It gives clear context: the required `trip_id` is obtained from rail_departures, effectively positioning this as a follow-up call. It stops short of explicit when-not-to-use guidance but the workflow is unambiguous.

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