swiss-outdoor-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@swiss-outdoor-mcpList paragliding launch sites reachable by train from Lausanne, with Saturday flyability."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
swiss-outdoor-mcp
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
Day 1 of a 5-day build: project scaffold, a ping tool and the data schemas. The real tools
(list_sites, get_flyability, get_connections, estimate_trip_co2) land on days 2–4.
See docs/SPEC.md.
Related MCP server: mcp-camptocamp
Install and run
uv sync
uv run swiss-outdoor-mcp # speaks MCP over stdioDevelopment
uv run ruff check . && uv run ruff format --check . && uv run mypy src && uv run pytestSee 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.
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 toolpingARead-onlyIdempotent
Check that the swiss-outdoor-mcp server is reachable and report its version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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 tool update
v0.1.0- First observed
ping
TDQS
Scored across 1 tool
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.
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.
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.
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
Related MCP Connectors
Swiss weather data for AI assistants — forecasts, measurements, stations, pollen.
Canonical SwissTrip MCP — independent SBB/CFF/FFS schedules, prices, and ticket links by SwissTrip.
Swiss Transport MCP — wraps Transport Open Data API (free, no auth)
Swiss federal law (Fedlex) and political data (LINDAS) for agents, every answer with sources
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceLets an LLM plan hikes anywhere in Switzerland by combining named routes, elevation profiles, weather forecasts, and public transport.7-
- AlicenseAqualityBmaintenanceExposes the Camptocamp.org API to LLMs, enabling querying of alpine routes, summit altitudes, and course descriptions with reliable data to avoid hallucinations.631 npm1MIT
- AlicenseNot gradedqualityBmaintenanceProvides real-time Swiss railway information including departures, connections, train composition, occupancy forecasts, disruptions, and pricing, accessible via natural language in over 100 languages.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to explore Swiss hiking routes with real-time closures, weather, public transport, and POIs, including GPX generation.1MIT