We built an MCP server so any assistant can book a table

For a month I have been writing about a gap, so I want to write about the piece that closes it.

We measured 200 Amsterdam restaurants on one question. Can an AI assistant complete a reservation? Sixteen out of two hundred could be taken to the final booking step by a browser agent. Zero out of 163 working sites published an interface an assistant could call directly. The gap was not skill and it was not model quality. There was nothing to act on.

So we built one.

The piece is an MCP server. Model Context Protocol is a protocol Anthropic published in late 2024 for exposing tools that an assistant can call. The major agent platforms all consume it in some form now. If you build an assistant that has to take an action in the real world, MCP is the most reliable way today to give it a door.

We wrote a small MCP server that fronts a booking system. Three tools: search a business, check availability for a date and party size, create a booking. The transport is plain JSON. Any assistant with an MCP client can list the tools, see their inputs and outputs, and use them without ever seeing a page. There is no widget to drive, no iframe to introspect, no captcha to defeat. The assistant asks for a table, and if a table exists it books it and gets back a confirmation ID it can quote to the guest.

Watching an assistant use it the first time is anticlimactic in the best way. There is no reasoning about how the site is laid out, no clicking around, no error at step four. The assistant reads the tools available, calls them, gets the result. It is what booking a table looks like when the last step is designed for software.

Building this made one earlier moment click into place.

Earlier in the summer I put a small booking API on our demo instance behind a plain HTML page. The endpoint, the required fields, the response shape. Not a widget, just a page. I asked ChatGPT to make a booking against it. ChatGPT read the page carefully. It understood the API. It listed the required fields. Then it apologised: its web tool cannot issue a POST request. It could describe the action perfectly and it could not perform it.

Every venue in our study was that scene, two hundred times over. The information for a person is on the page. The interface for software is not. The assistant sits between them and cannot bridge either.

The fix is not to teach the assistant to be a person. The fix is to give the assistant something to call. That is what MCP is.

A few practical notes for anyone building similar tools.

Keep it small. Three tools is enough for a booking. Search, availability, create. Later we may add cancel and modify. We resisted adding tools for things the assistant does not need, because every extra tool is another failure mode the model has to reason about, and every extra description is another paragraph the model has to hold in its head.

Return structured errors. "Slot no longer available" is a data field, not a natural language sentence. Every string an assistant has to interpret is another point where the same request can produce a different outcome.

Version the interface. MCP servers are contracts and contracts change. Include a version in the tool description and in every response.

Publish the URL somewhere machines can find it. A .well-known entry, a ReserveAction block on the venue's site pointing at the MCP endpoint, or a public discovery registry as those emerge. Existing is not enough. Being findable is.

Assume the venue does not want assistants competing with its own website. That is a fair position. Do not build a system that only agents can use. Guests should still be able to book on the site the way they always did. The MCP server is the second door, and its presence should be invisible to the human who walks through the front.

There is a live demo. Point your assistant at it, ask for a table, and it should just work. The MCP endpoint is listed on the demo page.

The booking layer for restaurants: https://g-lab.studio/g-guest
The Amsterdam study: https://g-lab.studio/research/amsterdam-restaurants-2026

If you build assistants that have to complete real-world actions, I would like to hear where the tools you gave them still fall short. That is where the next essay ends up.

Comments

[Mads Hansen]

The subtle failure boundary is between check_availability and create_booking: availability is an observation, not a reservation. create_booking needs to be the authoritative atomic claim on inventory, with a client-supplied idempotency key and typed outcomes such as confirmed, already_confirmed, slot_no_longer_available, and needs_requote.

Otherwise a timeout after a successful write can turn an innocent retry into a duplicate booking. I’d test two agents racing for the last table, a lost success response followed by retry, and cancellation versus confirmation crossing in flight. A confirmation ID is most useful when it is also a receipt for an explicit state transition.