Keeper

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Keeper

Inspiration

When you go away, someone else runs your home for a few days: a sitter, a dog walker, a parent helping out. The knowledge lives in a fridge note, a long text thread, and your phone, which rings at 9 PM with "what's the wifi again?" and "is Mila allowed peanut butter?". The device that is already in the kitchen could answer, but a household assistant has one problem a personal one doesn't: the person asking is not the owner, and some notes (the alarm code, where the spare cash is) are not for everyone.

What it does

Keeper is a self-hosted MCP server for Alexa+ that turns the owner's notes into a house manual that answers whoever is home, limited to what their pass allows.

• Passes, not accounts. "Give Lee a dog walker pass for the pets for two days." Lee says his four digit code to the device and, until the pass ends, hears only the pet and emergency notes.
• Private by default. New notes stay private until the owner shares them. A guest asking about a private note hears exactly the same words as for something that isn't written down, so the reply never reveals that a private note exists.
• Routines, one step at a time. "Walk me through bedtime" keeps its place across turns: next, back, say that again, stop.
• Questions go home. Anything Keeper can't answer is logged for the owner ("Priya asked: can Mila have a friend over?"). The owner answers by voice, Keeper tells the guest on their next turn, and the answer is saved as a shared note so the next person is covered.
• Emergency first. Emergency numbers and the address are always available, even before anyone says a code.
• While you were out. "What happened?" gives the owner a recap of each visit: what each guest got answers on and what they sent.
• MCP Apps card. Every tool links one MCP Apps view (ui://keeper/house-card.html) that shows the answer, the routine step with progress, the pass, the owner's open questions, or the recap on an Echo Show style screen, with buttons that call tools back.

How we built it

• Next.js 16 and TypeScript on Vercel. The MCP server lives at /api/mcp, built with the official MCP TypeScript SDK through mcp-handler, over Streamable HTTP, negotiating protocol 2025-11-25.
• 15 tools (visit_start, visit_end, house_ask, routine_walk, emergency_info, house_manual, note_add, note_update, note_remove, pass_create, pass_revoke, pass_list, questions_open, question_answer, house_recap), one prompt (sitter_handoff), and one MCP Apps resource. Every tool has zod input and output schemas, structuredContent, annotations, and a speech field written to be read aloud.
• Two kinds of connection. The device link (?house=) speaks for whoever has an active pass on it and can never change the manual. The owner's connection adds an x-keeper-key header, standing in for account linking in a real Alexa+ deployment. Five wrong codes in ten minutes locks code guessing.
• Privacy by construction. Search runs only over the notes the current person may hear; private and out-of-pass notes are filtered out before search, so they are never candidates. When search misses, a free open model (OpenRouter) may pick a note, but its prompt contains only those same visible notes, its choice is ignored unless it names one of them, and Keeper speaks the owner's note verbatim. The model chooses; it never writes the answer.
• Each house is one JSON document in a private Vercel Blob store with a per-house lock.
• The simulated Alexa+ (allowed by the rules) is the web page: pick who is speaking (Priya the sitter, Lee the dog walker, Sam the owner), speak or type, and each turn is planned (free open model, or an offline intent matcher) into real MCP tool calls against the same /api/mcp endpoint, through the official MCP client. The card renders in a sandboxed iframe host.
• Tests: 29 vitest tests cover passes, lockout, expiry and revocation, the question sets, routines, the owner loop, the planner, the resolver's privacy guard, and real MCP round trips over Streamable HTTP. Typecheck, lint, and build pass.

How well it answers

• Development set (40 questions, used to set the search thresholds): 24 of 24 answerable questions got the right note; 9 of 10 private or out-of-pass questions and 4 of 6 not-in-the-manual questions were routed to the owner; the other 3 got a different shared note (not a leak).
• Held-out set (20 questions, written after the thresholds were frozen, scored once): search alone answered 6 of 13 answerable questions; with the model resolver on the misses, 8 of 13. All 5 private or out-of-pass and both not-in-the-manual questions were routed to the owner.
• Replies containing private or out-of-pass text: 0 on both sets.
• Honest limit: paraphrases like "How many scoops for Biscuit?" are still missed. A miss is never silent: it becomes a question for the owner, and the answer is saved for next time.

Judging criteria

Technical implementation

• A real MCP server on spec 2025-11-25 over Streamable HTTP that owns its state (houses, notes, passes, questions, routines, activity); not a wrapper around another API.
• State across sessions and people: a visit, a routine step, and a question asked by one person reach another person later, in a different connection.
• Access control in the server, not the prompt: audiences resolved per connection, pass scopes by section, expiry, revocation, and a guess lockout.
• MCP Apps card with ui/initialize, tool-result notifications, and tools/call from buttons.
• Measured privacy and accuracy, with a held-out set and raw results in the repo.

Design

• Voice first: each reply is one or two sentences in the owner's own words, then a card.
• The reply for "private" and "not written down" is the same sentence, on purpose.
• Contextual suggestions change with the speaker and the moment (inside a routine they are Next, Say that again, Back, Stop).
• The side panel shows the house as the owner sees it: passes, who is here, private note titles, and the visit log.

Potential impact

Anyone who leaves their home in someone else's hands: parents with a sitter, pet owners with a walker, hosts with a house guest, adult children helping an older parent. The questions are the same every time, the answers already exist in the owner's head, and the device is already in the room. Keeper makes the answer available to the right person, keeps the rest private, and closes the loop when something wasn't written down.

Quality of the idea

Most assistant skills assume the speaker is the account owner. Keeper starts from the opposite case, the person in the house who isn't, and uses the Alexa+ creative directions the rules list: an agentic workflow across people, state across sessions, and MCP Apps cards.

Challenges we ran into

• Identity on a shared device: an MCP server sees a connection, not a person, so we separated the device link (spoken pass codes) from the owner's connection.
• Not leaking by accident: anything a tool returns can be spoken or shown, so privacy had to be enforced before search, and the miss and private replies had to be identical so a guest cannot probe.
• Keyword search breaks on paraphrase (6 of 13 on our held-out set), so we added a model resolver restricted to visible notes; the free models were conservative (2 of 7 recovered, no wrong picks) and took 1.4 to 12.8 seconds per call.

Accomplishments we're proud of

• The full loop in the video runs live: pass code, answer, routine, private question, owner answer, delivery to the guest, a second guest with a narrower pass, and the recap.
• Zero private-text leaks across 60 fixed questions, with the numbers reproducible from the repo.

What we learned

• Writing the spoken reply in the server, per tool, keeps answers short and makes privacy testable.
• A held-out set is humbling: our development numbers looked perfect; the held-out ones showed exactly where to improve.

What's next

• Real account linking and owner voice recognition instead of the owner key.
• Better paraphrase matching (small local embeddings) so fewer questions need the owner.
• Time-of-day routines that Keeper offers proactively ("it's 7, want to start bedtime?").

AI use disclosure

Keeper was built with AI coding assistance (an AI agent wrote most of the code, tests, docs, and this write-up under the entrant's direction). At runtime the simulator uses open models through OpenRouter to plan tool calls and, when search misses, to pick among visible notes. The demo video narration is a synthetic voice (Piper TTS, LJ Speech voice), and the video says so on screen. No real person's face or voice is used. The demo house, family, and phone numbers are fictional.

Built With

• mcp-apps
• model-context-protocol
• nextjs
• openrouter
• piper-tts
• react
• remotion
• tailwindcss
• typescript
• vercel
• vercel-blob
• vitest
• web-speech-api