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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only (though implied by 'Get'), what the return format is, or any rate limits or authentication requirements.

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, concise sentence that is front-loaded with the action and resource. It contains no unnecessary words and clearly communicates the tool's function.

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 no annotations, no output schema, and multiple similar siblings, the description is insufficient. It should clarify the distinction from get_line_status and possibly mention the return format or typical use case. The current description leaves gaps for an agent to understand when and why to choose this tool.

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

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

The tool takes zero parameters, so there are no parameter semantics to document. Baseline for 0 params is 4, as the schema is trivially complete. The description adds no parameter information, which 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 (Get) and resource (status) with a scope (ALL TfL lines at once). However, it does not differentiate itself from the sibling get_line_status, which likely returns status for a specific line. The 'ALL' and 'at once' hint at a distinction, but it's not made explicit.

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

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

No guidance on when to use this tool versus alternatives. The sibling 'get_line_status' is a clear alternative for single-line queries, but the description does not mention it or provide any context for 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the cross-tool dependency and a hard input constraint, but says nothing about whether data is live vs scheduled, pagination, rate limits, or error behavior for an unknown/closed station.

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 zero waste. The purpose is front-loaded and the critical constraint is escalated with a NOTE rather than buried.

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 simple 2-parameter read tool, the description covers the main failure mode (passing a station name). With no output schema and no annotations, it could say a bit more about what an arrival record contains, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the 'get this from get_station_info first' note on stationId. The description only reinforces the stationId rule and adds nothing about the optional line filter; baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource with scope: 'Get next train arrivals at a station.' The word 'train' implicitly separates it from the sibling get_bus_arrivals, so an agent can route without opening either schema.

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

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

The NOTE gives an explicit prerequisite ('First call get_station_info to get the stationId') and an anti-pattern ('Do not pass the station name directly'), which is genuinely actionable. It does not name alternative arrivals tools or say when not to fetch arrivals at all, so it stops short of a full when/when-not/alternatives treatment.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose that results are real-time/live, how fresh or how many arrivals are returned, or any rate-limit behavior, leaving the agent with only the one-line purpose statement.

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

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

A single front-loaded sentence with no filler, which is efficient. It is arguably under-specified rather than overly verbose, but nothing in it is wasted.

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

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

There is no output schema and no annotations, so the description should explain what an arrival record contains (line, destination, expected time) and any real-time caveats. For a live-data query tool, that gap leaves the agent unable to set expectations about the response.

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 stopCode parameter is fully documented in the schema, so the baseline is 3. The description adds no format hints or examples beyond what the schema already provides.

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

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

The description names a specific verb ('Get') and resource ('next bus arrivals at a bus stop'), which is clear enough to act on. However, it does not differentiate itself from the sibling get_arrivals, leaving the agent to infer the bus-vs-other-mode distinction from the tool name alone.

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

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

There is no guidance on when to use this tool versus get_arrivals, get_bus_route, or get_journey_time. No prerequisites or context (e.g., that the stop code must be known in advance) are stated.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: not whether the route is static or live, whether stops are returned in order, or how invalid bus numbers behave. It only implies a read operation via the verb 'Get'.

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 short sentence, front-loaded with the verb, with zero filler. It is efficient, though arguably over-terse given what is left unsaid.

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 simple one-parameter read tool with full schema coverage and no output schema, this is minimally adequate. It falls short on return-value expectations (stop ordering, route shape), which the agent would need for a 'full route' request.

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 an example format ('25, 396, 86'), so the single parameter is fully documented in structured data. The description adds no meaning beyond that, which is the correct baseline for a fully covered schema.

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

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

States a specific verb and resource ('Get the full route of a bus') and the word 'full' distinguishes it from partial-route siblings like get_bus_arrivals or get_line_status. It does not name any sibling explicitly, so differentiation is implicit 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?

No guidance on when to use this versus get_line_status, get_bus_arrivals, or get_station_info, and no mention of prerequisites or scope. The agent must infer context from the tool name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read operation, but the description says nothing about freshness of data, network breadth (all modes vs tube only), return shape, or any limits, leaving the agent to guess at 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?

A single ten-word sentence with the verb and scope front-loaded and no filler. Appropriately sized for a no-argument list call.

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

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

