TableTalk: Voice-First Restaurant MCP Server

A restaurant MCP server for voice assistants: allergen-aware menu search, smart table negotiation, pickup orders, opt-in memory, and simulated deposits where the AI can never approve a payment.

Comment

Inspiration

Booking a table by phone is slow, and small restaurants can't afford voice technology. Voice assistants also tend to fail at the moments that matter: a slot is full, a guest has a peanut allergy, or a large party needs a deposit. We wanted to build the restaurant side of a voice assistant properly, so it handles those moments safely instead of guessing.

What it does

TableTalk is a restaurant MCP (Model Context Protocol) server that a voice assistant can call to run a restaurant by conversation. It exposes 24 tools over Streamable HTTP:

  • Allergen-aware menu search. Hard filters for allergens and dietary tags. It only ever says an item is "listed as not containing" an allergen, never "safe", and always reminds guests to confirm severe allergies with staff.
  • Availability and negotiation. When "Friday at 7:30" is full, it ranks alternatives with explainable reasons, offers new options on each follow-up, and can hold a table for a few minutes before the guest confirms.
  • Safe bookings. Transactional, idempotent create and cancel, with a race test showing exactly one winner when many callers go for the last table.
  • Waitlist. First in, first out matching when a table frees up.
  • Pickup orders. Server-side pricing in integer minor units, price snapshots, and allergen conflict checks before an order is placed.
  • Opt-in memory. Remembers allergies, favorites and a "usual order" only after explicit consent, with a real "forget me" that deletes the profile and scrubs personal data from past records.
  • Simulated deposits. Large parties get a deposit step with a refund schedule. The AI cannot approve a payment. Only a human completes the mock checkout page. All payments are simulated, no real money moves, and no card data is ever accepted.
  • Rich cards. A web front end renders menus, options, bookings, orders and payments as accessible cards, and falls back to plain spoken text.

How we built it

  • Backend: Rust with Axum, Tokio and SQLite (SQLx). The MCP endpoint speaks Streamable HTTP and targets MCP spec 2025-11-25. [Edit: name the MCP library you used, or say custom implementation.]
  • Data safety: Every write runs in a BEGIN IMMEDIATE transaction that re-checks availability, so a stale answer can never cause a double booking. The booking, order, hold and payment flows are idempotent.
  • Ledger: The payment ledger is append-only, and the database rejects updates and deletes on it.
  • Front end: React, Vite, TypeScript, Tailwind and shadcn/ui, with a voice-style chat page using the browser's speech APIs.
  • Assistant layer: The demo uses a deterministic scripted router over the real MCP tools. The project also includes an optional LLM provider switch (Groq and Amazon Bedrock). [Edit: say exactly what you ran. For example, "Bedrock was implemented and tested with a fake client, but not used in the video."]
  • Process: We built it in phases with an AI coding agent and recorded design decisions, a friction log and product feedback along the way.

Challenges we ran into

  • Concurrency. Two callers can see the same free slot. Fixing that meant re-running the availability engine inside the write transaction and testing it with repeated race runs.
  • Holds and expiry. Short-lived holds must free a slot even if a background sweeper never runs, so expiry is evaluated against the clock at read time.
  • Allergen wording. A single "safe" in a voice reply is a real-world risk, so we added tests that scan every reply and card for unsafe wording.
  • Identity. MCP over HTTP has no standard way to know who the user is. We used opaque, hashed profile tokens held server-side, and documented this as a limitation.
  • Dates. Resolving "Friday" correctly against the restaurant's local time took several fixes.

Accomplishments that we're proud of

  • A booking flow tested under heavy concurrency with no double bookings. [Edit: add the real test numbers from your test output.]
  • A human-confirms rule for payments: no tool can pay, approve or refund on demand.
  • Memory with real consent, export and deletion, and a clear privacy document.
  • A design that degrades gracefully: every card also carries the spoken text, so text-only clients still work.

What we learned

  • Voice-first tools need short, natural replies and structured data side by side.
  • Safety-critical details like allergens and payments are better enforced in code and tests than in prompts.
  • MCP could use standard answers for user identity, push notifications to a voice session, and rich response rendering. We included these as feature requests and friction log entries.

What's next for TableTalk

  • Real authentication (OAuth per the MCP authorization spec) in place of bearer profile tokens.
  • A real payment provider behind a hosted checkout, with signed webhooks.
  • A multi-writer database for more than one restaurant location.
  • Table combining for large parties, and push notifications for waitlist offers.
  • Testing with a real Alexa+ environment. We have not verified how Alexa+ renders cards or MCP Apps UI, and the front end here is a simulated experience.

Honest scope: All data is fictional demo data, payments are simulated, and the demo video uses a scripted assistant over the real MCP tools.

Built With

Share this project:

Updates

Submission history