HomeLog

Inspiration

When something breaks at home, I never remember when I bought it, where I put the manual, whether it's still under warranty, or what I already tried. That knowledge is scattered across receipts, boxes and memory, and split between the people who live in the house. HomeLog is a household memory you can just talk to.

What it does

HomeLog remembers the things a household owns and what happens to them:

• Save things by talking. "Remember my space heater, it's an Example HT-1500, bought 2025-11-02, warranty until November 2, 2027, kept in the hall closet." It stores the model, purchase date, warranty end date and location.
• Find them later. "Where is the heater?" returns the location, and it mentions warranty only when one is saved or when you ask ("is the heater still under warranty?"). It never guesses a manufacturer's terms.
• Recurring jobs. "Remind me to clean the heater filter every 30 days." "What's due this month?"
• History. "I cleaned the heater filter yesterday" looks the item up, finds the matching job and marks it done: three tool calls from one sentence. "My heater keeps tripping the breaker" is logged to the item's history.
• Shared memory. Two household members share one logbook, and each entry records who said it.

How I built it

• A self-hosted MCP server in TypeScript using the official MCP SDK over Streamable HTTP, protocol 2025-11-25, with six tools: add_item, recall, log_event, add_task, whats_due, complete_task. The tool descriptions and input schemas are written for a model to choose between.
• SQLite (Node's built-in node:sqlite) holds the memory. The server is stateless per request, so any MCP client can use it.
• Due dates and warranty status are computed, never stored, so they can't go stale.
• A web voice simulator plays the voice assistant. It is an MCP client that calls the server over HTTP, shows each tool call, and uses the browser's speech features. It is a simulation: it is not the real Alexa+ and is not affiliated with Amazon.
• Tests: a smoke test that starts the real server and talks to it with the official MCP client, plus conversation tests for the assistant.
• An optional Amazon Bedrock adapter (Converse API) with a fake model for tests.

Challenges I ran into

• Real Alexa+ was out of reach. The Alexa+ MCP Toolkit documentation lists availability in the United States, and the developer site shows Canada as "coming soon". I didn't work around that, so the demo uses a simulator. The server follows the toolkit's stated requirements.
• Live Bedrock access. My new AWS account's per-model daily token quotas were 0 and not adjustable, so every model call was throttled, although AWS lists Bedrock as available on the Free plan. I opened a support case and haven't had a reply. The adapter is built and tested with a fake model. I haven't made a successful live call, and I say so rather than pretend.
• Natural phrasing. Hand-testing found gaps in the simulator's rules, such as "I put my X on Y", curly apostrophes and duplicate saves. Each is fixed and covered by a test.
• Everything is written up with evidence in FRICTION_LOG.md.

What I learned

How MCP works end to end (tools, schemas, transports, tool chaining), how Bedrock access is layered (model availability, a use-case form, quotas), and that testing with natural phrasing finds bugs that scripted tests miss.

What's next

A model-backed assistant for free-form speech and a step-by-step repair diagnosis that reads an item's history; tools to edit and delete items; handoff notes between household members; and connecting to real Alexa+ once the toolkit is available in my region.

Built With

• amazon-bedrock-(optional-adapter)
• express.js
• mcp
• model-context-protocol
• node.js
• sqlite
• streamable-http
• typescript
• web-speech-api
• zod