With no output schema, no annotations, and no parameters, the description is the only information source, yet it does not say what a 'disruption' entails (severity, affected lines, reason) or the data's freshness. Adequate to invoke, but thin for an agent needing to interpret or route results.

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 document beyond what the empty schema already shows. Baseline 4 applies; no parameter-level meaning is missing because none exists to convey.

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 (Get) and resource (disruptions) with a scope qualifier ('all current' on the TfL network). The word 'current' implicitly separates it from the sibling get_planned_works, but the description never names or mentions planned works explicitly, so the differentiation remains inferential.

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: 'current' suggests real-time status rather than planned/upcoming works, which nudges the agent away from get_planned_works. There is no explicit statement of when to prefer this tool over get_line_status or get_all_lines_status, and no exclusions 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?

With no annotations provided, the description carries the full behavioral burden, and it discloses almost nothing: it doesn't say whether the fare is a single value or a set (peak/off-peak, adult/child), what currency or units apply, whether a travel time or date affects the result, or whether it fails for unconnected locations. For a lookup tool with zero annotation coverage this is a notable gap.

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 with no filler or redundancy. It is efficient, though its brevity is partly under-specification rather than disciplined concision.

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?

There is no output schema and no annotations, so the description is the only place an agent could learn what a fare result looks like or when the call is valid. It omits response shape, currency, and any fare-type variance, leaving the tool under-explained for a domain where fares vary by time and passenger type.

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 'from' and 'to' are already documented as starting location and destination. The description's phrase 'between two locations' reinforces the schema but adds no format details (station IDs vs names, disambiguation) beyond it, making the baseline 3 correct.

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 ('Get') and resource ('the fare') and scopes it to 'a journey between two locations', which is unambiguous on its own. It does not, however, name or contrast itself with any sibling (e.g. plan_journey, which may also surface cost information), 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?

There is no when-to-use guidance, no statement of prerequisites (such as requiring a valid station pair or a travel date), and no mention of alternatives. The only usage signal is the implicit requirement that both locations be supplied.

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

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

No annotations are provided, so the description carries the full burden and adds almost nothing: it doesn't say whether the time is real-time or scheduled, whether disruptions are factored in, what units are returned, or whether it covers buses/trains. For a lookup whose value hinges on those traits, this is a significant gap.

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 with no filler. Nothing is wasted.

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

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

With no output schema and no annotations, the description should at minimum describe what the returned time represents (units, mode, real-time vs planned). It also fails to position the tool against plan_journey, so an agent lacks enough to invoke it confidently in this crowded transit toolset.

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 both parameters are documented as 'Starting location' and 'Destination'. The description only restates 'two locations' without adding format hints (station names, codes, coordinates), so the baseline 3 applies.

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

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

States a specific verb and resource: 'Get the fastest journey time between two locations'. It is clear what the tool returns and requires two endpoints, but it never distinguishes itself from the sibling plan_journey, which an agent could easily pick instead for the same query.

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

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

There is no guidance on when to use this rather than plan_journey, get_fare, or get_arrivals. The description gives no prerequisites, no transport-mode context, and no exclusions, leaving routing entirely to inference from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond 'current' — no freshness/live-vs-cached semantics of 'current', no rate limits, and no indication of what the status result contains. 'Get' implies a read, but that is the extent of the disclosure.

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

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

A single efficient sentence that front-loads the action and resource with no filler. It is appropriately sized, though the parenthetical examples are partly redundant with the schema.

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

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

For a one-parameter read tool with no output schema, the description is minimally adequate but leaves the return shape and the meaning of 'current' unexplained. It does not round out the definition with the behavioral context that missing annotations would otherwise require.

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 already lists example values ('elizabeth, central, jubilee, dlr...'), so the baseline is 3. The description's mode list (tube, DLR, Elizabeth line) marginally reinforces accepted inputs but adds no format or case-sensitivity 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 ('get') and resource ('current status of a specific TfL line'), and the word 'specific' implicitly contrasts with the sibling get_all_lines_status. The parenthetical names supported modes, making the scope concrete. It does not explicitly name the alternative, but the resource is unambiguous.

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

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

Usage is only implied: an agent can infer this is the single-line lookup versus get_all_lines_status for every line, but the description never states when to prefer one over the other or any prerequisites. No exclusions or alternatives are named.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only lookup but says nothing about result count, search radius, ordering, or whether it requires a valid UK postcode format.

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 with zero filler. It is efficient, though arguably under-specified rather than genuinely concise.

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 no output schema and no annotations, the definition covers the core action but leaves result shape, proximity semantics, and sibling routing 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?

