What can you do with this server?

This server provides access to Swiss weather and climate data from MeteoSwiss, enabling AI agents to query real-time observations, forecasts, climate normals, and weather warnings. * List weather stations: Browse the SwissMetNet (SMN) measurement station list, filterable by canton, to find station codes for use with other tools. * Get current observations: Retrieve live 10-minute interval weather readings (temperature, precipitation, sunshine, wind, humidity, pressure) for any SwissMetNet station. * Get weather forecasts: Fetch 1–16 day forecasts for any location (by name or coordinates) using the MeteoSwiss ICON-CH1/CH2-EPS model, with optional hourly breakdown. * Check suitability for outdoor school events: Get a 🟢/🟡/🔴 traffic-light assessment for outdoor activities (e.g., sports days, field trips) based on temperature, precipitation, wind, and UV thresholds — for the next 7 days or a specific date. * Retrieve climate normals: Access monthly 30-year climate averages (1991–2020) for temperature, precipitation, and sunshine hours at key Swiss stations. * Check weather warnings: Retrieve current MeteoSwiss weather warnings (storms, heavy rain, thunder, snow, heat, frost, etc.) with official warning maps and MeteoAlarm links, filterable by canton.

How do I use meteoswiss-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@meteoswiss-mcp What's the current weather in Zurich?" 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.

en es

meteoswiss-mcp

by malkreide

Overview Schema Related Servers Score Discussions

Python

Hybrid

🌦️ meteoswiss-mcp

PyPI Python License: MIT swiss-public-data-mcp

MCP server for Swiss weather and climate data from MeteoSwiss.

Connects AI models to the SwissMetNet measurement network (160+ stations, 10-minute interval), MeteoSwiss ICON-CH1/CH2-EPS forecasts and climate normals 1991–2020. Part of the swiss-public-data-mcp portfolio.

🇩🇪 Deutsche Version

Demo query (anchor example)

How suitable is next Wednesday for the sports day at Leutschenbach school?

→ meteo_school_check(location="Zürich Oerlikon", activity="Sporttag") returns a 🟢/🟡/🔴 traffic light for each day of the coming week — straight from the MeteoSwiss ICON model.

Combined with swiss-environment-mcp:

How were air quality and weather at Leutschenbach school yesterday?

→ meteo_current(station='REH') + env_nabel_current(station='ZUE') = a complete environmental picture. → More use cases by audience →

Related MCP server: Open-Meteo MCP Server

Tools (6)

Tool	Description	Data source
`meteo_stations`	List SwissMetNet stations (filterable by canton)	Embedded
`meteo_current`	Current 10-min observations for a station	BGDI STAC API
`meteo_forecast`	1–16 day forecast for a place or coordinates	Open-Meteo / MeteoSwiss ICON
`meteo_school_check`	🟢/🟡/🔴 traffic light for outdoor school events	Open-Meteo / MeteoSwiss ICON
`meteo_climate_normals`	Monthly climate normals 1991–2020	Embedded (KLO, SMA, BER, LUG, GVE)
`meteo_warnings`	Active official weather warnings (storm, thunderstorm, heat, forest fire, …) — nationwide, by canton, or by PLZ	MeteoSwiss App-API + opendata.swiss

Tool annotations (MCP hints)

All tools carry explicit MCP annotations — relevant for the client approval UI and for the LLM's safety decisions.

Tool	`readOnlyHint`	`destructiveHint`	`idempotentHint`	`openWorldHint`
`meteo_stations`	✅	✗	✅	✗ (curated list)
`meteo_current`	✅	✗	✗ (live data)	✅ (upstream STAC)
`meteo_forecast`	✅	✗	✗ (live data)	✅ (upstream Open-Meteo)
`meteo_school_check`	✅	✗	✗ (live data)	✅ (geocoding + forecast)
`meteo_climate_normals`	✅	✗	✅	✗ (embedded normals)
`meteo_warnings`	✅	✗	✗ (live data)	✅ (MeteoSwiss App-API)

Read rules: all 6 tools are readOnly + non-destructive — the server fundamentally cannot write or delete anything. idempotentHint=False marks tools that return different values depending on when they are called.

MCP protocol version

