meteoswiss-mcp

Name: meteoswiss-mcp
Author: malkreide

by malkreide

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

🌦️ meteoswiss-mcp

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

Servidor MCP para datos meteorológicos y climáticos suizos de MeteoSwiss.

Conecta modelos de IA a la red de medición SwissMetNet (más de 160 estaciones, intervalo de 10 minutos), a los pronósticos ICON-CH1/CH2-EPS de MeteoSwiss y a las normales climáticas 1991–2020. Forma parte del portafolio swiss-public-data-mcp.

🇩🇪 Deutsche Version

Consulta de demostración (ejemplo de ancla)

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

→ meteo_school_check(location="Zürich Oerlikon", activity="Sporttag") devuelve un semáforo 🟢/🟡/🔴 para cada día de la próxima semana, directamente desde el modelo ICON de MeteoSwiss.

Combinado con swiss-environment-mcp:

How were air quality and weather at Leutschenbach school yesterday?

→ meteo_current(station='REH') + env_nabel_current(station='ZUE') = una imagen ambiental completa. → Más casos de uso por audiencia →

Related MCP server: Open-Meteo MCP Server

Herramientas (6)

Herramienta	Descripción	Fuente de datos
`meteo_stations`	Lista las estaciones SwissMetNet (filtrable por cantón)	Integrado
`meteo_current`	Observaciones actuales de 10 minutos para una estación	BGDI STAC API
`meteo_forecast`	Pronóstico de 1 a 16 días para un lugar o coordenadas	Open-Meteo / MeteoSwiss ICON
`meteo_school_check`	Semáforo 🟢/🟡/🔴 para eventos escolares al aire libre	Open-Meteo / MeteoSwiss ICON
`meteo_climate_normals`	Normales climáticas mensuales 1991–2020	Integrado (KLO, SMA, BER, LUG, GVE)
`meteo_warnings`	Avisos meteorológicos oficiales activos (tormenta, tormenta eléctrica, calor, incendio forestal, …) — en todo el país, por cantón o por PLZ	MeteoSwiss App-API + opendata.swiss

Anotaciones de herramientas (sugerencias MCP)

Todas las herramientas incluyen anotaciones MCP explícitas, relevantes para la interfaz de aprobación del cliente y para las decisiones de seguridad del LLM.

Herramienta	`readOnlyHint`	`destructiveHint`	`idempotentHint`	`openWorldHint`
`meteo_stations`	✅	✗	✅	✗ (lista curada)
`meteo_current`	✅	✗	✗ (datos en vivo)	✅ (STAC externo)
`meteo_forecast`	✅	✗	✗ (datos en vivo)	✅ (Open-Meteo externo)
`meteo_school_check`	✅	✗	✗ (datos en vivo)	✅ (geocodificación + pronóstico)
`meteo_climate_normals`	✅	✗	✅	✗ (normales integradas)
`meteo_warnings`	✅	✗	✗ (datos en vivo)	✅ (MeteoSwiss App-API)

Reglas de lectura: las 6 herramientas son readOnly + non-destructive — el servidor fundamentalmente no puede escribir ni eliminar nada. idempotentHint=False marca las herramientas que devuelven valores diferentes según cuándo se llaman.

Versión del protocolo MCP

Aspecto	Valor
Versiones de especificación probadas	`2024-11-05`, `2025-03-26`, `2025-06-18` (mediante el SDK `mcp[cli]`)
Versión del SDK de MCP	ver `pyproject.toml` → `mcp[cli]>=2.0.0,<3` (la API `MCPServer` de `mcp.server.mcpserver`)
Política de actualización	Dependabot vigila `mcp[cli]`; los cambios de especificación se documentan en el CHANGELOG con un marcador "Tool Definition Changes"

→ Hoja de ruta completa y estrategia de actualización: docs/roadmap.md

Inicio rápido

Claude Desktop

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

Claude Desktop (desarrollo local)

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

Nube / Render.com (Streamable HTTP)

Configuración mediante variables ENV (las banderas CLI --http / --port N siguen funcionando como anulación):

