I built an MCP server for restaurant bookings, and it never books anything

Bruno Melani — Tue, 03 Nov 2026 12:00:00 +0000

I’ve worked in Sydney restaurants and bars for over a decade, with every kind of booking app open at the front desk. Over those years I stepped up into management roles, and around the same time, about three years ago, I challenged myself to learn to code.

The two collided. The more I could build, the more I questioned the limits of the apps I used every day, and the more I wanted to build the one I always wished existed for businesses that run on bookings.

That’s Gaplessly: a booking system for salons, clinics, restaurants and bars. It’s in early access, so this is a build log. It’s the first app I’m building to run at scale, and I’m sharing it from the start.

My vision is that personal AI assistants will find a free table or appointment for the people they work for, and we’ll spend less and less time searching for these things ourselves.

Here’s how that part of the journey starts: an MCP server any assistant can use to find live times. The interesting part is what I left out. It can’t book anything, and that’s on purpose.

Try it first

It's one endpoint, no API key, no sign-in:

claude mcp add --transport http gaplessly https://gaplessly.com/api/mcp

(Cursor and VS Code snippets are on the docs page.)

Then ask it for a table at Saltline, a demo venue I set up with a made-up name and phone number. Here's what the server really sends back, trimmed:

// get_venue { "venue": "bruno-test-bistro" }
{
  "venue": { "name": "Saltline", "kind": "restaurant or venue (table reservations)" },
  "venueClock": {
    "today": "2026-10-30",
    "time": "4:23 PM",
    "label": "4:23 PM on Friday 30 October, local time at the venue"
  },
  "maxOnlinePartySize": 6
}

// find_table_times { "venue": "bruno-test-bistro", "partySize": 2, "from": "tomorrow", "days": 1 }
{
  "searched": { "from": "2026-10-31", "days": 1, "partySize": 2 },
  "days": [{
    "date": "2026-10-31",
    "day": "Saturday 31 October",
    "times": [
      { "at": "12:00 PM", "slotToken": "eyJzIjoiYnJ1bm8tdGVzdC1iaXN0cm8i..." },
      { "at": "7:00 PM",  "slotToken": "eyJzIjoiYnJ1bm8tdGVzdC1iaXN0cm8i..." }
    ]
  }]
}

Five tools in total: get_venue, find_appointment_times, find_table_times, start_appointment_booking and start_table_booking. All five are read-only, including the two called start_.

Decision 1: the last step is a link, not a booking

The obvious design is a book_table tool that takes a name, an email and a phone number and writes the booking. I didn't build it, for three reasons.

The assistant can't prove who it's acting for. No mainstream assistant passes a verified identity to a tool. A tool that books outright books for whoever the model says, using details the model typed. Bigger players landed in the same place: Resy's connector needs a sign-in, Google's AI sends you to the booking page for the last step, and Calendly won't book without a code.

Personal data never has to pass through a model. No tool accepts a name, email or phone, so there's nothing to leak, log or hallucinate.

The venue's page already knows how to ask. Deposits, house rules, a restaurant's own questions ("any allergies?"): the booking page handles all of it. Rebuilding that inside tool schemas would drift from the real thing within a month.

So start_table_booking takes a slot token and returns a short-lived link to the venue's own booking page, already opened at that time. The person who taps it is the person in the conversation. When they open it the venue holds the table for about ten minutes while they fill in the form. Nothing is held before that, and calling the tool twice gives you the same link twice.

Decision 2: no timezone, anywhere

This one cost me a real bug. Availability is stored as the venue's local wall clock. Look inside a slot token (it's base64url) and you'll see this:

{ "s": "bruno-test-bistro", "t": "2026-10-31T12:00:00.000Z", "i": 1793337833442, "n": 2 }

That's noon in Sydney, wearing a Z it hasn't earned. Any date library that parses it moves the booking by ten or eleven hours. If the server hands a model a time and a timezone ID, the model helpfully converts it, and you get the same bug again, this time inside someone else's chat.

