Server Quality Checklist

Tool Scores

• get_stopB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns specific fields (name, coordinates, accessibility, services) which is useful context beyond the annotations. However, it doesn't mention what happens for invalid/unknown stop codes 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.

  Conciseness5/5

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

  A single compact sentence that conveys purpose and return fields with zero wasted words. Appropriately front-loaded with the verb and resource.

  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?

  The tool is a simple single-parameter lookup with an output schema and clear read-only annotations. The description covers purpose and return fields adequately. It falls slightly short on guiding invalid-code behavior and how the returned 'servicios' are structured, but for a straightforward lookup this is near-adequate.

  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 and only one param (stop_code), the description's 'por su código' indicates the parameter is a stop code string. However, it doesn't clarify the code format, whether it must be URL-encoded, or where to obtain valid codes. The description provides minimal addition over the bare schema field name.

  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+resource ('Obtener información detallada de un paradero') and specifies the key identifier (código). It clearly states the fields returned (nombre, coordenadas, accesibilidad, servicios). While clear, it doesn't explicitly differentiate from sibling search_stops or find_nearby_stops, though the focus on retrieving by code implies a singular lookup rather than search.

  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 lookup by stop code but provides no guidance on when to use this vs. alternatives like search_stops or find_nearby_stops. There's no explicit when-to-use/when-not-to-use, no prerequisites, and no mention that stop_code should come from a search-first workflow.

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

• find_stops_in_bboxB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it's a bounding-box query but doesn't disclose behavioral specifics like whether results are sorted, paginated, capped at a limit, or whether longitude/latitude order is enforced. With solid annotations covering safety, 3 is appropriate.

  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 extremely concise—a single clause. It's front-loaded with the core purpose. However, brevity comes at the cost of omitted helpful detail (parameter semantics, usage guidance), so while there's no waste, it may be under-specified.

  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?

  The tool has an output schema present and safe read-only annotations, which reduces burden. With 4 parameters at 0% schema coverage and no behavioral detail, the description is minimally adequate but leaves gaps in parameter guidance and return behavior. Given the output schema fills some context, completeness is passable but not strong.

  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%, so the description carries the full burden for parameter meaning. The description mentions 'min/max lat/lon' which loosely maps to the four parameters, but doesn't clarify valid ranges, ordering constraints, validation rules, or the relationship between min/max pairs. Given 0% coverage, the description should compensate substantially and doesn't.

  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 finds stops within a bounding box using min/max lat/lon coordinates. It distinguishes itself from spatial alternatives like find_nearby_stops (point-based) and find_closest_station. However, it doesn't explicitly name sibling alternatives for differentiation, and 'Paraderos' is a Spanish term that may not be universally understood.

  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 mention of 'bounding box (min/max lat/lon)' implies this is for rectangular geographic area queries, which implicitly contrasts with point-based tools like find_nearby_stops and find_closest_station. However, there's no explicit guidance on when to use this vs alternatives, no stated exclusions, and no mention of coordinate format or ordering requirements.

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

• get_route_shapeB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the output coordinate format ([lon, lat]) which is useful. However, it does not disclose details like whether direction=0 returns outbound geometry, whether the polyline is truncated, or how the default direction is treated.

  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 concise sentence that states purpose and output format with no filler. It is efficiently front-loaded and earns its place, though it could have used the spare space to cover more behavioral detail rather than being minimal.

  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?

  There is an output schema present, so return-value explanation isn't strictly needed. However, the tool has 2 parameters with 0% schema coverage and a direction that defaults to 0 but is unexplained. For a geometry tool in a GTFS domain, the description is adequate but misses directional semantics and use-case context relative to sibling tools.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description bears responsibility. It defines the shape output format ([lon, lat]) but adds no semantic detail about the direction parameter (what direction values mean, default behavior) or the route_id format. The route_id parameter is self-evident, but direction semantics are entirely unexplained.

  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 'Geometría (shape) de un recorrido como coordenadas [lon, lat]' with a clear verb+resource (get shape/geometry of a route) and clarifies the output format as [lon, lat] coordinates. It does not explicitly distinguish it from sibling tools, but there's only one geometry-shaped tool among the listed siblings, so differentiation is reasonably clear.

  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 vs alternatives. It doesn't mention that geometry complements get_route_stops or get_route, nor any conditions like requiring a specific GTFS feed, or the meaning of the default direction parameter. An agent would not know when to prefer this over get_route or get_route_stops for spatial needs.

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

