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

Annotations already declare the operation read-only and idempotent, so the description does not need to repeat those. It adds useful context by calling the board 'live' and clarifying that direction is interpreted as origin, which helps distinguish arrival semantics from departures. Beyond that, no additional behavioral traits such as pagination or data freshness are disclosed.

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 concise sentence with no filler and is easy to parse. However, the brevity comes at the cost of missing parameter and usage details, so it is under-specified rather than optimally 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?

With five parameters and a low schema coverage, the description should provide more context than it does. The pointer to db_departures helps, but the description still leaves key invocation details such as time window, format, rail-only filtering, and when-to-use semantics to be inferred.

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 only 40%, and the description does not compensate by explaining minutes, format, rail_only, or station. The phrase 'same shape as db_departures' may hint at output structure, but it adds little meaning to the actual parameters and leaves several fields underspecified.

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 the tool as a live arrival board and distinguishes it from the sibling db_departures by adding 'direction = origin'. However, it relies on a noun phrase rather than a specific action verb like 'list' or 'retrieve', so it is clear but not maximally 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?

There is no guidance on when to use this tool versus alternatives. The reference to db_departures implies a relationship, but it does not state when arrivals are appropriate, when departures should be used, or any exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and repeatability. The description adds useful behavioral context: results are organized by discrete time bands, include the applicable connection, and are most meaningful for long-distance advance bookings. It does not contradict the annotations.

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

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

The description is compact and front-loaded with the core behavior, then gives a usage cue and an applicability caveat. The opening German word 'Bestpreissuche' is somewhat redundant and could confuse an English-only agent, but the rest of the description 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?

The core behavior, use case, and a practical limitation are clear, and the output schema covers return shape. However, with eight parameters and very low schema coverage, the description does not compensate for missing guidance on optional parameters, station input format, or how filters like regional_only affect the search.

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 only 13%, and the description provides no parameter-level guidance beyond the implicit from/to/date purpose. Optional parameters such as bahncard, first_class, children_ages, and regional_only are left entirely unexplained in both the description and 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?

The description states a specific operation: find the cheapest available fare in each time band of a day, including the connection it applies to. This clearly distinguishes it from sibling tools like db_journeys or db_departures, which focus on journey listings or departures rather than cheapest fares by time band.

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 explicitly says to use this tool for 'when is it cheapest to go' and notes it is typically only meaningful for long-distance routes booked in advance. However, it does not explicitly name alternatives or state when not to use this tool versus sibling tools like db_journey_offers.

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 adds meaningful behavioral context beyond the readOnly/idempotent/openWorld annotations: data is live and delay-aware, platforms are real-time with a platform_changed flag, and cancellations/disruptions are surfaced. This complements the annotations and does not contradict them. It does not discuss data freshness limits or empty-result behavior, but the live qualifier covers the key trait.

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?

One front-loaded sentence states the purpose and enumerates the important output fields without redundancy. Parentheticals such as 'real-time, with delay' and 'real-time, platform_changed flag' are compact, and the journey_id cross-reference is a useful single mention.

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 rich input schema, the safety annotations, and the presence of an output schema, the description fills the remaining gap by specifying live/real-time behavior and the link to db_trip_details. Nothing needed to invoke the tool correctly 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 80%, so the schema already explains when, format, minutes, station, and rail_only. The description focuses on output fields rather than adding parameter-level semantics, and with high schema coverage it does not need to compensate. The journey_id reference is about linking to db_trip_details, not about parameter meaning.

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

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

The description clearly identifies a live departure board and enumerates the data it exposes: time with delay, line, destination, platform with platform_changed, cancellation, disruption notes, and journey_id. It is unambiguous about the resource, but it lacks an explicit verb like 'retrieves' and does not directly contrast itself with db_arrivals or db_journeys.

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?

Intended use is only implied by 'Live departure board' and the real-time departure fields. The description does not explicitly say when to use this tool instead of db_arrivals or db_journeys, nor does it state exclusion criteria. The reference to journey_id for db_trip_details hints at downstream usage but not at tool selection.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds useful behavioral context: fares are 're-checked live' and are informational only, not a booking. This goes beyond the structured annotation data without contradicting it.

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

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