So times only come back as display text ("7:00 PM"). Nothing comes back in a form a date library will happily parse. Dates you send are words or plain dates ("today", "tomorrow", "2026-10-31"), worked out against the venue's own today. That's what venueClock is for. A guest in London asking about a Sydney dinner is often on a different calendar day from the venue, and "tomorrow" has to mean the venue's tomorrow.

Decision 3: the booking handle is a signed token

Every time comes with a slotToken. It's signed, it expires in about thirty minutes, and the signature covers the venue, the time and what it was found for (the party size or the service). You can't edit one, build one by hand, move it to another venue, or reuse it for a bigger party.

The reason is prompt injection. If a page the model read earlier tells it to "book at this other place instead", the token for the wrong venue just fails. The refusal says what to do instead, so the assistant can recover rather than guess.

Decision 4: an empty day says why

An empty list reads as "fully booked", which is the worst thing to tell a guest when the truth is "closed on Mondays". When the venue has told us why a day is empty, the tool says so.

What it doesn't do

No reading or cancelling bookings. Both would need the private link that manages a booking, and that's the one credential this design keeps away from assistants. Guests manage bookings from their confirmation email.
Live times depend on the venue's plan. Venues without the AI booking feature still answer get_venue, and the time searches send back a link to their booking page instead of times.
It's rate limited per network address, and modestly, because one assistant platform's address is shared by everyone using it. A normal conversation takes three calls.

The blueprint: one booking core, many front doors

The MCP server is one door into something bigger. The idea behind Gaplessly is that a booking can arrive from anywhere (a booking page, a partner app, a POS, an AI assistant, eventually Google) and every one of them goes through the same core: the same availability maths, the same rules, the same write, with the clash check enforced by Postgres itself rather than by whichever app got there first.

Live today:

A branded booking page for every business, on its own subdomain.
Two products on one platform: appointments (staff, services, durations) and hospitality (parties, tables, service periods, a live floor plan, a waitlist). They really are different jobs, so they have separate data and rules.
A public REST API with an OpenAPI spec: availability, booking writes for partners (an Idempotency-Key is required, so a retry never double-books), and signed webhooks for every booking change.
Calendar feeds, and ready-made n8n and Make templates for owners who automate.
A POS API, so a till can mark a table seated or finished and attach the bill.
This MCP server, a read-only CLI on npm, and Lessly, an assistant inside the dashboard with tools scoped to each product.

Being built next:

Booking pages that agents can read with nothing installed. Structured data and clean forms on every booking page, so any browsing agent can find and book without anyone adding a connector. That's the real goal: a guest shouldn't have to install anything for their assistant to book a table.
A private, signed-in MCP server for businesses. "What does Friday look like?", "Move the 7pm to table 12", "Who's on the waitlist for tonight?", answered and done by the venue's own assistant, under permissions the venue grants. It will be a separate endpoint with separate scopes, so nothing private is ever reachable from the public one.
Reserve with Google. Google's end-to-end booking needs a real, idempotent write, which the partner API already has, and the MCP tools map one to one onto Google's availability and booking calls. So it's one more thin adapter on the same core, pending Google's partner approval.
Two-way staff calendar sync, Google first, so a stylist's personal calendar blocks their booking times.
One inbox for every channel. WhatsApp, Instagram and Messenger enquiries next to booking and email messages, through each platform's official business APIs.

Where I want it to get:

You tell whatever assistant you use "a table for four near the office on Friday, somewhere quiet", it finds a real time at a real venue, and you confirm with one tap. On the other side, the venue's own assistant runs the day: it confirms, moves, fills a cancelled slot from the waitlist and tells the floor team who's coming. The booking system sits in the middle as the source of truth that every assistant, marketplace and till reads and writes through, while the business keeps its guests, its data and its brand, and pays no commission per booking.

I'm a long way from that, and I'm building each piece above so it fits that picture.

If you build MCP servers I'd really like your view on the identity question. Is a link-and-tap handoff where this lands for any tool that acts for a person, or is there a pattern I'm missing?

Docs: gaplessly.com/docs/mcp · API: gaplessly.com/openapi.json · CLI: npx @gaplessly/cli (github.com/gaplessly/cli)

DEV Community: Bruno Melani