• get_routes_near_pointB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the radius-scoping behavior ("dentro de un radio"), which is useful. However, it doesn't disclose return format, pagination, or how coordinates are interpreted (which coordinate system), though the presence of an output schema mitigates some of this gap.

  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?

  A single clear sentence that conveys the core behavior. It's appropriately concise with no filler. While it could add more detail, it's not bloated and communicates the essence efficiently.

  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 an output schema, return-value documentation is covered. With readOnly annotations and 3 simple parameters, a minimal description might suffice. However, with 0% schema coverage and no usage guidance against a large sibling set (14 tools), the description leaves the agent to guess about radius semantics and tool selection. Adequate but with clear gaps.

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

  Parameters3/5

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

  Schema description coverage is 0%, meaning the schema itself provides no descriptions for latitude, longitude, or radius_km. The description mentions a coordinate and a radius conceptually, which maps roughly to latitude/longitude and radius_km, but it doesn't specify units for radius_km, coordinate format expectations, or the default 0.3 km behavior. Since coverage is 0%, the description should compensate more but only partially does.

  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 the tool returns routes passing near a coordinate within a radius ("Recorridos que pasan cerca de una coordenada, dentro de un radio."). This is a clear verb+resource action. However, it doesn't explicitly distinguish it from sibling tools like find_nearby_stops or find_closest_station, though the route-vs-stop distinction is somewhat implied by the context.

  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?

  There is no explicit guidance on when to use this tool versus alternatives. The description gives no hint that for stops one would use find_nearby_stops, or that get_routes is for listing all routes. Usage context is only implied by the tool's own phrasing and sibling names, with no exclusions or alternatives named.

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