Aspect	Value
Tested spec versions	`2024-11-05`, `2025-03-26`, `2025-06-18` (via the `mcp[cli]` SDK)
MCP SDK version	see `pyproject.toml` → `mcp[cli]>=2.0.0,<3` (the `MCPServer` API from `mcp.server.mcpserver`)
Update policy	Dependabot watches `mcp[cli]`; spec bumps are documented in the CHANGELOG with a "Tool Definition Changes" marker

→ Full roadmap & update strategy: docs/roadmap.md

Quick start

Claude Desktop

{
  "mcpServers": {
    "meteoswiss": {
      "command": "uvx",
      "args": ["meteoswiss-mcp"]
    }
  }
}

Claude Desktop (local development)

{
  "mcpServers": {
    "meteoswiss": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/meteoswiss-mcp", "meteoswiss-mcp"]
    }
  }
}

Cloud / Render.com (Streamable HTTP)

Configuration via ENV variables (the CLI flags --http / --port N still work as an override):

Variable	Default	Meaning
`MCP_TRANSPORT`	`stdio`	`stdio` or `streamable-http`
`MCP_HOST`	`127.0.0.1`	Bind address — never change locally
`MCP_PORT`	`8000`	Port
`MCP_ALLOW_ANY_HOST`	unset	Must be set to `1` to allow the server to bind to `0.0.0.0` (containers/cloud only)
`MCP_LOG_LEVEL`	`INFO`	`DEBUG` / `INFO` / `WARNING` / `ERROR` — structured JSON logs on stderr
`MCP_ALLOWED_ORIGINS`	unset	Comma-separated list of allowed origins for CORS. Empty = CORS disabled (same-origin only). `Mcp-Session-Id` is exposed automatically.
`MCP_API_KEY`	unset	If set: every request except `/health` requires `X-API-Key: <key>` or `Authorization: Bearer <key>`. Constant-time comparison.
`MCP_STATELESS_HTTP`	`0`	`1` enables the SDK's stateless mode → each HTTP request opens a new session. Prerequisite for multi-replica deploys without sticky sessions (SCALE-002/003).
`OTEL_EXPORTER_OTLP_ENDPOINT`	unset	If set + `pip install meteoswiss-mcp[otel]`: OpenTelemetry spans per tool call + automatic httpx instrumentation are sent as OTLP-HTTP to the collector.
`OTEL_SERVICE_NAME`	`meteoswiss_mcp`	Service name in the OTel resources
`MCP_CACHE_ENABLED`	`1`	`0` disables the TTL cache entirely (e.g. for end-to-end tests)
`MCP_CACHE_TTL_STAC`	`300`	TTL in seconds for STAC SMN observations (default 5 min)
`MCP_CACHE_TTL_OPEN_METEO`	`600`	TTL for ICON forecasts (default 10 min)
`MCP_CACHE_TTL_GEOCODING`	`3600`	TTL for geocoding lookups (default 1 h)
`MCP_CACHE_TTL_OPENDATA`	`3600`	TTL for the opendata.swiss catalogue (default 1 h)
`MCP_CACHE_TTL_WARNINGS`	`300`	TTL for warnings (MeteoSwiss App-API / structured override; default 5 min)
`MCP_CLIMATE_NORMALS_PATH`	unset	Path to a JSON file with additional climate normals — see `data/climate-normals.example.json`
`MCP_WARNINGS_API_URL`	unset	Override for the default MeteoSwiss App-API source: URL of a structured MeteoSwiss warnings API (e.g. the future OGD warnings REST endpoint). The host must be on the egress allow-list. Schema-tolerant (GeoJSON `features`, a `warnings` array or `items`). Unset → live App-API.
`MCP_CLIMATE_NORMALS_URL_TEMPLATE`	unset	URL template for runtime lookup of climate normals (for stations without embedded or JSON values). Tokens: `{station}` (lowercase), `{STATION}` (uppercase), `{param}` (MeteoSwiss code `tre200m0`/`rre150m0`/`sre000m0`). Example: `https://data.geo.admin.ch/.../{station}/{param}.txt`. The host must be on the egress allow-list.

# Local test (safe, loopback only)
MCP_TRANSPORT=streamable-http meteoswiss-mcp

