weather-packing-bot

一个定时机器人，为重复的三城市旅行路线发布包含多日天气预报和打包建议的 Slack 消息。它同时也是 MCP（Model Context Protocol）服务器与客户端配对的一个小型参考实现：预报数据由独立的 MCP 服务器提供，并由 MCP 客户端消费，而不是由机器人脚本直接获取。

概述

机器人按每周计划运行（周五 15:00 CEST），发布覆盖当天至下周一晚间的天气的 Slack 消息。预报和打包建议是感知行程的：它们会考虑旅行者在窗口期内每天预计身处三座城市中的哪一座，而不是不加区分地显示所有地点的天气。

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

为什么使用 MCP 服务器和客户端

服务器暴露天气工具，但不知道谁调用它们或为什么调用——它可能是这个机器人、IDE 助手或任何其他支持 MCP 的客户端。客户端不直接导入服务器的 Python 函数；它在运行时发现可用工具（session.list_tools()）并通过协议按名称调用它们（session.call_tool(...)）。这种分离正是该设计与在同一进程中简单调用函数的区别所在。

组件

mcp_server/weather_server.py

一个 MCP 服务器（使用 mcp 包中的 MCPServer 类），封装 Open-Meteo API 并暴露四个工具：

城市在 COORDINATES 字典中定义，可以自由扩展。

bot/packing_advisor.py

一个 MCP 客户端，它：

1. 通过 forecast_window() 计算预报窗口——从当前日期到下周一（含）。

2. 将 weather_server.py 作为子进程启动，执行 MCP 握手，并为该窗口调用 get_forecast_all 和 render_temperature_chart。

3. 将窗口中的每个日期与 WEEKLY_ITINERARY 匹配，该字典将星期几映射到旅行者当天预计所在的城市（或多个城市），以便只有相关地点参与输出。

4. 将匹配的日期传递给 recommend_packing()，这是一个基于规则、使用温度和降水阈值的函数（不调用外部 AI）。

5. 格式化 Slack Block Kit 消息——逐日明细、打包清单和图表——并通过传入 Webhook 发布。

旅行行程

bot/packing_advisor.py 中的 WEEKLY_ITINERARY 编码了一条重复的每周路线：

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

周一有两个条目，因为它是过渡日：行程安排旅行者白天在 Den Bosch，晚上回到 Kerpen。如果路线发生变化，这个字典是唯一需要编辑的地方。

图表

render_temperature_chart 生成纯文本、等宽字体的图表，而不是图像。这是一个刻意的约束：Slack 传入 Webhook 只能发布文本或 Block Kit JSON——它无法上传二进制文件。发布实际图像需要 Slack 机器人令牌（安装了具有 files:write 范围的 Slack 应用）以及调用 Slack 的 files.upload Web API，而不是 Webhook。这是一个可行的扩展，但需要管理额外的凭据；当前实现完全避免了这一要求。

设置

先决条件

• 一个具有传入 Webhook URL 的 Slack 应用。

• 一个用于托管代码并运行计划工作流的 GitHub 仓库。

本地运行

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（参见 .env.example）可以设置为 ISO 日期，以便在不等待实际周五的情况下演练行程/预报窗口逻辑。

MCP 服务器也可以单独检查：

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

这会在浏览器中打开 MCP Inspector，便于查看工具模式并直接调用 get_forecast 或 render_temperature_chart 等工具。

GitHub 仓库配置

• 将 SLACK_WEBHOOK_URL 添加为仓库机密（Settings → Secrets and variables → Actions → Secrets）。

• 不需要其他仓库配置；行程在代码中定义，而不是作为仓库变量。

计划

.github/workflows/weekly-forecast.yml 通过 cron: "0 13 * * 5" 在每个周五 13:00 UTC（15:00 CEST）运行。GitHub Actions 中的 Cron 计划不遵循夏令时，因此在 CET（冬季）期间，它会在当地时间 14:00 而不是 15:00 触发；如果该偏移很重要，可以按季节调整 cron 表达式。该工作流还支持手动触发（workflow_dispatch），带有可选的 simulate_date 输入，便于在依赖计划之前进行测试。

已知限制和可能的扩展

• Slack 消息包含基于文本的图表而不是图像，原因如上所述。通过 matplotlib 生成 PNG 图表，结合 Slack 机器人令牌和 files.upload，是一个可能的后续工作。

• recommend_packing() 基于规则。将其替换为对 LLM（例如 Anthropic API）的调用将允许更自然的语言输出；MCP 工具结果是纯字典，因此可以直接传递给此类调用。

• 行程是固定的每周模式。日历集成来源（例如从日历读取实际旅行日期）将使其超越重复的每周路线而泛化。

关于源材料的说明

原始草稿服务器脚本存在几个问题，在本实现的开发过程中已修正：

• 一个未使用且不存在的 httpx2 导入。

• get_params() 构建了参数字典但没有返回它。

• Open-Meteo 客户端仅在 if __name__ == "__main__" 内部构建，导致在模块作用域引用它的工具函数无法使用。

• process_response 尝试使用 dict_keys 对象作为索引赋值到 list 中，这是无效的。

• 工具函数返回 pandas DataFrame 对象和 numpy 标量类型，这些不可 JSON 序列化；MCP 工具结果必须可序列化，因为它们以 JSON 传输。