The house that explains itself

Alexa+ as the resident agent of a short-term rental

Comment

Inspiration

Hosts put an Echo in the rental and then still answer the same twenty questions by text at 11 pm: how does the hot tub work, where is the spare coffee, the shower is dripping. The guest is a stranger to the house; the device is already on the counter; voice is the only sensible input. Alexa+'s own pitch — agentic, across services, with memory — is a perfect fit for the one building where the user doesn't know the house.

What it does

The house is an MCP server. Alexa+ (or our simulated Echo Show) talks to it and nothing else.

  • "How do I turn on the hot tub?" — the host's own steps, with the host's picture on the screen. "…and the wifi?" — a scannable QR card.
  • "The coffee pods are out." — checks the cupboard, orders a refill from the host's supplier to the property, tells the guest where the spare box is, posts to the host's feed.
  • "The shower is dripping." — opens a ticket, picks the host's plumber, proposes the first slot that doesn't collide with a check-in or check-out, books it on the guest's yes. Next morning: "the plumber is coming at 3 for the shower you reported yesterday."
  • Host: "What happened at Lakeview this week?" — a spoken briefing.
  • One server, three houses. Lakeview Cabin, Harbor Loft and Pine Ridge Chalet each have their own guide, calendar, contractors and cupboards; the Echo in each unit is pointed at its house with /mcp?property=<id>. In the loft the guest leaves tomorrow and the next arrives the day after, so a repair reported today lands three days out — and the house says why.

10 tools, 2 resources (property://<id>/guide, stay://current), 1 prompt (host-morning-briefing). Every answer carries structuredContent, which the device renders as a media card. State lives in the house, so the second day knows what the first day did.

How we built it

  • MCP server — TypeScript, @modelcontextprotocol/sdk 1.30 (protocol 2025-11-25), WebStandardStreamableHTTPServerTransport in stateless mode with JSON responses, Hono, bearer auth per property. Data in node:sqlite (built into Node 24 — nothing native to compile on the VPS). A supplier interface with one simulated implementation backs order_supply.
  • Simulated Alexa+ — Next 16 / React 19 Echo Show on a kitchen counter: Web Speech in, speechSynthesis out, media cards from structuredContent, and a judges' drawer that shows every MCP call an answer made. The agent is function-calling over the server's tools/list, tried in three tiers so a rate limit never becomes a dead demo: Groq (openai/gpt-oss-120b), then Gemini Flash, then a scripted agent that walks the same tools. Gemini is second because its free tier is capped per day, not per minute — the public demo spent it by evening. The drawer names whichever answered. All three reach the house only through /mcp — never the database.
  • Agent Skill — skill/the-house/SKILL.md in the open SKILL.md format, plus a raw JSON-RPC client (scripts/house.mjs) for agents without an MCP client.
  • Ops — one VPS, pm2, nginx + TLS, GitHub Actions deploy on push to main, /health. 22 e2e tests run an SDK client over real Streamable HTTP. MCP Inspector CLI transcripts are in docs/proof/.

Challenges we ran into

Kept as a dated friction log (docs/friction-log.md). The headline ones:

  1. Streamable HTTP stateless mode hangs the client if you close the transport after handleRequest — the SSE stream is still being written. enableJsonResponse: true and no manual close. Not in the SDK's stateless example.
  2. Gemini 3 rejects a function-call turn rebuilt from functionCalls; you must echo the model's own content back so its thoughtSignature survives.
  3. "State across sessions" cuts both ways on a public demo — every visitor's tickets and orders stayed in the house. Fixed with grouping and a reseed every 6 hours.
  4. tsc doesn't copy a .sql beside src, so tests passed while dist/server.js crashed. The build gate now boots dist and hits /health.

Accomplishments that we're proud of

  • A real MCP server on the required spec, live, with bearer auth, proven by MCP Inspector — not a mock behind a UI.
  • The continuity moment: report a leak today, and tomorrow's agenda says who is coming and why.
  • schedule_repair knows the booking calendar. Repairs land on the day nobody is checking in or out — the one rule every host has and no smart speaker knows.
  • The whole thing is honest about its limits: fictional property, simulated supplier, and a drawer that names which of the three agents answered instead of implying it was always the best one.

What we learned

  • MCP 2025-11-25 + the TypeScript SDK is a genuinely small surface: a working Streamable HTTP server with auth was one afternoon, and structuredContent made media cards trivial.
  • A scripted agent that walks the same tools is worth building on day one — the demo never depends on a model's mood or a free-tier quota.
  • The judges' drawer (every MCP call, live) turned out to be the best explanation of the architecture we have.

What's next

A host briefing that spans the whole portfolio; proactive check-in / check-out cards; an MCP App property-card; OAuth for Alexa+ Preview in place of the per-property token; a real supplier adapter behind the interface that already exists.

Built With

Share this project:

Updates

Submission history