Larder

Inspiration

The kitchen is where a voice assistant already sits and where hands are busy. People will say "we just used the last of the eggs" out loud, but they will not open an app to log it. A shopping list is a flat list: it does not know what is already in the cupboard, what a recipe needs, or the gap between the two. We wanted Alexa+ to remember the kitchen for the whole household, across conversations.

What it does

Larder is a self-hosted MCP server that gives Alexa+ a shared, persistent memory of a household's kitchen.

• Pantry memory by voice. "We're out of eggs and low on olive oil" records both changes in one call, notes who said it, and offers to add them to the cart.
• Recipes against the pantry. "Make lasagna for six on Saturday" scales the recipe, compares it with what is on hand, and returns a card listing exactly what is short or missing.
• Purchasing with a clear yes. order_place reads the order back with a confirmation code. Nothing is placed until order_confirm receives the matching code after the user says yes. Orders are simulated: no store, no payment.
• State across sessions and people. Maya's update in the morning is in Sam's answer at night. "The groceries are here" restocks the pantry from the remembered order, and "What changed in the kitchen?" reads the shared activity log.
• MCP Apps card. Every tool links one MCP Apps view (ui://larder/kitchen-card.html) that renders pantry chips, a recipe carousel, a recipe checklist, the cart, the order review, or the activity timeline on an Echo Show style screen. Buttons on the card call Larder tools back through the host, so touch and voice share one flow.

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. It negotiates protocol version 2025-11-25 (checked in an automated test and against production).
• 11 tools, each with an input schema, an outputSchema, structuredContent, tool annotations (read-only, destructive, idempotent), and a speech field written to be read aloud in one or two short sentences. Server instructions tell the assistant to speak that field and to ask before confirming an order. One prompt, weekly_restock.
• Household state is stored per household in private Vercel Blob storage, chosen by ?household=<id> on the MCP URL. The speaker can be passed as member so the log shows who did what.
• The simulated Alexa+ (allowed by the rules) is the demo page: speak with the Web Speech API or type. A free open model on OpenRouter plans each utterance into tool calls using the live tools/list, then the page calls Larder through the official MCP client over Streamable HTTP, exactly like any MCP host, speaks the reply with speech synthesis, and renders the MCP Apps card in a sandboxed iframe through a minimal host we wrote. The free tier is small, so each visitor gets a few model-planned turns a day; after that, or when the model is slow, an offline intent matcher plans the common kitchen phrases, and the page labels which planner answered.
• Any other MCP client can connect to the same kitchen with the URL shown on the page.
• Tests: vitest covers the household logic, the planner fallback, and real MCP round trips over Streamable HTTP (protocol version, tools linking the card, persistence across connections, a tool error on bad input). Typecheck, lint, and build pass.

Judging criteria

Technical implementation

• Real MCP server, spec 2025-11-25 over Streamable HTTP, not a wrapper around an existing API: Larder owns the pantry, recipe scaling, cart, and order state.
• Agentic orchestration: one sentence can produce several tool calls (pantry update, recipe plan, cart add) planned from the live tool list.
• Structured output everywhere (outputSchema plus structuredContent), tool annotations, and a two-step purchase that cannot complete without a matching confirmation code (the code expires after 15 minutes).
• Persistence across sessions and devices in private Blob storage, per household.
• MCP Apps resource with the ui/initialize handshake, tool results, tools/call from buttons, and ui/message from recipe taps.
• Graceful degradation: when the free model quota is used or the model is slow, the offline matcher keeps the demo working and says so.

Design

• Voice first: every reply is one or two short sentences, then a card for detail.
• Kitchen-friendly amounts ("3/4 box lasagna noodles", "1 1/2 cups ricotta") instead of decimals.
• The Echo Show style frame shows listening and thinking states, contextual suggestion chips change with the conversation (after an order review the chips are "Yes, place it" and "No, wait"), and each turn shows the MCP calls it made.
• Works on desktop and phone widths (checked at 1440 and 390 pixels wide with no horizontal overflow).

Potential impact

Any household that keeps a voice assistant in the kitchen and shares the grocery run. Larder turns the moments people already say out loud (running out, planning a dinner, groceries arriving) into a shared memory, so the cart builds itself from what the house actually needs, and nobody buys a third jar of something the house already has.

Quality of the idea

The rules list these as creative directions for Alexa+: a context-aware add-on that keeps state across sessions, an agentic workflow, purchasing capabilities, media support such as cards and carousels, and MCP Apps. Larder does all five in one focused flow: remember, plan, buy with a yes, restock, recap.

Challenges we ran into

• Making purchasing safe by voice: we split it into review and confirm with a short code, and taught the planner to pass the code only after a clear yes.
• Free model latency varied a lot during our demo recording (from about 2 seconds to about 25 seconds per turn), so the offline matcher and a visible "which planner answered" label became part of the design rather than an afterthought.
• There is no off-the-shelf MCP Apps host for a web page, so we wrote a minimal one around a sandboxed iframe.

Accomplishments we're proud of

• The whole flow from the video runs live on the production site: update, cart, recipe plan, card tap, order review, confirm, restock in a new session, and recap.
• Every action goes through the real MCP endpoint, so the same kitchen works from any MCP client.

What we learned

• Writing the speech field per tool, instead of letting the model paraphrase raw JSON, made replies short and consistent.
• structuredContent plus one MCP Apps view is enough to cover every result type with a single resource.

What's next

• Alexa account linking or OAuth instead of URL-based households.
• A real grocery partner behind order_confirm.
• More recipes and a larger catalog (today: 12 original recipes and 64 common items; anything else is tracked as free text).

AI use disclosure

Larder 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 an open model through OpenRouter to plan tool calls. 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.

Built With

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