# Container / Render
MCP_TRANSPORT=streamable-http MCP_HOST=0.0.0.0 MCP_ALLOW_ANY_HOST=1 meteoswiss-mcp

Docker / Render

The repo includes a production-ready multi-stage Dockerfile (non-root user, HEALTHCHECK) and a render.yaml blueprint:

# Build + test locally
docker build -t meteoswiss-mcp .
docker run --rm -p 8000:8000 meteoswiss-mcp
curl http://127.0.0.1:8000/health   # → {"status":"ok","service":"meteoswiss-mcp"}

On Render: "New → Blueprint" → select the repo. Defaults (plan starter, Frankfurt, single instance) are set in render.yaml.

Important: numInstances: 1 is set deliberately — sticky-session routing for multi-replica (audit SCALE-002/003) is not yet implemented.

Structured logging

All tool invocations, upstream failures and egress blocks are emitted as JSON events on stderr (stdio-transport safe). Example:

{"tool": "meteo_forecast", "days": 7, "has_coords": false, "event": "tool_invoked", "level": "info", "timestamp": "2026-05-20T07:00:00Z"}
{"tool": "meteo_forecast", "endpoint": "geocoding", "error_type": "HTTPStatusError", "event": "upstream_failed", "level": "warning", "timestamp": "..."}
{"url": "https://evil.example.com/", "method": "GET", "reason": "host not in allow-list", "event": "egress_blocked", "level": "warning", "timestamp": "..."}

HTTP-mode security

MCP_HOST deliberately defaults to 127.0.0.1 so that --http on a dev laptop is not accidentally exposed to the local subnet (audit finding SEC-016).
All outgoing HTTP calls (including redirect follows) are validated against an allow-list: data.geo.admin.ch, api.open-meteo.com, geocoding-api.open-meteo.com, opendata.swiss. Other hosts and IP literals (in particular 169.254.169.254, RFC1918) are rejected with EgressBlocked (SEC-004 / SEC-021).
CORS: disabled by default (same-origin only). Browser clients (e.g. claude.ai web) need MCP_ALLOWED_ORIGINS=<csv> — the Mcp-Session-Id header is then automatically in Access-Control-Expose-Headers (SDK-004).
API-key auth: disabled by default. In a production HTTP setup, always set MCP_API_KEY=<random> — requests without a valid X-API-Key or Authorization: Bearer … are rejected with 401 (SEC-009 / SEC-013). /health stays open for container health probes.

Example: production HTTP stack

# 32 bytes of randomness as the auth key
export MCP_API_KEY=$(python -c "import secrets; print(secrets.token_urlsafe(32))")

MCP_TRANSPORT=streamable-http \
MCP_HOST=0.0.0.0 \
MCP_ALLOW_ANY_HOST=1 \
MCP_ALLOWED_ORIGINS=https://app.example.com \
MCP_API_KEY="$MCP_API_KEY" \
meteoswiss-mcp

Example queries

School planning

Which days next week are suitable for a sports day in Zürich?
→ meteo_school_check(location="Zürich", activity="Sporttag")

What will the weather be at Leutschenbach school on Friday?
→ meteo_forecast(location="Zürich Oerlikon", days=5)

Show me current readings from the nearest MeteoSwiss station to Zürich-Schwamendingen.
→ meteo_current(station="REH")

Climate comparison

How much rain normally falls in June in Zürich?
→ meteo_climate_normals(station="KLO")

Is Lugano really much sunnier than Zürich? Show me the annual values.
→ meteo_climate_normals(station="LUG") + meteo_climate_normals(station="SMA")

Infrastructure & environment

Are there currently any weather warnings for the canton of Zürich?
→ meteo_warnings(canton="ZH")

Show me a 10-day forecast for the Heerenschürli sports facility with hourly values.
→ meteo_forecast(location="Sportanlage Heerenschürli Zürich", days=10, hourly=True)

Architecture

Claude Desktop / AI agent
        │
        │ MCP (stdio / Streamable HTTP)
        ▼
