weather-packing-bot

Ein zeitgesteuerter Bot, der eine Slack-Nachricht mit einer mehrtägigen Wettervorhersage und einer Packempfehlung für eine wiederkehrende Reiseroute durch drei Städte postet. Er ist außerdem eine kleine Referenzimplementierung eines Server-und-Client-Paars für das MCP (Model Context Protocol): Die Vorhersagedaten werden von einem eigenständigen MCP-Server bereitgestellt und von einem MCP-Client konsumiert, anstatt direkt vom Bot-Skript abgerufen zu werden.

Überblick

Der Bot läuft nach einem wöchentlichen Zeitplan (freitags um 15:00 Uhr MESZ) und postet eine Slack-Nachricht, die das Wetter von diesem Tag an bis zum darauffolgenden Montagabend abdeckt. Die Vorhersage und die Packempfehlung sind auf den Reiseplan abgestimmt: Sie berücksichtigen, in welcher der drei Städte sich der Reisende an jedem Tag dieses Zeitraums voraussichtlich aufhält, anstatt das Wetter aller Standorte wahllos anzuzeigen.

GitHub Actions (scheduled, Fridays)
        │
        ▼
bot/packing_advisor.py            MCP client
        │  spawns as subprocess, communicates over stdio
        ▼
mcp_server/weather_server.py      MCP server, queries Open-Meteo
        │
        ▼
   Slack incoming webhook

Warum ein MCP-Server und -Client

Der Server stellt Wetter-Tools bereit, ohne zu wissen, wer sie aufruft oder warum - es könnte dieser Bot, ein IDE-Assistent oder ein beliebiger anderer MCP-fähiger Client sein. Der Client importiert die Python-Funktionen des Servers nicht direkt; er ermittelt die verfügbaren Tools zur Laufzeit (session.list_tools()) und ruft sie über das Protokoll namentlich auf (session.call_tool(...)). Diese Trennung ist es, die das Design von einem bloßen Funktionsaufruf im selben Prozess unterscheidet.

Komponenten

mcp_server/weather_server.py

Ein MCP-Server (unter Verwendung der MCPServer-Klasse aus dem mcp-Paket), der die Open-Meteo-API kapselt und vier Tools bereitstellt:

Die Städte sind im COORDINATES-Dict definiert und können frei erweitert werden.

bot/packing_advisor.py

Ein MCP-Client, der:

1. Das Vorhersagefenster - vom aktuellen Datum bis einschließlich zum folgenden Montag - über forecast_window() berechnet.

2. weather_server.py als Unterprozess startet, den MCP-Handshake durchführt und get_forecast_all und render_temperature_chart für dieses Fenster aufruft.

3. Jedes Datum im Fenster mit WEEKLY_ITINERARY abgleicht, einem Dict, das Wochentage auf die Stadt (oder Städte) abbildet, in der (bzw. in denen) sich der Reisende an diesem Tag voraussichtlich aufhält, sodass nur relevante Orte in die Ausgabe einfließen.

4. Die abgeglichenen Tage an recommend_packing() übergibt, eine regelbasierte Funktion, die Temperatur- und Niederschlagsschwellenwerte verwendet (kein externer KI-Aufruf).

5. Eine Slack-Block-Kit-Nachricht formatiert - tagesweise Aufschlüsselung, Packliste und Diagramm - und sie über einen Incoming-Webhook postet.

Reiseplan

WEEKLY_ITINERARY in bot/packing_advisor.py kodiert eine wiederkehrende wöchentliche Route:

WEEKLY_ITINERARY = {
    4: [("Nijmegen", "arrival")],       # Friday
    5: [("Nijmegen", "")],              # Saturday
    6: [("Nijmegen", "")],              # Sunday
    0: [("Den Bosch", "day"), ("Kerpen", "evening, back home")],  # Monday
}

Montag hat zwei Einträge, weil es ein Übergangstag ist: Der Reiseplan verortet den Reisenden tagsüber in Den Bosch und abends wieder in Kerpen. Dieses Dict ist die einzige Stelle, die geändert werden muss, wenn sich die Route ändert.

Das Diagramm

