Loading ToolBench
MCP Server for Swiss road mobility — shared vehicles, EV charging, traffic alerts, Park & Rail, multimodal trip planning, and geocoding
This server demonstrates solid definition quality across 15 tools with good naming consistency, mostly complete parameter schemas, and reasonable descriptions. All tools follow a consistent verb_noun pattern (road_*) which aids discoverability. Most tools have structured input schemas with proper types and constraints. However, there are gaps: output schemas are not explicitly documented (critical for agent planning), several parameters lack sufficient description detail, and error handling/recovery guidance is minimal. The implementation shows architectural maturity (HTTP transport, proper lifespan management, security middleware) but the tool definitions themselves could be optimized for LLM reasoning, descriptions are often technical API documentation rather than LLM-optimized prose that explains WHEN and WHY to call each tool.
Get real-time status and availability of a specific EV charging station
System status check - verify that all Phase 1 services are operational
Official road classification via swissTLM3D (swisstopo)
List all available traffic counter measurement sites in Switzerland
Find nearby EV charging stations with real-time availability
Find nearby shared mobility vehicles/stations (bikes, e-bikes, e-scooters, cars, etc.) within a specified radius and optional filters
Swiss address geocoding from official federal registry (swisstopo/geo.admin.ch)
Output schemas not documented for any tool. LLMs cannot plan downstream calls or extract needed fields without knowing what structure each tool returns. This violates pattern:tool and mxe:response-field-naming, critical for agent reasoning.
Tool descriptions are often technical API documentation rather than LLM-optimized prose. They lack guidance on WHEN to use each tool, what problem it solves, and how it differs from similar tools. E.g. 'road_check_status' description is extremely terse (55 chars). Should explain: when to call this (is it a liveness probe or a data validation step?), what the result means, what to do if it fails.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | 1.0.0+ | v1 |
Complete mobility snapshot for a location - combines all mobility data sources (sharing, charging, park & rail, etc.)
Multimodal trip planner combining car, Park & Rail, public transport, and other mobility options
Find Park & Rail facilities at Swiss train stations (SBB Open Data)
Reverse geocoding to nearest official address (geo.admin.ch/swisstopo)
Search for shared mobility stations/providers by name or text
List all shared mobility providers available in Switzerland
Get real-time vehicle counts from Swiss traffic measurement sites
Retrieve current traffic events, accidents, roadworks, and delays (DATEX II data from ASTRA/VMZ-CH)
Several parameters lack detailed descriptions or format guidance. Examples: 'site_id' in road_traffic_counters is described as 'Specific measurement site ID, or null for all', no guidance on format, how to discover IDs, or whether null is the discovery mechanism. 'search_text' parameters provide no examples of what queries return good results.
No error handling or recovery guidance visible in descriptions. Pattern:recovery-guide and pattern:error-classification require that error responses tell the LLM what to do next. These tools are read-only (low risk), but a production agent needs to know: what if an external API times out? What if coordinates are invalid? Return structured error guidance, not generic HTTP codes.
Composition and tool-chaining not optimized. If road_geocode_address returns lat/lon coordinates, tools like road_find_sharing should accept those directly without requiring the agent to map the response fields. Response should be shaped to feed directly into downstream tools (mxe:include-chaining-ids pattern).
Pagination not visible for potentially large result sets. Tools like road_traffic_situations, road_counter_sites, road_find_sharing could return hundreds of items. Pattern:paginated-result requires limit/offset or cursor-based pagination to avoid context window explosion. No limit parameter visible in road_find_charger or road_traffic_situations descriptions.
Parameter naming could be more consistent with mxe:natural-identifiers. Some tools accept 'latitude'/'longitude' while others might benefit from accepting place names or addresses. Road tools should prefer human-friendly identifiers (city name, address) with fallback to coordinates, reducing discovery/lookup call overhead.