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

No annotations are provided, so the description carries the full disclosure burden. It does state that realtime delays are included when available, which is useful behavioral context beyond a plain listing, and the 'when available' hedge is honest. However, it does not describe ordering, response shape, or how cancellations are surfaced, so it is adequate but not rich.

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 action-first sentence with no filler. It efficiently adds scope ('at a stop'), clarifies accepted location kinds ('station or platform'), and includes the realtime behavior without bloating 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?

For a low-complexity, read-only arrival lookup with full parameter coverage in the schema, the description plus schema is sufficient for an agent to invoke the tool correctly. The only notable gap is the lack of explicit differentiation from next_departures, but the term 'arrivals' already narrows the use case enough that this is a minor omission.

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 every parameter already has a meaningful description and the baseline is 3. The tool description adds no parameter-level detail beyond the phrase 'at a stop', and relies on the schema for count, line_id, from_datetime, and data_freshness semantics.

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

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

The description names an explicit action ('List') and resource ('next arrivals at a stop'), and the word 'arrivals' distinguishes it from the sibling next_departures without needing to open either schema. It also adds realtime delay behavior, making the tool's scope unmistakable.

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 stop-based wording implies this tool is for upcoming arrival boards at a known stop, but it never explicitly states when to prefer it over next_departures, stop_schedules, or plan_journey. With several closely related siblings, a brief exclusion or alternative note would materially improve decision-making.

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 present, so the description bears the full burden of disclosing behavioral traits. It does not explicitly state that the operation is read-only, safe, or free of side effects, leaving this crucial information implicit.

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

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

The description is a single, well-structured sentence that conveys the essential purpose without superfluous words. It is concise and easily scannable.

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, so the description should at least hint at the return format or fields. It does not, nor does it mention any error conditions, timezone handling, or other contextual details that would help an agent fully understand the tool's behavior.

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 all parameters having descriptions, so the baseline is 3. The description adds no additional semantic depth 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 clearly states the tool's function: listing next departures from a stop, with realtime delays when available. It is specific and unambiguous about the resource and the information provided.

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

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

The description does not provide any guidance on when to use this tool versus alternatives such as next_arrivals or stop_schedules. Without explicit differentiation, agents may struggle to select the appropriate tool in a broader 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?

No annotations are provided, so the description carries the burden. 'List' clearly indicates a read-only query with no side effects, which is appropriate for a simple listing tool. Still, it does not disclose result ordering, response shape, or any access/rate considerations, though these are less critical for a low-risk query.

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 filler: the first is action-oriented and front-loaded with the operation and scope, and the second adds a concrete use case. 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?

For a simple geospatial listing tool with a fully self-documenting schema, the description conveys the essential operation and intended use. The only notable gap is that there is no output schema and the description does not specify result fields or ordering, but this is a minor limitation for such a straightforward 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 100%, with all five parameters documented including defaults and bounds. The description adds only the concepts of 'coordinate' and 'radius,' which map onto lat/lon and distance, so it adds no meaning 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 opens with 'List public-transport stops and POIs within a radius of a coordinate,' giving a specific verb, resource, and query geometry. This clearly distinguishes it from text-search siblings like search_places and search_pt_objects because the search is coordinate- and radius-based.

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 second sentence, 'Useful to find the nearest station to a location,' provides an implied use case and suggests when this tool fits. However, it does not explicitly compare against alternatives such as search_places or search_pt_objects, nor does it state when not to use this tool.

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 explicitly describes what the tool returns (legs, times, transfers, disruptions) and clarifies the behavioral difference between soft preferences (prefer/avoid_lines) and hard exclusion (forbidden_uris). It stops short of describing edge cases or error behavior, but the core computational behavior is transparent.

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 sentences, front-loaded with the primary function, and every sentence adds information: what it computes, what it returns, and how to express preferences/exclusions. No filler or repetition of schema details.

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 complex (10 params, no output schema) and the description covers the main outcome and the most nuanced parameter behavior. It doesn't explain defaults like datetime=now, but the schema handles that. The return shape is sufficiently described for an agent to understand what it will receive.

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 100% schema coverage, baseline is 3. The description adds value by explaining the exact semantics of prefer_lines/avoid_lines vs forbidden_uris, which the schema only hints at, and confirms that max_nb_journeys caps the result set. This goes beyond the schema's field-level descriptions.

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

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

The description opens with a specific verb ('Compute'), a precise resource ('public-transport journeys between two points'), and characterizes the routing as 'multi-modal door-to-door'. The return payload is spelled out (itineraries with legs, times, transfers, disruptions), which clearly separates this journey-planning tool from sibling schedule/stop endpoints.

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

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

The description implies the tool is for point-to-point journey planning but never states when to choose it over siblings like next_departures or stop_schedules. It gives no explicit when-not or alternative routing. The parameter guidance (prefer_lines vs forbidden_uris) is a usage guideline for the tool's own options, not for 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?

The description discloses that the output is heavier, which is a behavioral characteristic. However, since no annotations are provided, it lacks explicit statements about side effects or errors, but for a read-only query tool this is adequate.

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

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

The description is concise, two sentences, with useful parenthetical notes. Parameter descriptions are also succinct and 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?

