MCP server for planning hikes in Switzerland — Wanderland routes, elevation, weather, public transport.
bergauf demonstrates good overall definition quality with consistent tool naming, comprehensive parameter schemas, and clear descriptions. All 7 tools are properly registered with input/output schemas and annotations. Tool names follow verb_noun conventions (search_location, list_named_routes, get_named_route, etc.). Descriptions are specific and actionable, averaging ~120 chars. Parameters include proper type constraints, ranges (e.g., limit 1-20, days 1-10), and descriptions. However, several tools lack crucial detail about error handling and recovery paths. The jsonTool wrapper shows thoughtful error handling in implementation but isn't fully reflected in tool descriptions. Output schemas are defined but not deeply validated in the source. Most parameter descriptions are adequate but could be more explicit about edge cases (e.g., what happens if search_location finds zero results?).
Hourly + daily weather forecast for a WGS84 point, using the MeteoSwiss ICON seamless model via Open-Meteo. Use the trailhead coordinates.
Given a WGS84 GeoJSON LineString (usually the geometry from get_named_route), return distance, ascent, descent, max/min elevation, elevation samples, and an estimated walking time using the SAC/DAV formula.
Fetch a single Wanderland route by its feature id (as returned by list_named_routes). Returns attributes (name, number, category, length) and the full geometry (LineString or MultiLineString).
List named SwitzerlandMobility (Wanderland) hiking routes — national, regional, and local. Pass a WGS84 bbox to narrow down to a region; otherwise queries all of Switzerland.
Find public transport stations (train/bus/tram) near a WGS84 point. Useful for finding a trailhead station or the nearest stop to a finish point.
Plan a Swiss public transport connection between two stations or addresses. Specify either when to depart (mode="departure") or when to arrive (mode="arrival").
Output schema documentation is incomplete. While outputSchema objects are defined in src/tools/index.ts (searchLocationOutput, listNamedRoutesOutput, etc.), the actual shape of these schemas is not visible in the provided source. This prevents validation that response fields match input requirements for tool chaining.
Error handling descriptions are absent or minimal. Tool descriptions do not explain what happens on error (e.g., if search_location returns zero results, if forecast fails for out-of-bounds coordinates, if plan_transit has no viable connections). The jsonTool wrapper catches errors and returns isError=true, but LLMs need recovery guidance in the tool description itself.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 73 | 2025-06-18+ | v2 |
Resolve a free-text Swiss place name (town, mountain, station, address) to coordinates. Always use this first when the user mentions a place.
Parameter dependency documentation is missing. For example, get_hike_profile expects a GeoJSON LineString 'type: LineString', but there's no explicit description noting that other geometry types (Polygon, MultiLineString) will be rejected or how to convert them. The 'includeGeometryWgs84' parameter behavior isn't fully explained (what format is returned if false?).
No explicit guidance on tool composition flow. While the server instructions in index.ts mention the typical flow (search → list → get → profile → stations → transit → forecast), individual tool descriptions lack explicit cross-references (e.g., 'search_location does not return route data; use list_named_routes next'). This forces LLMs to infer the correct sequence.
Pagination behavior is not explicit. list_named_routes accepts a 'limit' parameter (default 50, max 200), but there is no description of what happens if more results exist beyond the limit. No 'next_cursor', 'total_count', or 'has_more' field is documented in the output schema (which is not visible in the source).
Parameter edge cases are underdocumented. For 'nbPoints' in get_hike_profile, what happens if the LineString has fewer points than nbPoints? For 'days' in forecast, what is the range of valid dates? Can you forecast 10 days in the past? For 'date' in plan_transit, what is the cutoff (e.g., 30 days ahead only)?