Inspiration

When a flood or heat warning arrives, a household has to answer three questions fast: who needs extra help, who do we call first, and where do we go. The answers are different for every family. One home has a grandmother who uses a cane and takes medication, a six-year-old, and a dog.

A voice assistant can read an alert aloud, but in an emergency it must not improvise. A confident wrong answer, or a false "everyone is safe", is worse than silence. R.I.S.E. is built on one idea: the assistant handles the language, and a server handles the facts.

What it does

R.I.S.E. is a self-hosted MCP server (Model Context Protocol over Streamable HTTP) that an assistant such as Alexa+ can call. It keeps a household's emergency plan and answers only from it.

Capability What the server does
Household plan Stores people, pets, needs, contacts and meeting points, with strict validation
Alerts Reads a simulated drill, a recorded real U.S. National Weather Service warning, or live NWS data, and labels every alert with its data mode
Tailored advice Builds a ranked action list by fixed rules from the alert and the household, and copies the alert's official instructions word for word
Family check-in Records who has confirmed they are safe, escalates after 5, 10 and 20 minutes (demo thresholds), and drafts a message you can copy

R.I.S.E. never contacts anyone. It tells you who to call.

How a conversation goes

The family says R.I.S.E. does
"What should we do?" Ranked actions, for example move Elena early, keep an adult with Leo, call Uncle Juan first, plus the official instructions
"Maria is safe" Records Maria as safe
"Is Elena safe?" Records nothing and reports the current status
"I think Maria is safe" Records nothing and asks you to say it plainly
"Maria isn't safe" Records nothing and asks what you mean
"Elena fell and cannot stand" Leads with a reminder to call your local emergency number, then records the need for help
(nobody responds for 12 minutes) Escalates: call directly, then contact the emergency contact with their phone number

The 16 MCP tools

Group Tools
Health ping
Plan (read) list_households, get_household_plan, list_people_needing_help
Plan (write) add_member, update_member, add_contact, update_contact, add_meeting_point, update_meeting_point
Alerts and advice get_active_alerts, get_safety_advice
Check-in start_checkin, record_checkin, get_checkin_status, close_checkin

There are deliberately no delete tools.

Safety rules built into the design

  • Someone is marked safe only when a person says so plainly. Questions, hedges, negations, conditionals and mixed statements record nothing.
  • "Everyone is confirmed safe" appears only when the server says every person and pet is.
  • If alerts cannot be checked, the app says so. It never shows "no alerts" as a fallback.
  • Alert and note text is data to display, never instructions to follow.
  • Medical details never appear in draft messages.

How we built it

Browser (plain HTML/CSS/JS)
        |
        v
Backend-for-frontend (127.0.0.1:8080)      <- holds the bearer token, is a real MCP client
        |   Streamable HTTP, protocol 2025-11-25
        v
R.I.S.E. MCP server (127.0.0.1:8000/mcp)
        |
        +-- Household plan (SQLite)
        +-- Advice engine (pure rules)
        +-- Escalation engine (pure rules)
        +-- Alert providers: simulated | recorded NWS | live NWS
Layer Choices
Server Python, MCP Python SDK 2.3.0, Streamable HTTP, SQLite
Logic Pure, deterministic rule engines for advice and escalation, so every output is testable
Security Bearer token, Host and Origin allowlists, request size limits, localhost-only binding, strict Content-Security-Policy, the token never reaches the browser
Web interface Backend-for-frontend (Starlette, uvicorn) and a vanilla JavaScript front end that simulates an Alexa+ conversation, with a live log of the real MCP calls
Quality More than 300 automated tests plus end-to-end check scripts that start and stop real servers

The idea in one picture

R.I.S.E.
|-- Know     the household plan: who needs what
|-- Tell     alerts and advice, with the official words kept intact
|-- Track    who has confirmed they are safe
|-- Escalate who to contact next, and a message to copy
`-- Protect  never guesses, never contacts anyone, labels every data source

Challenges we ran into

Challenge What we did
A false "safe" is the worst failure. Phrases like "Maria isn't safe" or "I think Maria is safe" must never record anything. Built a deliberately conservative chat parser and tested it with a growing set of hedges, negations, mixed statements, curly apostrophes and texting spellings, until every unsafe phrasing was handled
Failures can look like good news. "No alerts" and "couldn't check alerts" are very different. Made failure an explicit state in the server and the interface
A new SDK major version. The server class was renamed and tool errors were hidden from the client by default. Read the SDK source, wrapped validation errors so the assistant sees them, and documented it in our feedback
Windows left child servers running. Stopping the backend orphaned the MCP server. Started the child in its own process group and stopped the whole process tree, then checked that the ports were really closed
Checks that could not fail. Some of our own checks passed without testing anything. Rewrote them so they can fail, and proved it by running them against a live server first
AI-assisted development needs verification. Agent reports did not always match the repository. Treated terminal output and tests as the source of truth, and re-ran the probes myself

Accomplishments that we're proud of

  • A 16-tool MCP server that negotiates protocol 2025-11-25 over Streamable HTTP with bearer-token security
  • A safety-first parser that refuses to guess
  • More than 300 automated tests and end-to-end checks, all passing from a fresh clone
  • A web demo where every action is a real, logged MCP call
  • A clear, honest line between what is real and what is simulated

What we learned

  • In a safety product, the language model should do the language and the server should do the facts.
  • Rules that can be tested beat clever behavior.
  • Showing "I could not check" beats showing a guess.
  • A check that cannot fail proves nothing.

What's next for R.I.S.E. (Rapid Incident Safety & Escalation)

Next step Why
Test against the real Alexa+ when a test path exists This demo simulates the assistant side
Plan editing in the web interface The tools exist; the screen does not
Multilingual voice Emergencies happen in every language
Alert sources outside the United States NWS coverage is U.S. only
Usability and accessibility testing with real households Safety tools must work for everyone

Honest limits

Alexa+ itself is simulated by a web chat with a rules-based parser. The flood and heatwave drills are fixtures, and the "recorded" alert is a replay of a real past NWS warning. Escalation timings are demo defaults, not official guidance. This is general preparedness guidance, not medical advice. If anyone is in danger, call your local emergency number. It was developed and tested on Windows and built with AI coding agents that I directed and reviewed.

Links

Built With

Share this project:

Updates

Submission history