weather-packing-bot

Un bot programado que publica un mensaje en Slack con una previsión meteorológica de varios días y una recomendación de equipaje para una ruta de viaje recurrente entre tres ciudades. También es una pequeña implementación de referencia de un par servidor-cliente MCP (Model Context Protocol): los datos de previsión los sirve un servidor MCP independiente y los consume un cliente MCP, en lugar de que el script del bot los obtenga directamente.

Resumen

El bot se ejecuta con una programación semanal (viernes, 15:00 CEST) y publica un mensaje en Slack que cubre el tiempo desde ese día hasta el lunes siguiente por la tarde. La previsión y la recomendación de equipaje tienen en cuenta el itinerario: consideran en cuál de las tres ciudades se espera que esté el viajero cada día de esa ventana, en lugar de mostrar el tiempo de todas las ubicaciones sin distinción.

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

Por qué un servidor y un cliente MCP

El servidor expone herramientas meteorológicas sin saber quién las llama ni por qué: podría ser este bot, un asistente de IDE o cualquier otro cliente compatible con MCP. El cliente no importa directamente las funciones Python del servidor; descubre las herramientas disponibles en tiempo de ejecución (session.list_tools()) y las invoca por nombre a través del protocolo (session.call_tool(...)). Esta separación es lo que distingue el diseño de simplemente llamar a una función en el mismo proceso.

Componentes

mcp_server/weather_server.py

Un servidor MCP (que utiliza la clase MCPServer del paquete mcp) que envuelve la API de Open-Meteo y expone cuatro herramientas:

Las ciudades se definen en el diccionario COORDINATES y se pueden ampliar libremente.

bot/packing_advisor.py

Un cliente MCP que:

1. Calcula la ventana de previsión —desde la fecha actual hasta el lunes siguiente, inclusive— mediante forecast_window().

2. Lanza weather_server.py como subproceso, realiza el protocolo de enlace MCP y llama a get_forecast_all y render_temperature_chart para esa ventana.

3. Compara cada fecha de la ventana con WEEKLY_ITINERARY, un diccionario que asigna el día de la semana a la ciudad (o ciudades) en la que se espera que esté el viajero ese día, de modo que solo las ubicaciones relevantes informen el resultado.

4. Pasa los días coincidentes a recommend_packing(), una función basada en reglas que utiliza umbrales de temperatura y precipitación (sin llamadas externas de IA).

5. Formatea un mensaje de Slack Block Kit —desglose día a día, lista de equipaje y gráfico— y lo publica mediante un webhook de entrada.

Itinerario de viaje

WEEKLY_ITINERARY en bot/packing_advisor.py codifica una ruta semanal recurrente:

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

El lunes tiene dos entradas porque es un día de transición: el itinerario sitúa al viajero en Den Bosch durante el día y de vuelta en Kerpen por la noche. Este diccionario es el único lugar que hay que editar si cambia la ruta.

El gráfico

render_temperature_chart produce un gráfico de texto sin formato y monoespaciado en lugar de una imagen. Esta es una restricción deliberada: un webhook de entrada de Slack solo puede publicar texto o JSON de Block Kit; no puede subir un archivo binario. Publicar una imagen real requeriría un token de bot de Slack (una aplicación de Slack instalada con el ámbito files:write) y una llamada a la API web files.upload de Slack en lugar del webhook. Es una extensión viable, pero requiere gestionar una credencial adicional; la implementación actual evita ese requisito por completo.

Configuración

Requisitos previos

• Una aplicación de Slack con una URL de webhook de entrada.

• Un repositorio de GitHub para alojar el código y ejecutar el flujo de trabajo programado.

Ejecución local

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 (consulta .env.example) se puede configurar con una fecha ISO para probar la lógica del itinerario y de la ventana de previsión sin esperar a un viernes real.

El servidor MCP también se puede inspeccionar por separado:

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

Esto abre el MCP Inspector en un navegador, útil para ver los esquemas de las herramientas y llamar a herramientas como get_forecast o render_temperature_chart directamente.

Configuración del repositorio de GitHub

• Añade SLACK_WEBHOOK_URL como secreto del repositorio (Settings → Secrets and variables → Actions → Secrets).

• No se requiere ninguna otra configuración del repositorio; el itinerario se define en el código y no como una variable del repositorio.

Programación

.github/workflows/weekly-forecast.yml se ejecuta todos los viernes a las 13:00 UTC (15:00 CEST) mediante cron: "0 13 * * 5". Las programaciones cron en GitHub Actions no tienen en cuenta el horario de verano, por lo que durante el periodo CET (invierno) se ejecuta a las 14:00 hora local en lugar de a las 15:00; la expresión cron se puede ajustar estacionalmente si ese desfase importa. El flujo de trabajo también admite la activación manual (workflow_dispatch) con una entrada opcional simulate_date, útil para probar antes de depender de la programación.

Limitaciones conocidas y posibles extensiones

• El mensaje de Slack incluye un gráfico basado en texto en lugar de una imagen, por la razón descrita anteriormente. Un gráfico PNG con matplotlib, combinado con un token de bot de Slack y files.upload, es una posible mejora futura.

• recommend_packing() se basa en reglas. Sustituirla por una llamada a un LLM (por ejemplo, la API de Anthropic) permitiría una salida en lenguaje más natural; los resultados de las herramientas MCP son diccionarios simples, por lo que se pueden pasar directamente a dicha llamada.

• El itinerario es un patrón semanal fijo. Una fuente de integración con calendario (por ejemplo, leer las fechas de viaje reales de un calendario) lo generalizaría más allá de una ruta semanal repetitiva.

Notas sobre el material de origen

El borrador original del script del servidor tenía varios problemas que se corrigieron durante el desarrollo de esta implementación:

• Una importación httpx2 no utilizada e inexistente.

• get_params() construía un diccionario de parámetros pero no lo devolvía.

• El cliente de Open-Meteo se construía solo dentro de if __name__ == "__main__", lo que lo hacía inaccesible para las funciones de herramienta que lo referenciaban en el ámbito del módulo.

• process_response intentaba asignar a una list usando un objeto dict_keys como índice, lo cual no es válido.

• Las funciones de herramienta devolvían objetos DataFrame de pandas y tipos escalares de numpy, que no son serializables en JSON; los resultados de las herramientas MCP deben ser serializables, ya que se transmiten como JSON.