render_temperature_chart erzeugt ein Klartext-Diagramm in Monospace-Schrift anstelle eines Bildes. Das ist eine bewusste Einschränkung: Ein Slack-Incoming-Webhook kann nur Text oder Block-Kit-JSON posten - er kann keine Binärdatei hochladen. Das Posten eines echten Bildes würde ein Slack-Bot-Token (eine installierte Slack-App mit dem Scope files:write) und einen Aufruf der files.upload-Web-API von Slack anstelle des Webhooks erfordern. Das ist eine machbare Erweiterung, erfordert aber die Verwaltung einer zusätzlichen Anmeldeinformation; die aktuelle Implementierung umgeht diese Anforderung vollständig.

Einrichtung

Voraussetzungen

• Eine Slack-App mit einer Incoming-Webhook-URL.

• Ein GitHub-Repository, um den Code zu hosten und den geplanten Workflow auszuführen.

Lokale Ausführung

python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env   # fill in SLACK_WEBHOOK_URL
export $(grep -v '^#' .env | xargs)
python bot/packing_advisor.py

SIMULATE_DATE (siehe .env.example) kann auf ein ISO-Datum gesetzt werden, um die Reiseplan-/Vorhersagefenster-Logik zu testen, ohne auf einen tatsächlichen Freitag warten zu müssen.

Der MCP-Server kann auch für sich allein untersucht werden:

pip install "mcp[cli]"
mcp dev mcp_server/weather_server.py

Dies öffnet den MCP Inspector in einem Browser, nützlich zum Anzeigen von Tool-Schemas und zum direkten Aufrufen von Tools wie get_forecast oder render_temperature_chart.

GitHub-Repository-Konfiguration

• Fügen Sie SLACK_WEBHOOK_URL als Repository-Secret hinzu (Einstellungen → Geheimnisse und Variablen → Aktionen → Geheimnisse).

• Keine weitere Repository-Konfiguration ist erforderlich; der Reiseplan ist im Code definiert und nicht als Repository-Variable.

Zeitplan

.github/workflows/weekly-forecast.yml läuft jeden Freitag um 13:00 Uhr UTC (15:00 Uhr MESZ) über cron: "0 13 * * 5". Cron-Zeitpläne in GitHub Actions berücksichtigen keine Sommerzeit, daher wird der Workflow während der MEZ-Periode (Winter) um 14:00 Uhr Ortszeit statt um 15:00 Uhr ausgelöst; der Cron-Ausdruck kann saisonal angepasst werden, wenn diese Abweichung von Bedeutung ist. Der Workflow unterstützt außerdem manuelles Auslösen (workflow_dispatch) mit einem optionalen Eingabewert simulate_date, nützlich zum Testen, bevor man sich auf den Zeitplan verlässt.

Bekannte Einschränkungen und mögliche Erweiterungen

• Die Slack-Nachricht enthält aus dem oben beschriebenen Grund ein textbasiertes Diagramm anstelle eines Bildes. Ein PNG-Diagramm über matplotlib, kombiniert mit einem Slack-Bot-Token und files.upload, ist eine mögliche Folgeerweiterung.

• recommend_packing() ist regelbasiert. Ersetzt man es durch einen Aufruf eines LLM (z. B. der Anthropic-API), wäre eine natürlichere Sprachausgabe möglich; die MCP-Tool-Ergebnisse sind einfache Dicts, sodass sie direkt an einen solchen Aufruf übergeben werden können.

• Der Reiseplan ist ein festes wöchentliches Muster. Eine Kalenderanbindung (z. B. das Auslesen tatsächlicher Reisedaten aus einem Kalender) würde ihn über eine sich wiederholende wöchentliche Route hinaus verallgemeinern.

Anmerkungen zum Quellmaterial

Das ursprüngliche Server-Skript aus dem Entwurf hatte mehrere Probleme, die während der Entwicklung dieser Implementierung korrigiert wurden:

• Ein unbenutzter, nicht existierender httpx2-Import.

• get_params() erstellte ein Parameter-Dict, gab es aber nicht zurück.

• Der Open-Meteo-Client wurde nur innerhalb von if __name__ == "__main__" erstellt, wodurch er für die Tool-Funktionen, die ihn auf Modulebene referenzierten, nicht verfügbar war.

• process_response versuchte, mithilfe eines dict_keys-Objekts als Index in eine list zuzuweisen, was nicht gültig ist.

• Tool-Funktionen gaben pandas-DataFrame-Objekte und numpy-Skalartypen zurück, die nicht JSON-serialisierbar sind; MCP-Tool-Ergebnisse müssen serialisierbar sein, da sie als JSON übertragen werden.