DEV Community

Elena Dev
Elena Dev

Posted on

I put a public MCP server online that books real restaurant tables

Short version: there is now a public MCP server you can point an assistant at to book a real table at a restaurant, and it needs no key. Endpoint at the bottom. Try it and tell me where it breaks.

Why

Earlier this summer we measured 200 Amsterdam restaurants with a browser agent, walking the real booking path on each. Across 163 working websites, exactly zero published a booking interface an assistant could call. The booking button is drawn for human eyes, mounted inside an iframe from another origin, with availability behind a private API and the confirmation rendered as a screen. To software, the booking path does not exist.

So an agent finds the restaurant, understands it, and then stalls at the exact moment the conversation should turn into a reservation. If you build agents that take real-world actions, you have hit this wall in some other domain already.

The server

Four tools, plain JSON over Streamable HTTP, no auth:

  • search - find a bookable business by name or slug, returns ids
  • fetch - full details for one business: services, hours, timezone
  • get_availability - open slots for a date and party size
  • create_booking - create a confirmed reservation, returns a confirmation id

It is deliberately unauthenticated, the same way the REST API is. An assistant acting for a stranger has no key and cannot get one. The guest's own name and phone are the identity that matters, and they are collected at booking time.

Try it

POST https://g-lab.studio/api/mcp
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }
Enter fullscreen mode Exit fullscreen mode

Point any MCP-capable client at that endpoint (Claude, a ChatGPT connector, Codex, or your own agent), ask it to book a table at the demo venue, and it comes back with a confirmation id it can quote. No page to read, no widget to drive, no captcha to lose to.

The design choices, briefly

Keep the surface small. Four tools is enough for a booking: search, availability, create, and later cancel. Every extra tool is another failure mode the model has to reason about.

Return structured errors, not sentences. "Slot no longer available" is a field, not prose. Every string an assistant has to interpret is a place where the same request produces a different outcome.

Version the contract. MCP servers are contracts and contracts change; the version rides in the tool description and every response.

What it is under the hood

The server fronts G-Guest, a booking layer for local businesses (restaurants, salons, studios, clinics) that also runs the normal human booking widget. Same availability, two ways in: a browser for people, a tool for agents. If you run a venue, that side lives at https://g-lab.studio/g-guest . This post is about the server, because the server is the part most of you will actually poke at.

The study that started it: https://g-lab.studio/research/amsterdam-restaurants-2026

If your assistant tries it and something is unclear, ambiguous, or wrong, that is exactly the feedback I want. Reply here.

Top comments (0)