Skip to main content
Glama
pierre-phu

swiss-outdoor-mcp

by pierre-phu

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 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.

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
ResponsivenessNo issues

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
    B
    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
    31 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