One parameter with 100% schema description coverage ('UK postcode e.g. E12 5JB'), so the schema already fully documents the input. The description adds no format, radius, or default-value semantics beyond what the schema states, making the baseline 3 correct.

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?

Specific verb ('Find'), specific resource ('TfL stations') and a stated scope ('near a postcode'). It is distinguishable from status/journey siblings, though it never clarifies how it differs from the closer sibling search_station.

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 statement, no exclusions, and no alternatives named. The phrase 'near a postcode' only weakly implies the input condition; an agent gets no help deciding between this and search_station.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a safe read and 'upcoming' gives a useful temporal scope, but there is no disclosure of return shape, freshness of data, authentication needs, or pagination behavior for what is presumably a large list of works.

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 efficient sentence with the resource front-loaded and no filler. It is appropriately sized, though the extreme brevity is partly the cause of the transparency gaps rather than a virtue.

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

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

With no annotations, no output schema, and no parameters, the description is the only documentation. It covers the bare purpose adequately for a trivial no-arg read, but leaves the agent without any indication of what the response contains or how it differs from sibling disruption tools.

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

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

The tool takes zero parameters, so schema coverage is effectively complete and there is nothing for the description to clarify. Baseline 4 applies for a no-arg tool; no syntax or format details are needed.

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

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

The description states a specific verb (Get) and resource (upcoming planned engineering works) with a scoping qualifier (TfL lines). It is clear on its own, but it never contrasts itself with the closest sibling, get_disruptions, which an agent could easily confuse with planned works.

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

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

There is no guidance on when to use this tool versus get_disruptions or get_line_status, nor any mention of prerequisites or context. The agent must infer the intended use entirely from the one-line purpose.

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

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

No annotations are provided, so the description carries the burden. It discloses the payload contents (zone, transport modes) and is a read-only lookup by nature, but does not state whether it requires an exact station name, handles ambiguous inputs, or what happens on a miss.

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 11-word sentence, front-loaded with the verb and resource and immediately followed by the returned fields. No filler.

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

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

For a 1-parameter read tool with full schema coverage and no output schema, the description covers purpose and payload. It is nearly complete, though it could note whether the input is an exact name or fuzzy match.

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 already includes examples. The description adds no syntax, format, or disambiguation details beyond the schema, 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 specific verb+resource ('Get information about a station') and specifies the payload ('zone and transport modes'). It is distinguishable from siblings like search_station or get_nearby_stations, though it does not explicitly name 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?

Usage is implied — use to retrieve static details about a known station. No explicit when-to-use vs when-not-to-use guidance or alternatives (e.g., search_station for name lookup, get_nearby_stations for proximity) are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It does not say what modes are considered, whether results are real-time or scheduled, whether alternative routes are returned, or whether the call is read-only and rate-limited.

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 short sentence, front-loaded with verb and resource, with no filler. Everything present 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 no annotations and no output schema, the description should explain the nature of the result (route options, modes, steps). It leaves an agent unable to predict the response shape for a fairly complex planning operation.

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 each parameter already documents format and examples (postcodes, HHMM), so the baseline of 3 applies. The description adds no meaning beyond the schema, not even clarifying that 'time' is a departure time.

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 (plan) and resource (journey) plus the provider (TfL), which distinguishes it from siblings like get_journey_time and get_line_status. It does not explicitly contrast with those siblings, so it falls short of a 5.

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

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

The phrase 'plan a journey between two locations' implies the usage context, but there is no explicit when-to-use versus get_journey_time or get_disruptions, and no prerequisites (e.g., valid station names, TfL coverage).

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose matching behavior (exact vs partial), result cardinality, or whether the search is case-insensitive, all of which matter for a search tool. It also never confirms this is a read-only operation.

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 efficient sentence with no filler, front-loaded with the verb and resource. It is arguably too terse rather than too long, but nothing is wasted.

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

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

For a one-parameter read-only search with no output schema, the definition is minimally viable. It leaves return format, matching semantics, and routing against get_station_info unaddressed, which an agent would benefit from knowing.

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 query parameter already carries examples ('Seven, Kings Cross, Canary'). The description adds no additional meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Search) and resource (station) scoped by name, which is clear and actionable. However, it does nothing to distinguish itself from sibling get_station_info, which an agent could reasonably confuse it with when looking up a named station.

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

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

There is no guidance on when to use this versus get_station_info or get_nearby_stations, nor any mention of what happens when the query matches nothing. Usage is only implied by the tool name itself.

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