Server Quality Checklist

Tool Scores

• tool_get_seat_availabilityC
  2.5/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. Only behavioral hint is 'raw' (suggesting unprocessed data), but this is not explained. No disclosure of caching, rate limits, or whether this is real-time vs cached data.

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

  Conciseness4/5

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

  Single sentence is efficiently structured and front-loaded. However, extreme brevity is inappropriate given zero schema documentation and lack of annotations; conciseness becomes underspecification.

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

  Completeness2/5

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

  With 0% schema coverage, no annotations, and ambiguous relationship to tool_get_seat_stats, the description is insufficient. While an output schema exists (reducing need for return value explanation), the input parameters and 'raw' data characteristics remain undocumented.

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

  Parameters2/5

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

  Schema has 0% description coverage (only titles). Description mentions parameter names but adds no semantic meaning—does not explain what place_type codes represent, how train_nr differs from connection_id, or expected value ranges for these integers.

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

  Purpose4/5

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

  States specific action (Get) and resource (raw seat availability) with identifying parameters. However, fails to distinguish from sibling tool_get_seat_stats (availability vs stats distinction is unclear), and 'raw' is undefined.

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

  Usage Guidelines1/5

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

  Provides no guidance on when to use this tool versus alternatives (particularly tool_get_seat_stats), no prerequisites mentioned, and no exclusion criteria provided.

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

• tool_search_connectionsC
  2.6/5.0
  Behavior2/5

  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 fails to mention whether this performs real-time searches, cached lookups, rate limits, or if it requires specific authentication. The description also does not clarify if this tool books tickets or merely queries schedules.

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

  Conciseness3/5

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

  The description is a single efficient sentence with no wasted words. However, for a tool with 7 parameters and complex search functionality, the brevity results in under-specification rather than optimal conciseness. It is front-loaded but incomplete.

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

  Completeness2/5

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

  Given the tool has 7 parameters (5 optional), 0% schema coverage, and no annotations, the description is insufficient. It mentions only the core concept (searching connections) while ignoring filtering capabilities (date, direct, brands), result limits (length), and pricing options (include_prices).

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

  Parameters2/5

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

  With 0% schema description coverage across 7 parameters, the description inadequately compensates. While 'between two stations' implies the purpose of 'start' and 'end', it completely omits the other 5 parameters: date format, what 'brands' refers to (operators?), whether 'direct' filters for non-stop journeys, what 'length' controls (result count vs journey duration), and the implications of 'include_prices'.

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

  Purpose4/5

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

  The description clearly states the verb (search) and resource (train connections) with specific scope (between two stations). However, it does not explicitly differentiate from siblings like tool_get_departures or tool_search_stations, though the 'between two stations' phrasing implicitly distinguishes origin-destination searches from single-station queries.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like tool_get_departures (for departures from a single station) or tool_get_train_by_id (for specific train details). No prerequisites or conditions are mentioned.

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

• tool_get_arrivalsC
  2.7/5.0
  Behavior2/5

  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 only hints at behavior through the word 'upcoming' (implying a forward-looking time window), but fails to disclose how many results are returned, whether data is real-time or cached, error handling for invalid stations, or the default behavior when the date parameter is omitted.

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

  Conciseness4/5

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

  The description is a single, efficiently structured sentence with no redundant words. It is front-loaded with the action verb. However, extreme brevity contributes to the lack of necessary detail in other dimensions.

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

  Completeness2/5

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

  While an output schema exists (relieving the description of return value documentation), the combination of zero schema descriptions, no annotations, and ambiguous sibling relationships means the description is insufficient. It should explain the date parameter's default behavior and clarify the distinction from departure queries.

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

  Parameters2/5

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

  With 0% schema description coverage, the description needed to compensate but only implicitly references the 'station' parameter ('at a station'). The 'date' parameter is completely undocumented despite having a default null value that presumably triggers current-day behavior, which the description fails to clarify.

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

  Purpose4/5

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

  The description clearly states the action (Get), resource (train arrivals), and scope (upcoming, at a station). However, it fails to distinguish from the sibling tool 'tool_get_departures', which could easily be confused given the identical structure and domain.

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

  Usage Guidelines2/5

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

  No guidance provided on when to use this versus 'tool_get_departures', 'tool_get_realtime_timetable', or 'tool_search_connections'. The 'upcoming' qualifier implies temporal filtering but does not explicitly exclude historical data or explain the time window.

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