The tool description covers its purpose, usage relative to alternatives, and output size. It doesn't include an example or output format, but that is not essential for such a simple query tool, so it's reasonably complete.

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

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

All parameters are described in the schema, and the description adds extra context such as how to find the id and that items_per_schedule defaults to 5 to keep output small, going beyond basic schema.

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

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

The description clearly states the tool provides a full timetable grid for a line or route, distinguishing it from stop_schedules and terminus_schedules. The verb is implicit but the purpose 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?

It explicitly instructs to prefer stop_schedules for single-stop queries, providing clear when-to-use guidance relative to 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It usefully discloses that results are object ids usable as from/to or stop_id, and that the input is free-text. It does not describe ranking, result shape, or type-default behavior, but the core non-obvious behavior is covered.

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 action and scope are front-loaded, and the second sentence adds the most important integration detail about returned ids. Every word earns its place.

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

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

For a search-style tool with fully documented parameters and no output schema, the description is nearly complete: it names supported entity types, input style, and the downstream use of returned ids. It is only slightly incomplete in not clarifying how results are ordered or how it differs from the sibling search_pt_objects.

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 query, count, and types with good descriptions. The description adds downstream context about how ids are consumed, but it does not add meaning beyond the schema for the parameters themselves, 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 names a specific verb ('Geocode / autocomplete') and a clear resource scope ('stations, addresses, POIs and cities'), and explains that returned object ids feed other tools. This makes the purpose immediately distinguishable from siblings like search_pt_objects or places_nearby.

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 implies when to use the tool: for free-text place search before calling plan_journey or departure/schedule tools. However, it does not explicitly mention alternatives or explain when to prefer search_pt_objects over this tool, leaving some routing 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?

With no annotations, the description carries the burden; it does disclose the core behavior (search by name, return ids) and integration purpose. It omits edge behavior like ordering, match semantics, empty-result handling, or count limits, so it stops at basic transparency.

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 first sentence defines the operation and scope, and the second gives concrete downstream usage. Every phrase earns its place.

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

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

For a simple three-parameter search with full schema coverage, the description supplies the missing links: what ids are for and how results feed into other tools. It does not define the response shape, but 'return their ids' plus the schema is sufficient for this complexity.

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?

Input schema already documents all three parameters, and the description adds little per-parameter detail beyond the same examples already present in the schema ('metro 14', 'RER A'). The downstream line_id use is useful context but not new parameter semantics, 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 precise action ('Find public-transport objects by name and return their ids') and enumerates the object types searched, which separates it from sibling search_places/places_nearby. It also anchors the result with the 'metro 14' → 'line:...' id example.

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?

Tells the agent exactly when to invoke it: resolving a named PT line to an id for next_departures/stop_schedules, or for blocking lines/modes/networks in plan_journey. It does not name alternate tools or include exclusions, but the PT-object scope makes the choice clear.

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

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

With no annotations, the description carries the full burden of explaining behavior. It does add useful context by saying results are grouped by line and route and contain next departure times. However, it does not mention whether there are side effects, auth requirements, response format details, or how filtering inputs affect the result beyond what the schema states.

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

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

The description is a single dense sentence that front-loads the core behavior and grouping semantics. It avoids filler and meaningfully expands on the title without being 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?

The description gives enough to understand the general purpose, especially the 'grouped by line and route' detail. However, there is no output schema and the description does not specify the exact response fields, how items_per_schedule affects each group, or how this tool should be chosen over next_departures. An agent could still be uncertain about the precise return shape.

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 has a helpful description (e.g., stop_id source, from_datetime default, data_freshness meaning, items_per_schedule bound). The tool description adds no parameter-level meaning 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?

The description clearly identifies a specific resource ('timetable at a stop') and the key behavior ('next departure times' grouped by line/direction). It is specific enough to understand the tool's function, though it does not explicitly distinguish it from siblings like next_departures or route_schedules.

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 stop_schedules versus related tools such as next_departures, route_schedules, or terminus_schedules. The description states what the tool returns but does not provide selection criteria, exclusions, or alternative conditions.

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 burden. It clearly describes the data returned (grouped by terminus, max upcoming times per line/direction) and the effect of data_freshness (realtime vs base_schedule). It does not explicitly state that the operation is read-only, but the nature of a schedule query makes this implicit.

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

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

The description is concise, consisting of two sentences that deliver the core purpose, required inputs, and a helpful default note. No unnecessary words 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?

Given the moderate complexity (5 parameters, no output schema), the description sufficiently explains why this tool exists and how to use it. It lacks an explicit output format description or differentiation from related tools, but the station-display analogy and parameter hints cover most needs.

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 schema descriptions are comprehensive and cover all parameters (100% coverage). The description adds meaningful context about the items_per_schedule default and the necessity of resolving line_id through search_pt_objects, going slightly beyond the schema alone.

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

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

The description clearly states the tool's purpose: a departure board for a specific line at a stop, grouped by terminus, exactly what a station display shows. It also specifies the required inputs (stop and line) and how to obtain 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?

Provides explicit guidance to resolve the line ID via search_pt_objects and notes the requirement for both stop and line. It also mentions the default for items_per_schedule to manage output size. However, it does not compare usage to sibling tools like next_departures or stop_schedules.

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