Variable	Predeterminado	Significado
`MCP_TRANSPORT`	`stdio`	`stdio` o `streamable-http`
`MCP_HOST`	`127.0.0.1`	Dirección de enlace: no cambiarla nunca en local
`MCP_PORT`	`8000`	Puerto
`MCP_ALLOW_ANY_HOST`	unset	Debe establecerse en `1` para permitir que el servidor se vincule a `0.0.0.0` (solo contenedores/nube)
`MCP_LOG_LEVEL`	`INFO`	`DEBUG` / `INFO` / `WARNING` / `ERROR`: registros JSON estructurados en stderr
`MCP_ALLOWED_ORIGINS`	unset	Lista separada por comas de orígenes permitidos para CORS. Vacío = CORS desactivado (solo mismo origen). `Mcp-Session-Id` se expone automáticamente.
`MCP_API_KEY`	unset	Si se establece: cada petición excepto `/health` requiere `X-API-Key: <key>` o `Authorization: Bearer <key>`. Comparación en tiempo constante.
`MCP_STATELESS_HTTP`	`0`	`1` activa el modo sin estado del SDK → cada petición HTTP abre una nueva sesión. Requisito previo para despliegues multi-réplica sin sesiones persistentes (SCALE-002/003).
`OTEL_EXPORTER_OTLP_ENDPOINT`	unset	Si se establece + `pip install meteoswiss-mcp[otel]`: los spans de OpenTelemetry por llamada a herramienta + la instrumentación automática de httpx se envían como OTLP-HTTP al recolector.
`OTEL_SERVICE_NAME`	`meteoswiss_mcp`	Nombre del servicio en los recursos de OTel
`MCP_CACHE_ENABLED`	`1`	`0` desactiva por completo la caché TTL (p. ej. para pruebas de extremo a extremo)
`MCP_CACHE_TTL_STAC`	`300`	TTL en segundos para las observaciones SMN de STAC (5 min por defecto)
`MCP_CACHE_TTL_OPEN_METEO`	`600`	TTL para los pronósticos ICON (10 min por defecto)
`MCP_CACHE_TTL_GEOCODING`	`3600`	TTL para las búsquedas de geocodificación (1 h por defecto)
`MCP_CACHE_TTL_OPENDATA`	`3600`	TTL para el catálogo de opendata.swiss (1 h por defecto)
`MCP_CACHE_TTL_WARNINGS`	`300`	TTL para los avisos (App-API de MeteoSwiss / anulación estructurada; 5 min por defecto)
`MCP_CLIMATE_NORMALS_PATH`	unset	Ruta a un archivo JSON con normales climáticas adicionales: consulte `data/climate-normals.example.json`
`MCP_WARNINGS_API_URL`	unset	Anulación de la fuente App-API de MeteoSwiss por defecto: URL de una API estructurada de avisos de MeteoSwiss (p. ej. el futuro endpoint REST de avisos OGD). El host debe estar en la lista de permitidos de salida. Tolerante al esquema (GeoJSON `features`, un array `warnings` o `items`). Sin establecer → App-API en vivo.
`MCP_CLIMATE_NORMALS_URL_TEMPLATE`	unset	Plantilla de URL para la consulta en tiempo de ejecución de normales climáticas (para estaciones sin valores integrados o JSON). Tokens: `{station}` (minúsculas), `{STATION}` (mayúsculas), `{param}` (código MeteoSwiss `tre200m0`/`rre150m0`/`sre000m0`). Ejemplo: `https://data.geo.admin.ch/.../{station}/{param}.txt`. El host debe estar en la lista de permitidos de salida.

# 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

El repositorio incluye un Dockerfile multi-etapa listo para producción (usuario no root, HEALTHCHECK) y una plantilla render.yaml:

# 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"}

En Render: «New → Blueprint» → seleccione el repositorio. Los valores predeterminados (plan starter, Frankfurt, instancia única) se establecen en render.yaml.

Importante: numInstances: 1 se establece deliberadamente: el enrutamiento de sesiones persistentes para multi-réplica (auditoría SCALE-002/003) aún no está implementado.

Registro estructurado

Todas las invocaciones de herramientas, fallos de servicios ascendentes y bloqueos de salida se emiten como eventos JSON en stderr (seguro para transporte stdio). Ejemplo:

{"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": "..."}

Seguridad en modo HTTP