• tool_get_departuresC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full disclosure burden. It only adds the word 'upcoming' implying time-bounded results, but does not clarify the time window (e.g., next hour, 24 hours), pagination behavior, or what 'upcoming' means when a specific date is provided.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no redundant words. However, given the complete lack of schema descriptions and absence of annotations, this brevity underserves the agent's information needs.

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

  Completeness2/5

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

  While an output schema exists (covering return values), the description inadequately documents the two input parameters (0% schema coverage). Missing usage guidelines and behavioral details (scope of 'upcoming') leave significant gaps for a tool with multiple siblings.

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

  Parameters2/5

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

  Schema description coverage is 0%, requiring the description to compensate. While 'from a station' implies the station parameter, the description does not specify whether 'station' expects a code, ID, or full name, nor does it mention the 'date' parameter's format or behavior when null.

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

  Purpose4/5

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

  The description states a clear action ('Get') and resource ('train departures') with scope ('upcoming'). However, it does not differentiate from siblings like 'tool_get_realtime_timetable' or 'tool_search_connections' which may also return departure information.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives (e.g., 'tool_get_arrivals' or 'tool_search_connections'). The description also fails to explain when to provide the 'date' parameter versus omitting it.

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

• tool_get_seat_statsC
  2.7/5.0
  Behavior2/5

  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 fails to indicate whether this is a read-only operation, what time period the statistics cover, or any rate limiting. The description adds minimal behavioral context beyond the tool name.

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

  Conciseness4/5

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

  The single-sentence description is efficiently structured and front-loaded with key information. However, it is overly concise given the lack of annotations and schema descriptions, leaving insufficient space for necessary usage context.

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

  Completeness2/5

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

  Given 4 parameters with 0% schema coverage and no annotations, the description is inadequate. It fails to clarify the distinction between 'statistics' and 'availability' (critical given tool_get_seat_availability exists) or explain parameter formats. The existence of an output schema does not excuse the lack of input parameter guidance.

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

  Parameters2/5

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

  With 0% schema description coverage, the description must compensate significantly but does not. While 'route segment' implies the stations parameter, it doesn't explain that stations requires an array format, what 'brand' represents (operator code?), or that date defaults to current day if null. Critical parameter semantics are missing.

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

  Purpose4/5

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

  The description clearly identifies the resource (seat occupancy statistics) and scope (train on a route segment) with specific nouns. However, it uses the weak verb 'Check' and does not explicitly differentiate from the similar sibling tool_get_seat_availability, leaving ambiguity about whether this returns real-time availability vs. historical/analytical data.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, particularly tool_get_seat_availability. There are no prerequisites mentioned (e.g., requiring valid train_number from tool_get_all_trains) or exclusion criteria.

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

