HandoffHome

Inspiration

A change of plans rarely affects just one person. If someone has to leave early, the rest of the household still needs to know what is left, who can take over, and whether the plan has already changed.

I built HandoffHome around that small but awkward moment. The goal is to make a handoff easy to review and safe to act on, while preserving the reasons behind each change.

What it does

Jordan needs to leave early and asks Sam to take over the evening routine. HandoffHome finds the unfinished tasks and notices that Sam's football overlaps with Miso's dinner. It asks a specific question about moving dinner to 7:30 PM, then creates a proposed handoff.

While Jordan is reviewing it, Alex marks the recycling bins done from a separate client session. The server notifies the speaker client, and the proposal is rebuilt from the latest household state. Sam now takes three tasks, with the bins recorded as already done.

Ownership changes only after explicit confirmation. A repeated commit request returns the same result instead of creating another handoff. Afterwards, Sam can ask what changed and why. Each explanation is grounded in the household change log, including why dinner moved and why the bins were excluded.

How I built it

The core is a self-hosted TypeScript MCP server using the official MCP SDK, protocol version 2025-11-25, and Streamable HTTP. A React web interface acts as a real MCP client. The speaker and Alex's phone establish separate sessions against the same server.

The server owns the important decisions: task and calendar conflict checks, proposal revisions, confirmation, idempotent writes, persistence, and explanations. Resource subscriptions keep the client informed when another session changes the household. Elicitation provides the confirmation step, with a token-based fallback for clients without elicitation support.

An optional read-only MCP App card displays the committed handoff through the official App/AppBridge in this project's web host. Its host restricts the tools it can call. A protocol inspector exposes the actual messages behind the interface.

The understanding layer is a deterministic intent parser. No AI model or external API key is required to run the product. Generative AI was used during development and for the video's narration; it is not presented as the application's runtime understanding layer.

Challenges

Final local verification also caught a confirmation-delivery race: a server request could be sent before the optional background stream was connected. Confirmation now travels on the originating tool-call stream, and a regression test checks that it still works when the background stream is unavailable.

The most important challenge was handling a plan that becomes stale while someone is reviewing it. Updating the screen alone is not enough: the server also re-checks the proposal's underlying task and event state before committing it.

Another challenge was keeping retries safe. Every mutation has an idempotency key, and the server preserves the original committed result for a repeated request. The optional card also needed a clear trust boundary, so write requests from that view are rejected by its host.

Testing the simulated experience meant being precise about what we could prove. The web client exercises real MCP traffic, but it does not establish compatibility with Alexa+ itself. The friction log records this gap and the other concrete integration problems encountered during the build.

What I'm proud of

The complete handoff stays coherent even when another person changes the plan halfway through. The project combines conflict detection, explicit consent, safe retries, and an explanation grounded in recorded changes in one working flow.

What I learned

A useful assistant needs more than a plausible response. It needs a dependable account of what it knows, which version of the plan is current, and whether the person has actually approved the change. Those responsibilities belong in the server's state transitions as well as in the interface.

What's next

The next step is to test the interaction with real households, then add authenticated access and a real calendar integration. An Alexa+ integration would need testing through supported tools when access is available. Broader language understanding could be added later while keeping the same server-side confirmation and consistency checks.

Current scope

This is a local prototype with fictional household data, simulated speaker selection, and no real calendar or messaging integration. It has not been tested on an actual Alexa device or in third-party MCP App hosts. Browser speech input and audible speech output are optional features that are not demonstrated in this recording. No user-adoption or measured real-world impact claims are made.

Validation

The final local build passed 365 automated tests across 25 files, type checking, and two real-browser tests covering the golden handoff and MCP App bridge/write rejection. During demo preparation, a newly reproduced confirmation-delivery race was fixed and given a regression test. An earlier independent Astra review had rerun 58 targeted tests and four browser tests on the preceding checkpoint; it does not cover the subsequent routing fix.

The demo was recorded against the real local server on a clean MacBook Air setup. Recording assertions check the clash, revision 1, revision 2, the three-task handoff, explicit confirmation, unchanged commit ID on replay, explanation citations, and the connected MCP App card.

Development and demo disclosure

Development took place during the hackathon submission period. The repository retains genuine development history. The demo uses actual local application footage and fictional household data. Its narration is AI-generated with OpenAI Cedar.

Built With

• model-context-protocol
• node.js
• react
• typescript