Home Guard

Inspiration

Voice assistants often say "Done" while only some devices respond. Users on Reddit describe group commands that turn on a single light, requests they must repeat two or three times, and routines created when they only asked for something once. I wanted to build the reliability layer an Alexa+ add-on should have: a command that runs once, completely, and proves it.

What it does

Home Guard is an MCP server (Streamable HTTP, spec 2025-11-25) that makes each household command follow a contract:

• Complete group execution: sends to every device in a room in parallel, reads back each device's real state, retries online failures once, and returns one result such as "4 of 5 on. Not done: Floor lamp (offline)."
• Idempotency: a repeated command ID returns the stored result instead of running twice.
• No surprise routines: schedule_action is one-time unless the user explicitly asks for recurrence, and it asks for confirmation first.
• Ledger: every command records planned vs verified devices, retries, and whether a routine was created.
• A naive_set_group_state tool acts as a control experiment: it fires commands and always says "Done!", so the demo shows the gap against real device state.

How I built it

• Server: Python 3.12 on AWS Lambda with a Function URL, with no third-party dependencies. It handles MCP JSON-RPC itself and checks a bearer token (401 without it).
• AWS services: Lambda, DynamoDB (devices, ledger, schedules), EventBridge Scheduler for real one-time schedules, CloudFormation/SAM for deployment, CloudShell for deploying, CloudWatch Logs.
• Console: a React + TypeScript web app (generated with Google AI Studio, then modified in Antigravity) that acts as an Alexa+-style client. It calls the real server and shows the exact JSON request and response for every call.
• Tests: 8 pytest tests cover execution, retry, dedupe, the recurrence guard, partial success and bad input.

What is real and what is simulated

The Alexa+ voice client and the devices are simulated. The devices are persistent virtual devices in DynamoDB, with a fan that fails its first attempt on purpose and a floor lamp I take offline. The MCP server, the verification and retry logic, the DynamoDB ledger and the EventBridge schedules are real and running on AWS. I have not onboarded to Alexa+ itself, so I do not claim that Alexa+ calls this server today.

Challenges

• A new MCP Python SDK major version renamed FastMCP and broke my first server, so I pinned mcp<2.
• I first marked a partial result as a tool error, so the console hid real data. I changed isError to apply only to real errors.
• The console's naive panel re-read live device state after a Home Guard run and changed its own count. I found it while recording the demo.
• Latency: a verified command took about half a second from my browser in India to AWS in Sydney, so network distance adds to the latency. I have not measured from Alexa's side.

What I learned

A reliable assistant needs verification after the action, not just a successful API call. Honest partial results ("4 of 5") are more useful than a clean "Done."

What's next

Cognito OAuth for Alexa+ onboarding, real LIFX bulbs through the included provider, a region closer to users, and latency measured from Alexa's side.

Track: Alexa+. Mini challenge: AWS Builder. Repo:https://github.com/nedinzhechliyan/home-guard Video: https://youtu.be/A4GktqSOcBM

Built With

• amazon-dynamodb
• amazon-web-services
• get-ledger
• list-devices
• naive-set-group-state
• node.js
• python
• schedule-action
• set-group-state