meteoswiss-mcp (MCPServer)
        │
        ├── meteo_stations ──────────────── [embedded: ~20 SMN stations]
        │
        ├── meteo_current ───────────────── BGDI STAC API
        │                                   data.geo.admin.ch/api/stac/v1
        │                                   Collection: ch.meteoschweiz.ogd-smn
        │
        ├── meteo_forecast ──────────────── Open-Meteo
        ├── meteo_school_check ──────────── api.open-meteo.com/v1/meteoswiss
        │                                   (MeteoSwiss ICON-CH1/CH2-EPS, 1–2 km)
        │
        ├── meteo_climate_normals ───────── [embedded: normals 1991–2020]
        │
        └── meteo_warnings ──────────────── app-prod-ws.meteoswiss-app.ch
                                            (MeteoSwiss App-API) + opendata.swiss

Data sources

Source	URL	License
BGDI STAC API (MeteoSwiss OGD)	`data.geo.admin.ch/api/stac/v1`	CC BY 4.0
Open-Meteo (MeteoSwiss ICON)	`api.open-meteo.com/v1/meteoswiss`	CC BY 4.0
Open-Meteo Geocoding	`geocoding-api.open-meteo.com`	CC BY 4.0
opendata.swiss CKAN	`opendata.swiss/api/3/action`	CC BY 4.0
MeteoSwiss App-API (warnings)	`app-prod-ws.meteoswiss-app.ch/v1/plzDetail`	CC BY 4.0

Safety & limits

Aspect	Details
Access	Read-only (`readOnlyHint: true` on all tools) — the server cannot modify or delete any data
Personal data	No personal data — all sources are aggregated, publicly available open data
Rate limits	Built-in per-query caps: max 50 results per API call, 30 s timeout
Authentication	No API keys required — all data sources are publicly accessible
Licenses	All data under CC BY 4.0 (MeteoSwiss Open Government Data)
Terms of Service	Subject to the ToS of the respective data sources: MeteoSwiss OGD, Open-Meteo, opendata.swiss

Known limitations

ID	Tool	Description
BUG-01	`meteo_current`	STAC asset structure can vary per station; fallback to a direct link is implemented
LIM-01	`meteo_climate_normals`	Only 5 stations embedded (KLO, SMA, BER, LUG, GVE); the rest via an opendata.swiss link
LIM-02	`meteo_warnings`	Live warnings come from the MeteoSwiss App-API (`plzDetail`) — public and unauthenticated, but undocumented (mobile-app backend, not the OGD REST API). There is no nationwide endpoint, so the countrywide view aggregates one representative capital PLZ per canton (sub-regional warnings outside that PLZ may be missed — narrow with `plz`/`canton`). `MCP_WARNINGS_API_URL` overrides it once the official OGD warnings REST API ships.
LIM-03	`meteo_current`	Shows 10-min values in UTC; no automatic conversion to local time

Responsibility matrix — snow & precipitation (delineation vs. `swiss-environment-mcp`)

To avoid duplicating snow and precipitation data across the portfolio, responsibilities are split as follows. meteoswiss-mcp owns atmospheric precipitation and weather; swiss-environment-mcp (SLF domain) owns snow on the ground and avalanche danger.

Data	meteoswiss-mcp (MeteoSwiss)	swiss-environment-mcp (BAFU / SLF)
Precipitation amount (mm): measurement network, forecast, climate normals	✅ `meteo_current` / `meteo_forecast` / `meteo_climate_normals`	❌
Snowfall as a current weather condition	✅ `meteo_current` / `meteo_forecast` (weather code)	❌
Weather warnings (storm, thunderstorm, heat)	✅ `meteo_warnings`	❌
Snow depth on the ground (`HS`)	❌	✅ SLF IMIS / study-plot ¹
Fresh snow 24 h (`HN_1D`)	❌	✅ SLF ¹
Avalanche danger level	❌	✅ SLF avalanche bulletin ¹
Natural-hazard warnings (flood, avalanche, wildfire)	❌	✅ `env_flood_warnings`, `env_hazard_*`, `env_wildfire_danger`

Rule: atmospheric precipitation (rain/snowfall as mm) plus weather, forecast, warnings and climate normals belong to meteoswiss-mcp; snow on the ground and avalanche danger belong to swiss-environment-mcp (SLF). The SLF IMIS precipitation sensor is used there only as context for the snowpack and is never exposed as a precipitation tool, so it does not duplicate MeteoSwiss.

