Nepal Disaster Watch

Inspiration

On August 26, a devastating flood tore through Nepal's Bhote Koshi river system, sweeping water, mud, and debris through Rasuwa and downstream communities. I wasn't thinking about hackathons that night I was refreshing tab after tab at 2am, trying to find out if people I knew were okay.

That's when the second gut-punch hit: I couldn't even get a straight answer. Incident reports lived on one government portal, river levels on another, road closures on a third, flood forecasts and satellite damage assessments somewhere else entirely each written for a different audience, none of them talking to each other. Every empty page made me more anxious, because I couldn't tell if "no data" meant "nothing happened" or "the power's out and nobody can report anything."

That fear of mistaking silence for safety is the whole reason Nepal Disaster Watch exists.

What it Does

Nepal Disaster Watch is a live emergency-intelligence platform covering all 77 districts of Nepal. It pulls together six public data sources government incident reports, river gauges, road closures, disaster alerts, flood forecasts, and field or satellite damage assessments into one consistent, constantly refreshing picture.

It isn't just a dashboard. It's built with 11 native WebMCP tools that let a person and an AI agent investigate the same evidence, side by side, on the same screen. Some tools read information checking source health, summarizing the national situation, cross-referencing a district across every feed. Others act on the interface itself, like focus_district("Rasuwa"), which pans and zooms the live map the person is already looking at. There's no separate "agent view." We share one screen and one investigation.

How we Built It

The core of the system normalizes those six data sources into a single schema, refreshed every three minutes:

$$t_{\text{refresh}} = 180\text{s}$$

Every record is transformed into a standardized model with strict provenance metadata:

$$R_i = {\,id,\ district_id,\ timestamp,\ source_type,\ payload,\ confidence_score\,}$$

On top of that pipeline sit the 11 WebMCP tools, split between read tools (source health, situation summaries, cross-source comparisons, record inspection, feed filtering) and action tools that mutate the dashboard state directly moving the map, opening records, changing what's on screen for both the human and the agent at once.

Challenges we Ran Into

The hardest part wasn't technical it was resisting the urge to smooth things over. Cross-referencing sources often surfaced sharp, uncomfortable disagreements: a district with zero official incident reports sitting right next to satellite imagery showing widespread structural damage. It would have been easier to just pick a number and show it. Instead, the app says plainly: these sources disagree, and here's probably why because honesty about what we don't know is worth more than false confidence during a crisis.

Underneath that were two harder engineering problems:

• Source availability. Public emergency portals go down during real disasters exactly when they're needed most, from traffic spikes or infrastructure failure. I had to build fallback logic and explicit "source health" indicators so the system stays useful even when parts of it go dark.
• Context synchronization. Keeping the agent's actions and the human's view in perfect sync zero-latency state updates between a WebMCP tool call and what actually renders on screen took real care to get right.

Accomplishments that We're Proud Of

I'm proud that this doesn't feel like a technical demo bolted onto a real tragedy it feels like the tool I actually needed at 2am on August 26. I'm proud that the system never quietly papers over a gap in the data; it surfaces disagreement and uncertainty instead of pretending to have a single clean answer. And I'm proud of building a genuinely shared human-agent interface — not an agent-only backend and a human-only frontend, but one investigation the two of us run together.

What we Learned

• Absence of evidence isn't evidence of absence. In disaster intelligence, an empty feed usually means broken infrastructure, not a safe district. I had to design the whole system around that distinction instead of treating "no data" as good news.
• Uncertainty deserves to be shown, not hidden. Source freshness, health, and reporting delays turned out to matter more than forcing everything into one clean "source of truth."
• WebMCP changes what "using an AI agent" even means. Instead of an agent screen-scraping a website and guessing which button to click, it can call purpose-built tools and act inside the same interface a person is looking at genuinely side by side, not behind the scenes.

What's Next for Nepal Disaster Watch

Nepal Disaster Watch doesn't issue official warnings or make emergency decisions, and that boundary matters it's a step, not the finish line. Next is expanding source coverage beyond the initial six feeds, tightening the confidence-scoring model so confidence_score reflects real reporting-chain conditions rather than a rough proxy, and getting the platform in front of the people who were living through nights like the one that inspired it so the next time information is scattered, it doesn't have to stay that way.

Built With

• ai-agents
• css3
• html5
• javascript
• leaflet.js
• model-context-protocol
• openstreetmap
• rest-api
• webmcp