Three purposeful sentences: scope and fare types first, usage trigger second, informational caveat third. No filler, and 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 5-parameter tool with an output schema and safety annotations, the description is largely complete: it identifies the required recon_token, explains sequencing, and sets expectations about live pricing and non-booking. The only notable gap is that it does not explicitly distinguish itself from db_best_price, but the wording 'all fares' vs 'best price' mostly covers that.

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 only 40%; only recon_token and bahncard get explicit descriptions. The description reinforces that recon_token comes from a db_journeys result and mentions 'class', which loosely maps to first_class, but it does not compensate for the undocumented adults, first_class, and children_ages parameters. Parameter semantics remain mostly left to inference.

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 and resource: it returns all fares for ONE specific connection, with concrete fare types (Super Sparpreis, Sparpreis, Flexpreis, regional day tickets) and includes price and class. This distinguishes it from journey search and from a best-price-only tool.

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

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

The description explicitly says to use it after db_journeys when the user asks 'how much' or 'cheapest ticket', which gives clear invocation context. It also states prices are informational and not a booking, but it does not explicitly name or exclude the alternative db_best_price.

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?

Beyond readOnlyHint, openWorldHint, and idempotentHint, the description discloses live bahn.de data, real-time delay notation ('(+7)', '(+1d)'), real-time platforms with `*_platform_changed`, cancellations, and the meaning of `alternative` as DB's re-route around a disruption. This adds substantial behavioral context that annotations alone do not provide.

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 first sentence is a strong front-loaded purpose statement. The second is a dense but purposeful field glossary using backticks and clear separators. It is long, but nearly every clause adds operational meaning for a complex output, so there is minimal waste.

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

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

For a 17-parameter tool that already has an output schema and annotations, the description focuses on what structured data cannot express: real-time semantics, delay/platform-change notation, follow-up token usage, and the `alternative` reroute flag. Nothing essential for invoking the tool correctly is missing.

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

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

Schema coverage is 82%, so the baseline is 3. The description adds only marginal parameter insight: price is 'None with Deutschlandticket' and depends on travellers/BahnCard, which is largely already captured in the schema descriptions. It does not meaningfully clarify the remaining input parameters beyond what the schema already documents.

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

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

The description opens with a specific verb+resource: 'Plan train connections between two stations with live bahn.de data.' It clearly distinguishes itself from station-board siblings like db_departures and db_arrivals by emphasizing origin-to-destination journeys, and it references downstream sibling tools (db_journey_offers, db_trip_details), making its role in the tool family unambiguous.

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

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

The first sentence gives clear context: this tool is for planning train connections between two stations. It does not explicitly enumerate when-not-to-use alternatives such as db_departures, db_arrivals, or db_best_price, but the description's focus on connections plus the recon_token/journey_id handoffs provides partial routing guidance. This is clear context without formal exclusions.

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

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

Annotations already cover readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is established. The description adds that the returned bahn.de id is usable in every other tool, which is useful context, but it does not disclose behavior like sorting, pagination, or filter defaults. No contradiction with annotations.

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

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

A single sentence with no redundancy: the core purpose is front-loaded, and the chaining detail about the returned id is valuable and compact. 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 moderately simple tool with 5 parameters and an output schema, the description is adequate but leaves gaps around optional parameters like radius_m, max_results, and rail_only. The output schema covers return fields, but the description doesn't explain how these optional parameters shape 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?