MCP_HOST se fija deliberadamente a 127.0.0.1 para que --http en un portátil de desarrollo no quede expuesto accidentalmente a la subred local (hallazgo de auditoría SEC-016).
Todas las llamadas HTTP salientes (incluidos los redireccionamientos) se validan contra una lista de permitidos: data.geo.admin.ch, api.open-meteo.com, geocoding-api.open-meteo.com, opendata.swiss. Otros hosts y direcciones IP literales (en particular 169.254.169.254, RFC1918) se rechazan con EgressBlocked (SEC-004 / SEC-021).
CORS: desactivado por defecto (solo mismo origen). Los clientes de navegador (p. ej. claude.ai web) necesitan MCP_ALLOWED_ORIGINS=<csv>; el encabezado Mcp-Session-Id se incluye entonces automáticamente en Access-Control-Expose-Headers (SDK-004).
Autenticación por clave API: desactivada por defecto. En una configuración HTTP de producción, establezca siempre MCP_API_KEY=<random>: las peticiones sin una X-API-Key válida o Authorization: Bearer … se rechazan con 401 (SEC-009 / SEC-013). /health permanece abierto para las sondas de salud del contenedor.

Ejemplo: pila HTTP de producción

# 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

Ejemplos de consultas

Planificación escolar

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")

Comparación climática

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")

Infraestructura y entorno

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)

Arquitectura

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

Fuentes de datos

Fuente	URL	Licencia
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 (avisos)	`app-prod-ws.meteoswiss-app.ch/v1/plzDetail`	CC BY 4.0

Seguridad y límites

Aspect	Details
Acceso	Solo lectura (`readOnlyHint: true` en todas las herramientas): el servidor no puede modificar ni eliminar ningún dato
Datos personales	No se recopilan datos personales: todas las fuentes son datos abiertos agregados y disponibles públicamente
Límites de peticiones	Límites integrados por consulta: máx. 50 resultados por llamada a la API, tiempo de espera de 30 s
Autenticación	No se requieren claves de API: todas las fuentes de datos son de acceso público
Licencias	Todos los datos bajo CC BY 4.0 (MeteoSwiss Open Government Data)
Términos de servicio	Sujeto a los términos de servicio de las respectivas fuentes de datos: MeteoSwiss OGD, Open-Meteo, opendata.swiss

Limitaciones conocidas

ID	Herramienta	Descripción
BUG-01	`meteo_current`	La estructura de activos STAC puede variar según la estación; se implementa un respaldo a un enlace directo
LIM-01	`meteo_climate_normals`	Solo 5 estaciones integradas (KLO, SMA, BER, LUG, GVE); el resto mediante un enlace de opendata.swiss
LIM-02	`meteo_warnings`	Las alertas en vivo provienen de la API de la app MeteoSwiss (`plzDetail`), pública y sin autenticación, pero no documentada (backend de la app móvil, no la API REST OGD). No existe un endpoint nacional, por lo que la vista nacional agrega un PLZ capital representativo por cantón (las alertas subregionales fuera de ese PLZ pueden perderse: limite con `plz`/`canton`). `MCP_WARNINGS_API_URL` lo reemplaza cuando se publique la API REST oficial de alertas OGD.
LIM-03	`meteo_current`	Muestra valores de 10 minutos en UTC; sin conversión automática a la hora local

Matriz de responsabilidades: nieve y precipitación (delimitación frente a `swiss-environment-mcp`)

Para evitar duplicar los datos de nieve y precipitación en el portafolio, las responsabilidades se dividen de la siguiente manera. meteoswiss-mcp es responsable de la precipitación atmosférica y el tiempo; swiss-environment-mcp (dominio SLF) es responsable de la nieve en el suelo y del peligro de aludes.