• get_system_statsB
  3.3/5.0
  Behavior4/5

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

  The readOnlyHint=true and destructiveHint=false annotations already convey this is a safe read operation. The description adds the context that it covers specific content areas (paraderos, recorridos, viajes, modos), which gives the agent an understanding of what scope the stats cover. With annotations covering the safety profile, this is adequate. No contradiction found.

  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 short sentence that is efficient and front-loaded with the resource name (Estadísticas del sistema). It lists the covered content areas concisely. It could perhaps benefit from a note on the return format or scope, but for a zero-parameter stats tool, it's appropriately brief.

  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?

  The tool has an output schema (which per rubric means return values needn't be explained), 0 parameters, and read-only annotations. However, the description doesn't clarify what 'estadísticas' means precisely — counts? aggregates over time? current values? It also doesn't distinguish itself from get_gtfs_status. For a simple stats tool with no params and good annotations, this is mostly complete but could briefly clarify scope or units.

  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 0 parameters, and the schema coverage is 100%. Per the rubric, 0 params earns a baseline of 4. There are no parameters requiring explanation, so the description doesn't need to elaborate on parameter semantics. The description appropriately describes what the stats contain without needing param details.

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

  Purpose3/5

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

  The description states the tool returns 'Estadísticas del dataset GTFS' (GTFS dataset statistics) with a list of content areas (paraderos/stops, recorridos/routes, viajes/trips, modos/modes). It's clear enough about what it returns, but it doesn't specifically differentiate from sibling tools like get_gtfs_status, which may also return data about system state. The verb 'get' plus the clear resource improves clarity.

  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 given about when to use this tool versus alternatives. Notably, get_gtfs_status is a sibling tool that likely provides related system status information, and there's no differentiation between them. The description doesn't mention prerequisites, context, or when this would be preferred over other tools. A brief 'use to get a quick overview of the GTFS dataset' or distinction from status tools would help.

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

• find_nearby_stopsB
  3.4/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the ordering-by-distance behavior and spatial radius scoping. However, it doesn't disclose return format details, coordinate system expectations (e.g., WGS84), or whether the radius is strict or inclusive — though the presence of an output schema partially relieves this burden.

  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?

  A single, efficient sentence that conveys purpose, scope, and ordering behavior with zero waste. Well front-loaded and appropriately terse given the moderate complexity of the tool.

  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?

  The tool has 4 parameters (2 required), an output schema, and read-only annotations. The description covers the core spatial-retrieval purpose and ordering. Gaps remain: no guidance on choosing between this and find_closest_station / find_stops_in_bbox, no explanation of coordinate format, and no mention of result count behavior relative to limit vs radius. Adequate but not complete.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description carries the full burden for parameter meaning. The description covers the conceptual purpose of latitude/longitude (coordinate center) and radius_km (radius), and implies limit acts as a count cap. However, it doesn't explicitly enumerate each parameter or note defaults (0.5 km radius, limit 20), which are left to the schema.

  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 specific verb+resource+scoping: find stops within a radius of a coordinate, ordered by distance. It's clear and distinct from siblings like search_stops (text search) and find_stops_in_bbox (bounding box). However, it doesn't explicitly differentiate from find_closest_station or get_routes_near_point, which are also spatial lookups.

  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 for spatial proximity queries ('within a radius of a coordinate, ordered by distance') but provides no explicit when-to-use versus alternatives, no exclusions, and no mention of the relationship to siblings like find_closest_station (single nearest vs list within radius). The ordering-by-distance detail helps infer utility but doesn't state alternatives.

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

• get_arrivalsB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the data source (iBus + RED web) which is useful context, but doesn't explain the output format despite having an output schema, nor the live/real-time nature's implications (staleness, caching, polling behavior). With an output schema present, some burden is relieved, but the description could note that results are time-sensitive predictions.

  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 compact at two sentences, front-loaded with the core function. The usage hint is efficiently integrated. It's lean without being under-specified, though a bit more parameter detail would improve the score.

  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?

  The tool has 2 parameters (1 required), an output schema, and readOnly annotations. For a simple read-only arrival prediction lookup, the description covers the core purpose and usage sequence. However, with 0% schema coverage and no parameter documentation, the description is somewhat thin for a tool with an output schema that could contain complex prediction data. It's adequate but could elaborate on what 'service' selects and the nature of returned predictions.

  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%, so the description must compensate for parameter meaning. However, the description does not explain what 'stop_code' means, what format it should be in (numeric? string?), or what the 'service' parameter does. The description mentions resolving the code via search_stops but does not define the parameter types or expected values beyond what the schema name implies.

  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 'Predicciones de llegada en tiempo real para un paradero' (real-time arrival predictions for a stop) with a specific verb in Spanish. It identifies the data source (iBus + RED web) and differentiates from siblings by focusing on arrival predictions for a resolved stop code. It doesn't explicitly name a sibling alternative but the context of using after search_stops helps.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool: 'Usar después de resolver el código con search_stops' (use after resolving the code with search_stops). This provides clear sequencing guidance and ties it to the search_stops sibling, which is the prerequisite. It gives actionable usage context.

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

• get_gtfs_statusB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read profile is established. The description adds the actual output fields (availability, download date, validity), which is useful behavioral context beyond the empty schema. However, it doesn't describe output format or clarify what the 'validity' (vigencia) field means semantically.

  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 concise sentence listing exactly what the tool returns. No wasted words, front-loaded with the resource name. Slightly dense for a non-expert but efficient. Could arguably benefit from a tiny bit more explanation of the fields, but that would add length without proportional value.

  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?

  For a zero-parameter read-only status tool with an output schema present, the description covers the essentials: what it returns (3 fields). The output schema handles return-value details. Given the low complexity (no params, no mutation), this is reasonably complete. Minor gap: no context on the 'vigencia' semantics or how to interpret availability.

  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?

  Tool has 0 parameters, so schema has nothing to document. With zero params, the baseline is 4. The description correctly indicates no parameters are needed and simply returns status, which is appropriate for a zero-arg introspection tool.

  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?

  Description states it returns GTFS dataset status: availability, download date, and validity period. Clear verb (get) + specific resource (GTFS dataset status). It lists the fields returned. Doesn't explicitly distinguish from siblings, but the resource (GTFS dataset) is distinct enough from the stop/route/journey siblings that differentiation is implicit.

  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 when-to-use guidance, no context about why one would query this (e.g., checking data freshness before planning journeys, understanding how recent the GTFS feed is). Given the sibling tools like plan_journey and get_arrivals depend on GTFS data freshness, the description could note this relationship but doesn't. No exclusions or alternatives mentioned.

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

• get_route_stopsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the directional scoping (ida/vuelta) which is useful behavioral context beyond the annotations, but doesn't disclose other behaviors like ordering guarantees, empty results for unknown routes, or error handling. With annotations present, this 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.

  Conciseness4/5

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

  Single concise sentence that packs the essential information: what it returns (stop sequence for a route), the scoping (a single direction), and the direction code mapping. No wasted words, front-loaded with the core purpose.

  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?

  Has an output schema and read-only annotations, so the tool doesn't need to explain return values or mutation risks. The description covers the core purpose and the direction semantics. However, it doesn't clarify behavior for invalid route_ids, whether direction=1 exists for all routes, or how to discover available routes, which an agent might need. Adequate but with gaps given the query-oriented context.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description carries the full burden for parameter meaning. The description clarifies route_id implicitly (identifies the recorrido) but its main contribution is explaining direction semantics with the '0=ida, 1=vuelta' mapping. However, no enums or validation are added for the direction values, and route_id format isn't explained. Baseline 3 is appropriate given zero schema coverage.

  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 the tool fetches the sequence of stops for a route in a given direction. The verb is implicit (get from name) but the resource (paradas/ruta) is clear. It distinguishes from get_route (route details) and get_route_shape (shape geometry), though it doesn't explicitly name them.

  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 explains the direction parameter (0=ida, 1=vuelta) which clarifies a key usage aspect. However, it doesn't explicitly state when to use this vs siblings like get_route or search_stops, leaving the usage context implied rather than explicit.

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

• list_routesB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context—no mention of what the list returns, pagination, ordering, or volume of results. With annotations present the bar is lower, so the minimal-but-consistent picture earns a midpoint score.

  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, front-loaded purpose, zero waste. It efficiently communicates the core operation and the filter option. One could argue it's slightly under-specified rather than concise, but for the information it conveys, the structure is appropriate.

  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?

  This is a simple filtered-list tool with an output schema present, so the description doesn't need to explain return values. The output schema and one clearly documented parameter cover much of the need. However, given that the mode parameter is undocumented in the schema (0% coverage), the description could have more thoroughly covered its valid values and semantics, which it does enumerate partially.

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

  Parameters3/5

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

  With only 1 parameter at 0% schema description coverage, the description carries the burden of defining 'mode'. It does list valid mode values (bus, metro, rail, tram), which adds value beyond the schema that just declares mode as a string/null. However, it doesn't specify whether the parameter is case-sensitive, accepts aliases, or what happens if omitted.

  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 the verb+resource clearly ('Listar recorridos' = list routes) and distinguishes itself from route-specific siblings by presenting a list operation. However, it doesn't differentiate from other list-like siblings semantically beyond naming the resource. The 'opcionalmente filtrados por modo' adds scoping but the tool name and title already communicate the core purpose.

  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 when to use this tool (when listing routes, optionally by mode) but gives no explicit usage guidance or exclusions relative to sibling tools like get_route, get_route_stops, or get_route_shape. No when-not-to-use or alternative tool references are provided, so the agent must infer appropriate usage.

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

• get_routeA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description lists what data is returned (name, color, mode, stops, frequencies), adding some value about scope. However, with no output schema detail discussed and limited behavioral context beyond the annotation baseline, it doesn't add rich behavioral information about pagination, defaults, or edge cases like routes with no stops.

  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 concise sentence that enumerates the key fields comprehensively. It covers all the meaningful content in 15 words with no waste. Slightly more context about relationships to sibling tools could have been added but the economy is good.

  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?

  The tool has an output schema which covers return-value expectations, and readOnly annotations. However, the description doesn't clarify how this relates to siblings like get_route_stops, get_route_shape, and list_routes — whether calling get_route returns everything they do or is a different view. For a tool with a moderately rich output (stops, frequencies), a bit more guidance on relationship to sibling tools would improve completeness.

  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?

  There is only one parameter (route_id) which is self-explanatory and already documented by the schema. With 0% schema description coverage but a single obvious parameter, the tool name plus description context ('detalle de un recorrido') makes the route_id meaning clear. Since there's only one obvious parameter, the description doesn't need to add much beyond what the schema conveys. However, it doesn't specify the expected format or source of route_id (e.g., from list_routes).

  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 verb+resource ('Detalle de un recorrido' — detail of a route) and enumerates the specific fields returned: nombre, color, modo, paradas de ida/vuelta, y frecuencias por día. It distinguishes from siblings like get_route_stops (which focuses on stops only) and get_arrivals. However, it's in Spanish while the field is route_id, and it doesn't explicitly differentiate from get_route_shape which is a sibling.

  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 this is for retrieving comprehensive route details including stops and frequencies, which distinguishes it somewhat from get_route_stops and get_arrivals. However, there's no explicit when-to-use guidance, no exclusions, and no mention of how it differs from the other get_route* siblings. The purpose is inferable but not explicitly stated.

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

• find_closest_stationA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is fully covered structurally. The description adds that it returns 'sus servicios' (its services), giving some indication of output richness. However, it doesn't disclose return format details, units, or error behaviors, though the output schema exists to cover some of this.

  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 is one concise sentence that packs purpose, scope, and output summary into minimal words. No wasted text; every element earns its place. Perfectly front-loaded with the verb and resource.

  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?

  The tool has only 2 parameters, an output schema, and read-only annotations, so the baseline requirements are modest. The description covers purpose and output (services) adequately. However, given the 0% parameter schema coverage, the description fails to compensate by explaining coordinate format expectations, leaving a gap for a numeric input tool.

  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%, meaning neither the schema properties nor the description explain what latitude/longitude should look like (degress, decimal format, bounds). The description says 'una coordenada' (a coordinate) which somewhat implies lat/lng pair usage, but doesn't compensate for the 0% coverage gap by explaining coordinate format expectations or constraints.

  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 clearly states the verb ('Encontrar' = find), the resource ('estación de metro o tren' = metro or train station), and the specific scope ('más cercana a una coordenada' = closest to a coordinate). This clearly distinguishes it from siblings like find_stops_in_bbox and find_nearby_stops by specifying metro/train stations specifically, and it mentions returning services.

  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 when a user needs the nearest metro or train station to a coordinate, but doesn't explicitly state when NOT to use it versus the sibling tools. Given the sibling set includes find_nearby_stops (all stops) and get_routes_near_point, there's no explicit comparison to guide selection. However, the metro/train specificity provides some implicit differentiation context.

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

• suggest_direct_routesA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds the key behavioral fact that this tool does not handle transfers (only direct routes). However, it doesn't clarify how 'direct' is defined (geographic proximity? same line?) or what happens with routing variants, which would add useful context.

  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 short sentences, completely front-loaded with the primary purpose then the exclusion with an alternative. No wasted words.

  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?

  This is a moderately simple tool (5 params, all primitive numbers) with a good output schema and solid annotations. The description captures the core behavior (direct routes only) and directs to the transfer-planning sibling. Some minor gaps remain around radius_km semantics, but given the structural richness elsewhere, this is reasonably 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%, meaning the description adds no parameter explanations. Of the 5 parameters, only radius_km has a title/default hint in the schema; the four required lat/long parameters are self-explanatory by name but the description gives no semantic context for radius_km (search radius for stops at endpoints?) or for how the coordinates relate to stops. The description provides zero compensation for the 0% coverage gap.

  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 says 'Sugerir recorridos directos que conecten dos puntos' (Suggest direct routes connecting two points). The verb is clear and the resource (direct routes between two points) is specified. It doesn't explicitly distinguish from all sibling tools, but the 'direct' qualifier does separate it from plan_journey which is named.

  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 description states 'No planifica transbordos; para eso usar plan_journey' (Does not plan transfers; for that use plan_journey). This explicitly names an alternative tool and states when NOT to use this tool. It provides a clear exclusion with a named alternative.

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

• search_stopsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by noting partial matching ('nombre o código parcial'), which is a behavioral trait not in the annotations. However, it doesn't disclose behavior around limit handling, pagination, or response format, which is acceptable given the annotations already carry the safety burden.

  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 sentences, zero waste. States the purpose and the key usage context. Front-loaded with the action, well-organized.

  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?

  Has an output schema, so return values need no explanation. 2 simple params with defaults, read-only annotations, a clear purpose, and a usage hint. For a low-complexity search tool, this is complete enough. It doesn't over-explain and covers what an agent needs.

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

  Parameters3/5

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

  Schema description coverage is 0%, but with only 2 params (query, limit), the schema defaults carry most of the burden. The description mentions 'nombre o código parcial' which maps to the query param semantics, adding context beyond 'Query' as a title. No detail on limit beyond the default. Baseline 3 is appropriate; description adds marginal value.

  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?

  Clear verb+resource ('Buscar paraderos') with scope ('de Santiago') and search dimensions ('por nombre o código parcial'). It distinguishes from siblings like get_stop (which resolves a specific stop) and find_nearby_stops (geospatial search), though it doesn't explicitly name them.

  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?

  Provides clear when-to-use context: 'Útil cuando el usuario menciona un lugar o intersección y hay que resolver el código del paradero.' This implies the use case of resolving a stop code from a partial name/place mention. Doesn't explicitly name alternatives, but the implied usage context distinguishes it from geospatial tools.

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

• plan_journeyA
  4/5.0
  Behavior4/5

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

  The annotations provide readOnlyHint=true and destructiveHint=false, so the safety profile is already clear. The description adds useful behavioral context: it notes the RAPTOR algorithm and mentions integrated fare, which signals what kinds of output the agent can expect. It could add departure time handling detail, but the readOnly annotation lowers the bar and the description adds meaningful algorithmic context.

  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 compact sentence that front-loads the core purpose (plan journey between coordinates via RAPTOR) and then lists the key parameter value mappings concisely. Every clause adds value — no filler or repetition. It could benefit from structured formatting for the parameter lists but is efficient overall.

  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?

  The tool is moderately complex (8 params, journey planning with multiple output types), and an output schema exists which can document return values. The description covers the algorithm and the two most complex parameters (day, fare_type with their enums). However, with 0% schema description coverage, several parameters (departure_time, max_transfers, coordinate formats) have no documentation anywhere — the description should have compensated further given the annotation and schema coverage context.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It explains day (L/S/D) and fare_type (normal/estudiante/adulto_mayor) mappings, which adds real semantic value. However, it does not explain the from/to coordinates format, max_transfers semantics, or departure_time format, leaving 6 of 8 parameters partially undocumented. The description covers the enum-like values but the coordinate/latency parameters rely on schema titles alone.

  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 clearly states a specific verb+resource: planning a public transport journey between two coordinates using RAPTOR. It specifies exactly what outputs to expect (alternatives with transfers, times, integrated fare) and distinguishes it from siblings that search stops, routes, or arrivals — this is the only tool that plans complete journeys.

  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 description opens with the core use case ('planificar un viaje') and explains the day and fare_type parameter value meanings. It provides clear context for when to use this tool versus the other transit data tools (which query stops/routes/arrivals vs. computing full itineraries). However, it does not explicitly state when NOT to use it or name specific alternatives.

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