• tool_get_train_calendarC
  2.8/5.0
  Behavior2/5

  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. While it hints at returning 'all dates,' it does not specify the date format, date range (historical vs. future), pagination behavior, or error handling when a train number is invalid.

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

  Conciseness4/5

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

  The description is a single, efficient sentence with no redundant words and the core purpose front-loaded. However, given the lack of parameter documentation in the schema, appropriate sizing would have warranted a second sentence clarifying the required inputs.

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

  Completeness3/5

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

  For a tool with a simple two-parameter schema and an existing output schema (which removes the need to describe return values), the description adequately covers the core function. However, the complete lack of parameter documentation in both schema and description leaves a significant gap.

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

  Parameters2/5

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

  With 0% schema description coverage, the description needed to compensate by explaining the 'brand' and 'train_number' parameters. It only implicitly references 'a specific train' (mapping to train_number) but completely omits what 'brand' represents or the expected formats for either parameter.

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

  Purpose4/5

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

  The description clearly identifies the action ('Get') and resource ('dates/operating calendar') with specific scope ('when a specific train runs'). It implicitly distinguishes from siblings like tool_get_train_route (path) and tool_get_realtime_timetable (times) by focusing on operating dates.

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

  Usage Guidelines2/5

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

  The description states what the tool does but provides no guidance on when to use it versus alternatives (e.g., when to use this instead of tool_get_train_by_id or tool_get_realtime_timetable). No prerequisites or conditions are mentioned.

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

• tool_get_train_routeC
  2.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the core return value (route and stop schedule) but omits operational details such as the behavior of the 'closest' flag, default date handling, caching policies, or potential error conditions.

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

  Conciseness4/5

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

  The single sentence is front-loaded with the action verb and contains no redundant words. However, given the tool's complexity (4 parameters with zero schema descriptions), the description may be overly terse rather than appropriately concise.

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

  Completeness2/5

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

  Despite having an output schema (removing the need to describe return values), the description is incomplete due to the 0% parameter schema coverage and lack of annotations. The undocumented 'date' and 'closest' parameters are critical for proper tool invocation and should have been explained.

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

  Parameters2/5

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

  Schema description coverage is 0%, requiring the description to compensate. While it implicitly maps 'brand and number' to their respective parameters, it completely ignores the optional 'date' and 'closest' parameters, leaving half the input space undocumented.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('full route and stop schedule'), and specifies the lookup method ('by brand and number') which implicitly distinguishes it from sibling tools like tool_get_train_by_id. However, it doesn't explicitly differentiate from similar schedule-based siblings like tool_get_realtime_timetable or tool_get_train_calendar.

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

  Usage Guidelines2/5

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

  The description mentions the identifier pattern (brand and number) but provides no explicit guidance on when to use this tool versus alternatives like tool_search_connections or tool_get_train_by_id. It also fails to explain when the optional date/closest parameters should be utilized.

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