Schema description coverage is only 20%, yet the description only explains that latitude/longitude form a 'GPS position'. It does not add meaning for radius_m (units, default), max_results (cap), or rail_only (beyond the schema's existing one-line description). The description fails to compensate for the schema's low coverage.

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

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

The description states a precise verb and resource: 'Stations and stops around a GPS position — 'stations near me''. This clearly differentiates it from sibling db_search_station (name-based lookup) and explains the key output fields including the chaining id.

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 'around a GPS position' implicitly tells an agent when to use this tool, but it never explicitly names alternatives or states when not to use it. The cross-tool id note guides downstream usage, not tool selection.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety is covered. The description adds useful behavioral context beyond those annotations by detailing the return fields (name, EVA number, products, full bahn.de id) and the fact that the returned id is accepted by other tools. This gives the agent actionable integration knowledge, though it does not touch on limits, sorting, or error 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?

Three sentences, each earning its place: the core action, the precise usage condition, and the return-value interoperability detail. There is no redundant repetition of the title or schema, and the most important scoping rule is front-loaded immediately after the action statement.

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 has strong annotations, a 100% documented schema, and an output schema, so the definition does not need to re-explain structured data. The description adds the selection criterion and cross-tool compatibility context, making it complete for an agent to decide when and how to invoke 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?

Schema description coverage is 100%, so the baseline is 3; the schema already explains both 'query' and 'include_stops' with examples. The description reinforces that the query is a name/fragment lookup and frames it as a disambiguation step, but it does not add new parameter-level 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 begins with a specific verb and resource: 'Find Deutsche Bahn stations by name.' It clearly differentiates this tool from its siblings by explaining that the other tools accept plain station names directly, so this tool is specifically for ambiguous or rejected names. The purpose is immediately obvious and not a tautology.

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 explicit when-to-use guidance: 'Call this only when a name is ambiguous or another tool rejected it.' It also states the alternative clearly—'the other tools accept plain station names directly'—so an agent knows exactly when to avoid this tool. This is exemplary usage routing.

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

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

Annotations already carry readOnlyHint, openWorldHint, and idempotentHint. The description adds the important detail that the platform and sectors are real-time, which reinforces the open-world nature, and it narrows applicability to ICE/IC/EC. No contradiction with annotations.

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

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

The description is two efficient sentences. Core purpose is front-loaded, and the use case and availability restriction each add necessary selection information without filler.

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

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

An output schema exists, so return-value details are covered elsewhere. The description covers purpose, domain, constraints, and a concrete use case. It does not explicitly contrast with alternatives, but given sibling names and context signals, the selection boundary is clear enough.

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 three parameters have schema descriptions, so the baseline is 3. The description adds meaningful constraints beyond the schema: it clarifies that 'train' must be an ICE/IC/EC long-distance service, and ties 'station' and 'when' to the departure context at that station.

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 exactly what the tool provides: coach order and platform sectors (A–G) for 1st class, bistro, bike, and quiet coaches, plus the real-time platform. It also explicitly scopes to ICE/IC/EC trains, which clearly distinguishes it from sibling tools about journeys, departures, or offers.

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 identifies the intended user question ('where do I stand on the platform') and gives a clear exclusion ('not available for regional trains'). It does not name specific sibling tools as alternatives, but the context is sufficient for an agent to select this tool over the listed siblings.

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

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

Annotations already mark the tool as read-only, idempotent, and open-world. The description adds valuable behavioral context by emphasizing the live/real-time nature of the data and listing what the response covers, including platform, load, notes, amenities, and running days. This goes beyond the annotations without contradicting them.

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 front-loaded with the core object and packs the resource, data scope, practical examples, and additional return fields into one efficient sentence. Every clause earns its place.

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

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

For a read-only detail tool with an output schema and annotations already covering safety and idempotence, the description is sufficiently complete. It explains what the tool returns, the live aspect, and the practical questions it answers, leaving no critical gap for an agent to select and call it correctly.

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

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

The schema already documents journey_id as coming from a db_journeys leg or board row and format as an enum. The description reinforces that the tool targets one specific train run, but it adds little new parameter-level detail. With 50% schema coverage, this is adequate though not exceptional.

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 the resource ('one specific train run') and the exact data returned: scheduled and real-time times, platform, load, notes, amenities, and running days. This distinguishes it from station-level tools like db_departures and db_arrivals without requiring the agent to open 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?

The illustrative use cases ('where is this train now, is my stop still served, which platform at my stop') give strong contextual guidance for when to call this tool. It does not explicitly name excluded alternatives, but the 'all stops of one train run' framing makes the intended usage clear.

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