Loading ToolBench
Professional product for AI-powered cycling and mountain bike route discovery, terrain analysis, and GPX generation.
BikeScout has three tools with complete input schemas and descriptions, but quality is uneven. geocode_location is well-named and described (verb_noun pattern, 10 - 1024 char range). trail_scout and trail_scout_simple have extensive parameter sets (38 and 42 params respectively) with good type coverage, but descriptions are verbose and some parameters lack clarity on mutual exclusivity. Output schemas are referenced (GeocodingResponse, FullMissionBriefingResponse) but not visible in source, so schema documentation cannot be fully verified. Error handling and recovery guidance are absent. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being READ_ONLY. Parameter descriptions average ~60 chars, below the 72-char baseline for A+ tools.
Finds latitude and longitude for any place name (city, mountain pass, address). Use this BEFORE other tools if you only have a location name and not coordinates.
Advanced trail discovery. Returns route data, difficulty, a GPX file, and a URI with the altimetry report. that can be displayed directly in the chat. Supports both single-point Round Trips and A->B separate destinations. If target_date is None, it defaults to the current date. OPERATIONAL NOTE FOR AGENTS: - If the user requests a 'circular' route of a specific length (target_distance_km), a variance of ±10% is considered a SUCCESSFUL MATCH. - DO NOT re-invoke the tool or attempt to refine the 'total_length_km' if the returned route falls within this 10% tolerance window. - Example: For a 25km request, any result between 22.5km and 27.5km is optimal.
Simplified tactical scout for cycling routes. Use this for quick route generation with sensible defaults. Only lat and lon are strictly required. Supports both single-point Round Trips and A->B separate destinations. If target_date is None, it defaults to the current date. OPERATIONAL NOTE FOR AGENTS: - If the user requests a 'circular' route of a specific length (target_distance_km), a variance of ±10% is considered a SUCCESSFUL MATCH. - DO NOT re-invoke the tool or attempt to refine the 'total_length_km' if the returned route falls within this 10% tolerance window. - Example: For a 25km request, any result between 22.5km and 27.5km is optimal.
Parameter complexity and mutual exclusivity undocumented. trail_scout and trail_scout_simple each have 38 - 42 parameters; many are optional toggles (include_gpx, include_map, include_poi, etc.) with no guidance on which combinations are valid or recommended. LLMs will struggle to reason about valid parameter sets.
Output schemas not visible in source code. Tool descriptions reference GeocodingResponse, FullMissionBriefingResponse, etc., but the actual schema definitions are not shown. Cannot verify field names, types, or whether responses include chaining IDs (e.g., latitude/longitude for downstream calls). Violates pattern:response-shaper.
No error handling or recovery guidance. Tool descriptions do not explain what happens on invalid input (e.g., invalid coordinates, API key missing, route not found). No guidance for LLM on retry strategy or fallback actions. Violates pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Tool annotations missing. All three tools are READ_ONLY (no state modification), but no readOnlyHint annotation is present. This forces LLMs to infer safety from descriptions, increasing hallucination risk. Current MCP spec (2026-07-28) supports tool annotations; they should be used.
Naming ambiguity: trail_scout vs trail_scout_simple. Both do route discovery; the distinction is unclear from names alone. 'simple' suggests fewer features, but both accept 38 - 42 parameters. Consider renaming to trail_scout_advanced and trail_scout_quick, or consolidate into one tool with a 'mode' parameter.