¹ SLF/snow tools in swiss-environment-mcp are in preparation (Phase-1 live-probe completed 2026-07-19, see that repo's docs/probe-slf.md); the demarcation is fixed now so the two servers do not collide once implemented.

Portfolio synergies

meteoswiss-mcp
    │
    ├── swiss-environment-mcp   Combine weather + air quality (NABEL)
    │                           "How were weather AND air at Leutschenbach school?"
    │
    └── zurich-opendata-mcp     School locations → weather forecast
                                "Which schools in Zürich have sports-day weather?"

MCP Protocol Version

This server speaks two protocol eras over the same endpoint. The client's first request on a connection decides which one applies; a later claim from the other era is refused.

Era	Revision	Who reaches it
`initialize` handshake	`2024-11-05` … `2025-11-25`	What today's clients speak. The server answers with the revision asked for, or with the `2025-11-25` ceiling when the request asks for something newer.
Per-request envelope	`2026-07-28`	A request carrying the `2026-07-28` `_meta` envelope opens a modern connection.

Both revisions are pinned in tests/test_protocol_version.py and asserted against the installed SDK, so a Dependabot bump of mcp cannot move either one silently. This server builds no ASGI app to send an initialize through, so the gate asserts the SDK constants rather than a measured response — the weaker form, named rather than left unsaid.

Note that the SDK's LATEST_PROTOCOL_VERSION is an alias for the modern era, not for the handshake era — pinning against it alone would leave the era that current clients actually negotiate free to drift.

Update policy. When the gate fails, do not edit the constant blindly: read the spec changelog between the two revisions, verify the server still behaves, then move the constant, this section, README.de.md and CHANGELOG.md together.

Testing

# Unit tests (no network)
PYTHONPATH=src pytest tests/ -m "not live" -v

# Live tests (real APIs) — also run daily at 05:17 UTC via
# .github/workflows/live-tests.yml, so a format change upstream
# surfaces even though the unit tests stay green.
PYTHONPATH=src pytest tests/ -m live -v

# Linting — install the local gates once with `pre-commit install`
# to run these (and the CI guards) before every commit.
ruff check src/ tests/ scripts/
ruff format --check src/ tests/ scripts/

Development

git clone https://github.com/malkreide/meteoswiss-mcp
cd meteoswiss-mcp
pip install -e ".[dev]"

MCP Inspector (local test)

PYTHONPATH=src npx @modelcontextprotocol/inspector python -m meteoswiss_mcp.server

Contributing

See the contributing guidelines (Deutsch).

Security

See the security policy (Deutsch) for the security posture and how to report a vulnerability.

License

MIT License – see LICENSE.

Source data: MeteoSwiss Open Government Data (CC BY 4.0). When using the data, cite: Source: MeteoSwiss.

Author

Hayal Oezkan · github.com/malkreide

swiss-environment-mcp zurich-opendata-mcp swiss-transport-mcp

Installation

Run via uv's uvx — no clone or manual install needed. Add to your MCP client config (mcpServers for Claude Desktop, Cursor and Windsurf; use a top-level servers key for VS Code in .vscode/mcp.json):

{
  "mcpServers": {
    "meteoswiss-mcp": {
      "command": "uvx",
      "args": [
        "meteoswiss-mcp"
      ]
    }
  }
}

Available Tools

6 tools

meteo_climate_normalsA

Read-onlyIdempotent

Args: params (ClimateNormalsInput): - station: SMN-Kürzel (z.B. 'KLO', 'SMA', 'BER') - response_format: 'markdown' oder 'json'

Returns: str: Monatliche Klimanormwerte-Tabelle 1991–2020.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds context that data is static and no network roundtrip is needed, reinforcing the annotations without contradiction.

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?

The description is well-structured with use_case, important_notes, and example sections. It is concise with no superfluous content.

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?

Given the tool's simplicity, the description covers all necessary aspects: purpose, period, embedded stations, fallback, idempotence, and examples. It is complete.

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?

The input schema already provides descriptions for parameters (station with examples, response_format as enum). The tool description adds examples and contextual notes (e.g., embedded stations), which supplement the schema.

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 clearly states the tool provides monthly 30-year climate normals for a MeteoSwiss station, including temperature, precipitation, and sunshine hours. It distinguishes itself from sibling tools like meteo_current and meteo_forecast by being a static reference for 'typical weather'.

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 description provides explicit use cases such as school planning, event budgeting, and comparison with current measurements. It also includes important notes about the period, embedded stations, and fallback behavior, but does not explicitly state when not to use or name alternatives.

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

meteo_currentA

Read-only

Args: params (CurrentInput): - station: SMN-Kürzel, z.B. 'KLO', 'SMA', 'REH', 'BER' - response_format: 'markdown' oder 'json'

Returns: str: Aktuelle Messwerte mit Zeitstempel, oder Fallback mit Direktlinks.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds that the tool is not idempotent and provides live data, plus a fallback behavior on upstream failure. This adds value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description uses structured XML-like tags for use case, notes, and example, making it easy to parse. It is not overly long but includes some redundancy (e.g., repeating '10-Minuten-Werte' in notes and example). Still well-organized.

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

Completeness4/5

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

The description covers the use case, important behavioral notes, and provides an example. The tool has an output schema, so return values are documented elsewhere. Missing details like exact number of observations or error handling, but overall sufficient for a simple data retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has descriptions for station and response_format. The tool description provides an example mapping a station code to a location, adding minimal extra meaning. With schema coverage indicated as 0%, the description does not fully compensate but the schema itself has some descriptions.

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 clearly states it retrieves current 10-minute weather measurements from a SwissMetNet station, listing measurement types (temperature, precipitation, etc.). It distinguishes from sibling tools (forecast, climate normals, etc.) by focusing on current observations.

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 description includes a use case tag and important notes (granularity, data source, idempotency) that provide context. However, it does not explicitly state when not to use this tool or contrast with siblings, though the sibling names imply differentiation.

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

meteo_forecastA

Read-only

Args: params (ForecastInput): - location: Ortsname (geokodiert) ODER lat/lon direkt - days: Prognosetage (1–16, Standard: 7) - hourly: True für Stundenwerte - response_format: 'markdown' oder 'json'

Returns: str: Tages- (und optional Stunden-)Prognose mit Wettercode und Planung.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds substantial behavioral context: the hybrid model source (ICON for first 5 days, best_match beyond), geocoding with fuzzy fallback, hourly data limitation to 48 hours, and direct-link fallback on upstream failure. It also discloses that responses include provenance fields (`modell`/`modell_details`). No contradiction with 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?

The description is well-organized with clear sections (use_case, important_notes, example, args, returns). Every section contributes value—purpose, behavioral nuances, invocation examples, and parameter explanations—without redundancy or padding. It is appropriately sized for the tool's complexity.

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?

The description covers all critical aspects: model provenance, geocoding fallback, hourly data range, failure handling, and response format. With an output schema present, the concise Returns statement suffices. The tool's complexity is fully addressed, leaving no significant gaps for an agent to misuse it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the top-level schema parameter has no description (0% coverage), the description explicitly enumerates each field under 'Args' and adds meaning beyond the nested schema: e.g., 'lat/lon überschreibt location und spart einen HTTP-Roundtrip' and explanation of response_format. The important_notes also clarify the geocoding behavior and hourly scope, fully compensating for the schema gap.

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 opens with a clear use case: '1-16 Tage Wetterprognose für einen Ortsnamen oder Koordinaten' and specifies output (daily values, optional hourly). It names the unique MeteoSwiss ICON model and lists distinct weather fields, making the tool's purpose unmistakable and distinguishing it from siblings like meteo_current or meteo_warnings.

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 description provides clear context for when to use (multi-day forecast, up to 16 days) and includes practical usage tips in important_notes (e.g., lat/lon overrides location and saves a roundtrip; hourly only covers first 48 hours). However, it does not explicitly mention alternatives or when-not-to-use scenarios, leaving sibling differentiation implicit.

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

meteo_school_checkA

Read-only

Args: params (SchoolCheckInput): - location: Ort (geokodiert), z.B. 'Zürich Oerlikon' - date: Optional – spezifischer Tag (YYYY-MM-DD) - activity: Art der Aktivität ('Sporttag', 'Schulreise', etc.)

Returns: str: Ampel-Bewertung für die nächsten 7 Tage (oder Einzeltag).

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds behavioral context: it explains internal steps (geocoding, forecast, threshold check) and sources (SUVA/BAG). It doesn't contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with tags (use_case, important_notes, example) which aids readability. It is somewhat lengthy but every section serves a purpose. Could be slightly more concise.

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

Completeness4/5

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

Given the tool's complexity (multi-step aggregation with thresholds), the description covers the key aspects: what it does, thresholds, date behavior, and examples. It assumes output schema exists, which is acceptable.

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?

While the schema descriptions provide good coverage (contradicting the 0% metric), the tool description adds value through examples and threshold context, clarifying how parameters influence results.

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 clearly states it aggregates geocoding, 7-day forecast, and threshold check into a traffic light rating for outdoor school events. It explicitly distinguishes itself from meteo_forecast by saying it replaces the combination of forecast plus manual evaluation.

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 description specifies when to use this tool (for school outdoor events) and mentions it replaces meteo_forecast plus manual evaluation. However, it does not explicitly list when not to use each sibling tool, leaving some ambiguity.

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

meteo_stationsA

Read-onlyIdempotent

Schul-Tipp: Station REH (Zürich/Affoltern) ist die nächste SMN-Station zum Schulhaus Leutschenbach.

Args: params (StationsInput): - canton: Kantonskürzel (z.B. 'ZH') – leer = alle - response_format: 'markdown' oder 'json'

Returns: str: Stationsliste mit Kürzel, Name, Kanton, Koordinaten und Höhe.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Description adds curated selection, school/urban focus, data source, and license beyond annotations. No contradictions with readOnlyHint=true, destructiveHint=false.

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?

Well-structured with sections (use_case, important_notes, example, args, returns). Every sentence adds value without being verbose.

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?

Comprehensive coverage of what the tool does, how to use it, and what it returns, given the output schema and annotations.

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?

Despite 0% schema coverage, description explains both parameters (canton and response_format) with examples and default behavior, adding meaning.

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?

Clearly states it lists SwissMetNet stations to find station abbreviations for meteo_current or meteo_climate_normals. Distinguishes from siblings by naming them directly.

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?

Explicitly says use to find station abbreviations for related tools. Provides example with canton filtering. Does not state when not to use, but context is clear.

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

meteo_warningsA

Read-only

Args: params (WarningsInput): - canton: Kantonskürzel zum Filtern (z.B. 'ZH') - plz: 4-stellige PLZ für ortsgenaue Warnungen (z.B. '8001') - language: 'de' | 'fr' | 'it' | 'en' (Sprache der Warntexte) - response_format: 'markdown' oder 'json'

Returns: str: Aktive Warnungen + Warnkarte/MeteoAlarm-Links.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false. Description adds behavioral details: live backend, no nationwide endpoint, aggregation logic, warning scale, and environment variable override. Provides substantial context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with <use_case>, <important_notes>, <example>, Args, Returns. Front-loaded with purpose. Slightly lengthy but each section earns its place. Could trim some notes.

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?

Covers usage, parameters, behavior, examples, and environment variable. Output schema exists for ResponseFormat. Complete for a live-data aggregation tool with multiple filtering options.

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?

Schema has descriptions for each parameter, but the description reinforces meaning: plz for precise location, canton for filtering, language, response_format. Adds value beyond schema (e.g., 'Präziser als canton'). Coverage signal 0% may be inaccurate, but description compensates.

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 clearly states it retrieves active official MeteoSwiss weather warnings live, and distinguishes from sibling tools (meteo_stations, meteo_current, etc.) which focus on other weather data.

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 <use_case> section explains when to use it (live warnings, nationwide, per canton, or per PLZ). Examples show different parameter combos. Sibling tool names imply alternatives, but no explicit when-not-to-use.

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. Dates show when Glama detected each change.

1 tool updatev0.4.0Jul 27, 2026

Changedmeteo_warnings2 fields changed

addedInput schema / $defs / WarningsInput / properties / language

Added value: +{
+  "default": "de",
+  "description": "Sprache der Warntexte: 'de', 'fr', 'it' oder 'en'.",
+  "maxLength": 2,
+  "title": "Language",
+  "type": "string"
+}

addedInput schema / $defs / WarningsInput / properties / plz

Added value: +{
+  "default": "",
+  "description": "4-stellige Schweizer PLZ für ortsgenaue Warnungen (z.B. '8001'). Präziser als 'canton'; leer = kanton- bzw. landesweite Aggregation.",
+  "maxLength": 4,
+  "title": "Plz",
+  "type": "string"
+}

6 tool updatesv0.3.0Jun 3, 2026
- First observedmeteo_climate_normals
- First observedmeteo_current
- First observedmeteo_forecast
- First observedmeteo_school_check
- First observedmeteo_stations
- First observedmeteo_warnings

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct meteorological resource: station metadata, current obs, forecasts, climate normals, warnings, and an aggregated school-specific check. There is no overlap or ambiguity between them.

Naming Consistency5/5

All six tools follow a consistent 'meteo_' prefix plus a clear noun or composite noun (stations, current, forecast, school_check, climate_normals, warnings). The pattern is uniform and predictable.

Tool Count5/5

Six tools provide a well-scoped coverage of weather data and domain-specific analysis for an MCP server focused on Swiss meteorology. No tool feels redundant and none are missing to justify a larger set.

Completeness4/5

The server covers the core weather workflows: station lookup, current conditions, forecasts, climatological normals, and warnings. A minor gap is the lack of historical actual observations (e.g., past dates), but the provided climate normals and current/forecast data cover typical planning needs.

Maintenance

ActivityActive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MeteoSwiss MCP Server A
io.github.eins78
Swiss weather data for AI assistants — forecasts, measurements, stations, pollen.
Weather Services Location Services Open Data
722
open-meteo-mcp-server A
io.github.cyanheads
Global weather via Open-Meteo: forecast, ERA5 archive, marine, air quality, geocoding, elevation.
Weather Services Location Services
1125
Weather A
io.github.pipeworx-io
Real-time weather conditions and multi-day forecasts via Open-Meteo — free, no API key required
Weather Services Search
342
Weather & Geo Intel MCP A
io.github.selflabbs
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
Weather Services Location Services
2

Related MCP Servers

LandiWetter MCP Server
Weather Services Search
nabossha
A
license
D
quality
D
maintenance
Provides Swiss weather forecast data, allowing users to search for Swiss locations and get detailed hourly and daily weather forecasts.
Updated a year ago (2025-05-06 15:19 UTC)
2
2
MIT
Open-Meteo MCP Server
Weather Services Location Services Search
cmer81
A
license
A
quality
A
maintenance
Provides comprehensive access to Open-Meteo APIs for weather forecasts, historical data, air quality, and marine conditions. It enables LLMs to query specialized meteorological models, perform geocoding, and access advanced climate or flood projections.
Updated a month ago (2026-07-25 22:24 UTC)
17
524
66
MIT
MeteoSwiss MCP Server
Weather Services Search Government Data
eins78
A
license
Not graded
quality
C
maintenance
Provides access to official MeteoSwiss weather data, including regional reports, daily forecasts, and website search functionality across multiple languages. It enables AI assistants to retrieve real-time weather information and documentation from MeteoSwiss using the Model Context Protocol.
Updated 6 days ago (2026-08-30 22:17 UTC)
2
Creative Commons Zero v1.0 Universal
meteo-swiss-mcp
Weather Services Open Data
cuolm
A
license
Not graded
quality
D
maintenance
Exposes Swiss weather forecast data as MCP tools, including rainfall, sunshine, temperature, wind, and more, with local caching.
Updated a year ago (2025-09-19 07:17 UTC)
1
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/malkreide/meteoswiss-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🌦️ meteoswiss-mcp

Demo query (anchor example)

Tools (6)

Tool annotations (MCP hints)

MCP protocol version

Quick start

Claude Desktop

Claude Desktop (local development)

Cloud / Render.com (Streamable HTTP)

Docker / Render

Structured logging

HTTP-mode security

Example: production HTTP stack

Example queries

School planning

Climate comparison

Infrastructure & environment

Architecture

Data sources

Safety & limits

Known limitations

Responsibility matrix — snow & precipitation (delineation vs. swiss-environment-mcp)

Portfolio synergies

MCP Protocol Version

Testing

Development

MCP Inspector (local test)

Contributing

Security

License

Author

Related servers

Installation

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Responsibility matrix — snow & precipitation (delineation vs. `swiss-environment-mcp`)