• tool_get_train_by_idB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation, but the description doesn't explicitly confirm safety, idempotency, error conditions, or rate limiting. Minimal behavioral disclosure beyond the action itself.

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

  Conciseness5/5

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

  Single, tightly constructed sentence with zero redundancy. Front-loaded with the action verb immediately establishing the tool's function. Every word earns its place.

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

  Completeness3/5

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

  Adequate for a single-parameter lookup tool with an output schema (which handles return value documentation). However, lacks prerequisite guidance on how to obtain the 'internal Koleo ID,' leaving a gap for agents attempting to use this tool without prior context.

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

  Parameters4/5

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

  Despite 0% schema description coverage, the description successfully compensates by explaining that the parameter represents an 'internal Koleo ID.' This adds critical semantic meaning missing from the schema. Could be improved by explaining how to obtain this ID or its format constraints.

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

  Purpose4/5

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

  States a specific verb ('Get') and resource ('train's route and stops'), and distinguishes from siblings by specifying the required identifier type ('internal Koleo ID'). However, it doesn't clarify the relationship to sibling 'tool_get_train_route', which appears to have overlapping functionality.

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

  Usage Guidelines2/5

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

  Provides implicit guidance by specifying the tool requires an 'internal Koleo ID,' suggesting use when that specific identifier is available. Lacks explicit when-to-use/when-not-to-use guidance or comparison to alternatives like 'tool_get_train_route' or 'tool_search_connections'.

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

• tool_get_brandsB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'List all available' without indicating if the data is static or real-time, if there are rate limits, pagination behavior, or cache considerations. The scope ('all available') is mentioned but not explained.

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

  Conciseness5/5

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

  The description consists of a single efficient sentence with parenthetical examples that add value without verbosity. There is no redundant or filler text; every word serves the purpose of defining the tool's scope.

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

  Completeness4/5

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

  Given the tool's simplicity (zero parameters) and the presence of an output schema (which handles return value documentation), the description is adequate. However, it falls slightly short by not clarifying the relationship between 'brands/operators' and the sibling 'tool_get_carriers' concept.

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

  Parameters4/5

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

  The tool accepts zero parameters, which according to the calibration baseline earns a score of 4. The input schema confirms this with an empty properties object, and the description correctly implies no filtering is needed by stating 'List all'.

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

  Purpose4/5

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

  The description uses a specific verb ('List') and resource ('train brands/operators'), with concrete examples (IC, REG, EIC, KM) that clarify the domain. However, it does not explicitly differentiate from the sibling tool 'tool_get_carriers', which could cause confusion since 'operators' and 'carriers' are often synonymous.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives, particularly 'tool_get_carriers'. The description does not state prerequisites, exclusion criteria, or suggest when this list is necessary (e.g., for filtering connections).

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

• tool_get_carriersB
  3.3/5.0
  Behavior2/5

  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 fails to indicate whether this is cached/static data, if there are rate limits, or auth requirements. The word 'List' implies read-only, but explicit safety/performance characteristics are absent.

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

  Conciseness5/5

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

  Single sentence with zero waste. The parenthetical examples are efficiently placed at the end to clarify domain terminology without bloating the core verb-resource statement.

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

  Completeness4/5

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

  Given the tool's simplicity (no inputs) and the presence of an output schema, the description is complete enough for invocation. It adequately covers the 'what' (carriers) but misses the 'how expensive/safe' aspects that would make it fully complete for an agent lacking annotations.

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

  Parameters4/5

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

  The tool has zero parameters, which establishes a baseline score of 4 per the rubric. No parameter documentation is required.

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

  Purpose4/5

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

  The description uses a specific verb 'List' with clear resource 'train carriers' and concrete examples (PKP Intercity, POLREGIO) that implicitly distinguish it from siblings like tool_get_brands or tool_get_stations. However, it doesn't explicitly differentiate when to choose this over similar enumeration tools.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or contextual triggers (e.g., 'use this before searching connections to filter by carrier').

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

• tool_get_realtime_timetableB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the authentication requirement and hints at the data structure ('actual vs scheduled times'). However, it omits details about real-time data freshness, error handling for invalid train IDs, or rate limiting that would be valuable for a real-time data tool.

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

  Conciseness5/5

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

  The description consists of two efficient sentences with zero waste. The primary function is front-loaded in the first sentence, while the second sentence provides necessary operational context (authentication). Every word earns its place.

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

  Completeness3/5

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

  Given the tool has only two simple parameters and an output schema exists, the description provides a minimally viable foundation. However, the complete lack of parameter documentation and absence of behavioral details beyond authentication leaves notable gaps for an agent trying to invoke the tool correctly.

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

  Parameters2/5

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

  Schema description coverage is 0%, requiring the description to compensate. While 'for a train' loosely implies the train_id parameter, the operating_day parameter is completely undocumented. The description fails to explain what format operating_day expects (ISO date? YYYY-MM-DD?) or its purpose, leaving a significant gap given the schema provides no descriptions.

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

  Purpose4/5

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

  The description clearly states the tool retrieves a 'realtime timetable for a train' and specifies the key data returned ('actual vs scheduled times'). The 'realtime' qualifier helps distinguish it from sibling tools like tool_get_train_calendar or tool_get_train_route, though it doesn't explicitly name these alternatives.

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

  Usage Guidelines3/5

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

  The description identifies one prerequisite ('Requires authentication in config'), which is useful usage guidance. However, it lacks explicit guidance on when to use this versus similar timetable tools (tool_get_train_calendar, tool_get_train_route) or how to handle the optional operating_day parameter.

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

• tool_search_stationsB
  3.4/5.0
  Behavior2/5

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

  No annotations provided, so description carries full disclosure burden. It identifies the operation as a search (read-only implication) and mentions return fields (IDs, slugs, types), but omits critical behavioral traits: fuzzy vs exact matching, pagination, result limits, or rate limiting constraints.

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

  Conciseness5/5

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

  Two efficient sentences with zero waste. Purpose and return value are front-loaded immediately. Appropriate length for the tool's complexity.

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

  Completeness3/5

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

  Barely adequate given 0% schema coverage and no annotations. Mentioning return fields provides some value despite existing output schema, but the lack of parameter documentation for optional filters (type, country) creates significant gaps in contextual completeness.

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

  Parameters2/5

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

  Schema description coverage is 0%, requiring heavy compensation. Description only implicitly maps 'query' to station name via 'by name' phrase. Completely fails to document 'type' and 'country' parameters—critical filters for a station search tool.

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

  Purpose5/5

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

  Description uses specific verb 'Search' with clear resource 'train stations' and scope 'by name'. It effectively distinguishes from siblings like tool_get_station_info (retrieval by ID) and tool_search_connections (route finding).

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

  Usage Guidelines3/5

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

  Implies usage when looking up stations by name, but provides no explicit guidance on when to prefer this over tool_get_station_info or how it relates to the workflow with tool_search_connections. No 'when-not-to-use' or prerequisite guidance provided.

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

• tool_get_station_infoA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses what categories of data are returned, which is helpful, but omits error handling behavior, authentication requirements, or whether the data is cached/real-time.

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

  Conciseness5/5

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

  Single sentence with information-dense structure. Front-loaded with the action, specifies the resource, and efficiently lists the three data categories returned. No redundant or wasted words.

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

  Completeness3/5

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

  Given the tool's low complexity (single parameter) and existence of an output schema, the description adequately covers the high-level return value categories. However, the complete lack of input parameter documentation (0% schema coverage) leaves a significant gap that the description should have addressed.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description fails to compensate adequately. While it mentions 'a station,' it does not clarify whether the 'station' parameter expects an ID, name, or code, nor its format, leaving the input semantics underspecified.

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

  Purpose5/5

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

  The description uses a specific verb ('Get') with clear resource ('station info') and enumerates exact data fields returned (address, opening hours, facilities). This clearly distinguishes it from sibling tools focused on trains, routes, or schedules.

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

  Usage Guidelines3/5

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

  The description implies usage by listing specific static data fields (address, hours) that differentiate it from real-time or routing tools, but provides no explicit guidance on when to use this versus tool_search_stations or how to obtain the station identifier.

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

• tool_get_all_trainsA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden and discloses the sorting behavior ('sorted by time') and dual-direction scope. However, it omits other behavioral details like pagination, date null-handling, or whether data is real-time versus scheduled.

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

  Conciseness5/5

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

  Single sentence of 12 words with zero waste. Every clause earns its place: operation ('Get all trains'), sibling differentiation ('both departures and arrivals'), parameter context ('at a station'), and behavior ('sorted by time').

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

  Completeness3/5

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

  Given the tool has only two parameters and an output schema exists (relieving the description from explaining return values), the description is minimally adequate. However, with 0% schema coverage, it should have explained the date parameter semantics to be complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, requiring the description to compensate. While 'at a station' implies the station parameter, the description completely omits explanation of the 'date' parameter, its format, or the significance of the default null value.

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

  Purpose5/5

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

  The description uses specific verb 'Get' and resource 'trains', and explicitly distinguishes from siblings tool_get_arrivals and tool_get_departures by stating it returns 'both departures and arrivals', making the scope unambiguous.

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

  Usage Guidelines4/5

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

  The parenthetical '(both departures and arrivals)' provides clear implicit guidance on when to use this versus the specific arrival/departure sibling tools, though it lacks explicit 'when to use' phrasing or prerequisites.

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