Why I built it
Travel safety data is fragmented by design. GDACS publishes an XML feed of active natural disasters with color-coded severity. The US State Department runs RSS advisories with a 1–4 scale. FAA NOTAMs use a cryptic Q-code format. The UK FCDO, NOAA, USGS, CDC, and ReliefWeb each publish their own schemas.
Every travel-adjacent assistant I tried to build hit the same wall: to answer a question as basic as "is it safe to travel to Haiti right now?" you have to cross-reference half a dozen sources, normalize three different severity scales, and hope none of them is stale.
How it works
One MCP server. Background pollers fetch each feed on its own cadence; severity is normalized — GDACS color codes (Green/Orange/Red) and State Dept levels (1–4) both collapse to a unified enum. The server exposes two tools:
list_active_alerts— filtered by country or region, with optional severity floor.fetch_alert_details— full text, coordinates, and source URL for a specific alert.
SQLite handles local caching, keyed by (source, source_id) for deduplication across polls.
Under the hood
- FastMCP framework over stdio transport, with lifespan management for connection pooling and the background polling loop.
aiosqlitein WAL mode so readers never block writers.- Per-source fetchers run in parallel; each one handles its own parse quirks (XML, RSS, JSON).
- Ships the NOTAM Decoder as a submodule — the FAA feed comes in already structured, not as raw Q-code soup.
- Includes background polling and an HTTPS deployment configuration.
Where it stands
The implementation covers GDACS, US State Dept, FAA, NOAA, NWS, UK FCDO, USGS, CDC, and ReliefWeb. Additional sources can be added as their feeds prove stable.