MCP Server for Restaurant Reservations: How the Connector Works

If you build with AI assistants, one question tends to arrive the first time an agent fails to book dinner: could a tool let it do the job? A restaurant reservation MCP server is that tool. This is a builder’s look at what such a connector actually is, the operations it hands an assistant, and the design choices that keep it honest. It pairs with our consumer walkthrough of booking hard tables with an AI assistant, which covers the user-facing side. Current as of August 2026.

Why a reservation MCP server has to exist

The Model Context Protocol is the open standard for giving an assistant callable tools. Nothing about MCP is restaurant-specific; the reason a reservation server exists at all is a gap on the platform side. Resy, SevenRooms, and OpenTable are built for people tapping through apps and websites, and none of the three publishes an official agent connector. There is no sanctioned endpoint an assistant can hit to hold or claim a table. So an agent that wants to book is left with two poor options: script a headless browser through a human booking flow (slow, brittle, and usually blocked), or give up. A reservation MCP server closes that gap. It sits between the assistant and the booking, exposing clean tool calls the agent can reason about while a purpose-built service does the real work against the platforms.

What the connector exposes to an assistant

Described at the capability level, a reservation connector gives an assistant a small set of intent operations, not a one-shot booking button. The core one is setting up a watch: you tell the agent the restaurant, the dates or a date range, the party size, and any constraints (a time window, weekends only, a minimum table), and the agent registers that as a standing watch. From there it can list your active watches, and adjust or stand one down as plans change. That is the whole surface an assistant needs, and it is deliberately small. SeatSwiper publishes the connector but not a public tool schema, so treat the exact function names and arguments as an implementation detail your client discovers at connect time, not something to hard-code against.

One capability is worth calling out, because it is a safety choice as much as a feature: a booking action requires an explicit confirmation before anything is reserved. The agent can arm and manage watches on its own, but the moment of committing to a table stays gated.

The design principle: agent owns intent, watcher owns execution

The cleanest way to think about the split is a separation of concerns. The agent is excellent at the fuzzy front half: turning “somewhere good for four, Italian-ish, a Friday in the next month, not too late” into one concrete watch. It is bad at the back half. Winning a hard table is a long, boring, real-time job: watching a platform for days, then reacting inside the few seconds a cancellation is visible before someone else takes it. Language models do not sit in a loop for a week, and they lose a seconds-long race to a dedicated watcher every time. So the connector hands execution to a service that never sleeps and never gets distracted, running the set-once watch lifecycle in the background. The agent owns intent; the watcher owns the race. Get the boundary wrong, ask an agent to babysit a booking, and you get the worst of both: an expensive model idling and a table lost the instant it appears. If you want that higher-level agent workflow without the plumbing, see booking any restaurant with an AI agent.

Connecting it to Claude or ChatGPT

SeatSwiper ships as a remote MCP connector, so there is nothing to self-host. It is a Streamable HTTP server at a single endpoint. In an MCP client that takes a config file, the entry is minimal:

{
  "mcpServers": {
    "seatswiper": {
      "url": "https://www.seatswiper.com/api/mcp"
    }
  }
}

Use the www host exactly as written. The apex domain’s redirect does not always replay the connector POST, and some clients quietly discard it. Assistants with a connector directory can also find it by its registry name, com.seatswiper/booking, which is listed in the official MCP registry. First use kicks off a guided OAuth 2.1 sign-in (dynamic client registration and PKCE), which is how the connector gets permission to act for you without you pasting a raw token into the chat. After that, the agent can arm and manage watches in plain language.

The own-account model, as a design constraint

For a builder, the safety story is not a marketing line; it is a constraint that shapes the whole thing. SeatSwiper books on your own Resy, SevenRooms, or OpenTable account, in your own name, one reservation at a time. Nothing is booked into a stranger’s identity, resold, or transferred. That rules out the entire gray market of reservation broking by construction, and it is the honest answer to whether letting an agent book is safe: the action the connector performs is the same action you would take by hand, so the result is indistinguishable from a booking you made yourself. It is worth being precise about the tradeoffs, too. The connector needs a connection to your reservation account so it can book as you (a token handoff on Resy, the email-code login OpenTable already uses), it never stores your password, and it can still lose a race, because no watcher can conjure a table that never opens. We go deeper on that risk model in is it safe to let AI book restaurants. On the law: the 2025 to 2026 reservation statutes, New York’s included, target resale and bulk broking, not booking a table for your own dinner, which is the lane this design stays inside.