Datos	meteoswiss-mcp (MeteoSwiss)	swiss-environment-mcp (BAFU / SLF)
Cantidad de precipitación (mm): red de medición, pronóstico, normales climáticas	✅ `meteo_current` / `meteo_forecast` / `meteo_climate_normals`	❌
Nevada como condición meteorológica actual	✅ `meteo_current` / `meteo_forecast` (código meteorológico)	❌
Avisos meteorológicos (tormenta, tormenta eléctrica, calor)	✅ `meteo_warnings`	❌
Altura de nieve en el suelo (`HS`)	❌	✅ SLF IMIS / parcela de estudio ¹
Nieve nueva en 24 h (`HN_1D`)	❌	✅ SLF ¹
Nivel de peligro de aludes	❌	✅ boletín de aludes SLF ¹
Avisos de peligros naturales (inundación, alud, incendio forestal)	❌	✅ `env_flood_warnings`, `env_hazard_*`, `env_wildfire_danger`

Regla: la precipitación atmosférica (lluvia/nieve en mm), junto con el tiempo, el pronóstico, los avisos y las normales climáticas, pertenecen a meteoswiss-mcp; la nieve en el suelo y el peligro de aludes pertenecen a swiss-environment-mcp (SLF). El sensor de precipitación SLF IMIS se utiliza allí solo como contexto para el manto de nieve y nunca se expone como herramienta de precipitación, por lo que no duplica a MeteoSwiss.

¹ Las herramientas SLF/nieve en swiss-environment-mcp están en preparación (sonda en vivo de la Fase 1 completada el 2026-07-19, consulte el docs/probe-slf.md de ese repositorio); la delimitación queda fijada ahora para que los dos servidores no colisionen una vez implementados.

Sinergias del portafolio

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?"

Pruebas

# 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/

Desarrollo

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

MCP Inspector (prueba local)

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

Contribuciones

Consulte las pautas de contribución (Alemán).

Seguridad

Consulte la política de seguridad (Alemán) para conocer la postura de seguridad y cómo informar de una vulnerabilidad.

Licencia

Licencia MIT: consulte LICENSE.

Datos de origen: MeteoSwiss Open Government Data (CC BY 4.0). Al utilizar los datos, cite: Fuente: MeteoSwiss.

Autor

Hayal Oezkan · github.com/malkreide

Servidores relacionados

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

Instalación

Ejecute mediante uvx de uv: no se necesita clonar ni instalar manualmente. Añádalo a la configuración de su cliente MCP (mcpServers para Claude Desktop, Cursor y Windsurf; use una clave servers de nivel superior para VS Code en .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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-08-03 08:05 across 6 tools

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

Need Help?

Related Servers

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
723
Meteoswiss
io.github.pipeworx-io
Swiss weather and federal geodata from MeteoSwiss and swisstopo on data.geo.admin.ch — find…
Weather Services Location Services Open Data
1
open-meteo-mcp-server A
io.github.cyanheads
Global weather via Open-Meteo: forecast, historical, marine, air quality, geocoding, elevation.
Weather Services Location Services
1128
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
B
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 9 days ago (2026-10-03 16:41 UTC)
17
1,359 npm
70
MIT
MeteoSwiss MCP Server
Weather Services Search Government Data
eins78
A
license
Not graded
quality
A
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 2 days ago (2026-10-10 18:34 UTC)
3
Creative Commons Zero v1.0 Universal
mcp-weather-gc-ca
Weather Services Open Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables AI agents to access live weather data from Environment and Climate Change Canada via the GeoMet API.
Updated 16 days ago (2026-09-26 22:20 UTC)
30 npm
MIT

🌦️ meteoswiss-mcp

Consulta de demostración (ejemplo de ancla)

Herramientas (6)

Anotaciones de herramientas (sugerencias MCP)

Versión del protocolo MCP

Inicio rápido

Claude Desktop

Claude Desktop (desarrollo local)

Nube / Render.com (Streamable HTTP)

Docker / Render

Registro estructurado

Seguridad en modo HTTP

Ejemplo: pila HTTP de producción

Ejemplos de consultas

Planificación escolar

Comparación climática

Infraestructura y entorno

Arquitectura

Fuentes de datos

Seguridad y límites

Limitaciones conocidas

Matriz de responsabilidades: nieve y precipitación (delimitación frente a swiss-environment-mcp)

Sinergias del portafolio

Pruebas

Desarrollo

MCP Inspector (prueba local)

Contribuciones

Seguridad

Licencia

Autor

Servidores relacionados

Instalación

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Matriz de responsabilidades: nieve y precipitación (delimitación frente a `swiss-environment-mcp`)