Skip to main content
Glama
pierre-phu

swiss-outdoor-mcp

by pierre-phu

swiss-outdoor-mcp

CI

An MCP server that gives an LLM client reliable, computed facts for planning Swiss mountain outings by public transport. The v0.1 use case is paragliding:

"Saturday, from Lausanne, where can I go paragliding by train?"

The server does not answer that question. It provides the deterministic pieces — launch sites, ensemble-based flyability probabilities, train connections — and the LLM composes them. There are no LLM calls inside the server.

Status

Work in progress towards v0.1; the current pre-release is 0.1.0a1. Working today: list_sites, get_flyability and get_connections. Still to come: estimate_trip_co2, offline fixture mode and the eval harness. See docs/SPEC.md.

Related MCP server: mcp-camptocamp

Example

A real get_flyability call for the Fiesch launch (Valais, faces SE–SW, 2163 m), made on 2026-09-25 for the next day. The hourly list is trimmed to its first and last hours; the real response has all eight, 10:00 to 17:00.

{
  "site_id": "fiesch",
  "date": "2026-09-26",
  "p_flyable": 1.0,
  "hourly": [
    {
      "time": "2026-09-26T10:00:00+02:00",
      "p_wind_ok": 1.0,
      "p_gust_ok": 1.0,
      "p_dry": 1.0,
      "p_direction_ok": 1.0,
      "p_flyable": 1.0,
      "wind_kmh": { "median": 1.8, "p10": 1.6, "p90": 2.5 }
    },
    {
      "time": "2026-09-26T17:00:00+02:00",
      "p_wind_ok": 1.0,
      "p_gust_ok": 1.0,
      "p_dry": 1.0,
      "p_direction_ok": 1.0,
      "p_flyable": 1.0,
      "wind_kmh": { "median": 8.6, "p10": 7.4, "p90": 10.8 }
    }
  ],
  "model": "icon_d2_eps",
  "n_members": 20,
  "grid_elevation_m": 2173.0,
  "criteria": {
    "max_wind_kmh": 20.0,
    "max_gust_kmh": 30.0,
    "max_precip_mm_h": 0.1,
    "direction_tolerance_deg": 45.0,
    "window_start": "10:00:00",
    "window_end": "17:00:00",
    "min_consecutive_hours": 3
  },
  "method": "Each of the 20 members of the icon_d2_eps ensemble is checked hour by hour against the criteria (all limits inclusive; wind 10 m above the model's terrain). Hourly p_* values are the share of members meeting each criterion. The day-level p_flyable is the share of members with at least 3 consecutive flyable hours between 10:00 and 17:00 Europe/Zurich, both ends included.",
  "generated_at": "2026-09-25T16:19:01+02:00",
  "disclaimer": "Indicator only, computed from a weather-model ensemble. It does not replace pilot judgment, an on-site assessment of conditions, or official aviation weather forecasts.",
  "attribution": "Weather data by Open-Meteo.com (https://open-meteo.com/), CC BY 4.0."
}

How to read it:

  • p_flyable: 1.0 means all 20 ensemble members have at least 3 consecutive hours inside the criteria. It is a share of members, not a calibrated probability.

  • model says which ensemble answered: the 2 km icon_d2_eps (20 members) for today and tomorrow, the 13 km icon_eu_eps (40 members) further out.

  • grid_elevation_m is the altitude of the model cell. Here it is 10 m from the real launch; on other sites the gap can be hundreds of metres.

  • The LLM client is expected to pass disclaimer and attribution on to the user.

Install and run

uv sync
uv run swiss-outdoor-mcp     # speaks MCP over stdio

Development

uv run ruff check . && uv run ruff format --check . && uv run mypy src && uv run pytest

See CONTRIBUTING.md. Verified facts about every upstream API live in docs/api-notes.md — read it before touching a client.

Limitations

This is not a flight-safety tool. Flyability output is an indicator built from a public weather model; it does not replace pilot judgment, a site briefing, or official aviation weather.

  • p_flyable is the share of ensemble members that agree, not a calibrated probability.

  • Winds are 10 m above the model's terrain, not at launch height. The model cell can sit hundreds of metres from the real launch altitude; grid_elevation_m reports it. No thermals, no foehn, no upper winds.

  • Near-calm hours can score low: the direction check applies whatever the wind speed, so a 1 km/h breeze from the wrong side fails it.

  • The forecast reaches about four days out. The exact horizon moves with each model run and is read from every response.

  • The sites' access_notes (the last leg from the stop to the launch) are not filled in yet.

Data sources

  • Weather: Open-Meteo Ensemble API — weather data by Open-Meteo.com, CC BY 4.0.

  • Public transport: transport.opendata.ch (an unofficial API over the Swiss timetable; its terms of use are not stated — see docs/api-notes.md).

Licence

MIT — see LICENSE.

Available Tools

1 tool
pingA
Read-onlyIdempotent

Check that the swiss-outdoor-mcp server is reachable and report its version.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the useful behavioral detail that it reports a version, which is meaningful context beyond the annotations.

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, information-dense sentence expresses both the operation and the output. There is no redundancy or filler.

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

Completeness5/5

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

For a parameter-less, read-only, idempotent tool with an output schema, the description fully covers what an agent needs to select and invoke it correctly.

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 are zero parameters, so there is nothing for the description to explain. The baseline of 4 is appropriate because no parameter ambiguity exists.

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 ('Check') and a clear resource ('swiss-outdoor-mcp server'), and explicitly states the outcome ('report its version'). This leaves no ambiguity about what the tool does.

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 intended usage—checking server reachability—is clearly implied by the description. There are no sibling tools or alternatives to distinguish, so explicit exclusion guidance is unnecessary.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedping

TDQS

A4.1/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool in the set, there is no possible ambiguity or overlap. The ping tool is the sole functionality, so an agent cannot confuse it with anything else.

Naming Consistency5/5

There is only one tool named 'ping', which is a standard, clear health-check convention. With no other tools, there is no pattern to violate, so consistency is effectively perfect.

Tool Count1/5

A server named swiss-outdoor-mcp with only a ping health check has a severe mismatch between its apparent purpose and its actual tool surface. One trivial tool is far too few for the implied domain.

Completeness1/5

The server's name suggests it should cover Swiss outdoor activities, but the only tool is a reachability check. There is no actual domain functionality, leaving every conceivable outdoor use case unsupported.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    Lets an LLM plan hikes anywhere in Switzerland by combining named routes, elevation profiles, weather forecasts, and public transport.
    7
    -
  • A
    license
    A
    quality
    C
    maintenance
    Exposes the Camptocamp.org API to LLMs, enabling querying of alpine routes, summit altitudes, and course descriptions with reliable data to avoid hallucinations.
    6
    44 npm
    1
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Provides real-time Swiss railway information including departures, connections, train composition, occupancy forecasts, disruptions, and pricing, accessible via natural language in over 100 languages.
    MIT