Gaplessly's booking connector for AI assistants
One endpoint for the whole platform. An assistant connected to it can look up any business that takes bookings through Gaplessly and, where the business's plan includes AI booking, find its free appointment and table times and hand the guest a link to finish the booking themselves.
https://gaplessly.com/api/mcpThe endpoint
A Model Context Protocol server over Streamable HTTP, JSON-RPC 2.0, stateless. No authentication, no API key and no OAuth, because nothing here reaches anything a member of the public cannot already see on a business's own booking page. Call tools/list against it for the authoritative tool definitions; the summary below is prose about the same thing.
There is no CORS and none is planned. An MCP client is a server-to-server HTTP client, so the browser-based Inspector cannot reach this and is not meant to. Use the Inspector CLI.
The six tools
Every one of them is read-only, including the two named start_. That is not a labelling convenience: they return a link and write nothing, and calling one twice produces the same link twice.
find_venuesTakes a business name, a suburb or postcode, or a kind (appointments or hospitality).
Returns up to ten matching venues with their slug, name, address and booking page link. Only real businesses whose plan includes AI booking are searchable, so an empty result means "not found here", not that the business cannot be booked: ask the guest for its booking link and use the slug from it.
get_venueTakes a venue slug (
slug;venueis accepted as the same argument).Returns the venue's public booking profile, its service list, and the venue's own current date and time. Anything the business has not entered, such as an address or phone, is named under
notProvidedrather than guessed. For a restaurant with an online party limit it also returnsgroupEnquiry. Everything else needs the slug, and appointment searches need a service id from here.find_appointment_timesTakes a venue, a service, a day, a span of up to 14 days, and optionally
near,partOfDay,notBefore,notAfterormaxPerDay.Returns free times for that service, each as a display label plus a signed slot token. A day lists up to ten times by default, spread across the day, with
omittedsaying how many more exist; the filters narrow that to "around 6pm" or "afternoons".find_table_timesTakes a venue, a party size, a day, a span of up to 14 days, and the same optional time filters.
Returns free sittings for that party size. An empty day says why it is empty when the venue told us, so "closed on Mondays" never reads as "fully booked". A party above the venue's online limit gets no times: it gets the venue's group enquiry link and any contact details the venue published.
start_appointment_bookingTakes a venue, a slot token and the service it was found for.
Returns a short-lived link to the venue's booking page, opened at that time. It books nothing.
start_table_bookingTakes a venue, a slot token and the party size it was found for.
Returns the same: a link, opened at that sitting. The venue holds the table from the moment the guest opens it, for about ten minutes.
Why nothing here books
- 1
The assistant finds times
find_venues for a name or suburb, get_venue, then find_appointment_times or find_table_times.
- 2
It gets a booking link
start_appointment_booking or start_table_booking returns a link and writes nothing.
- 3
The guest taps and confirms
On the venue's own booking page, which asks for their details.
An assistant cannot prove who it is speaking for. No mainstream assistant passes a verified human identity to a tool, so a connector that booked outright would be booking for whoever the model says, on details the model typed. Nobody in this industry does that: Resy's connector requires a sign-in, Google's AI links you to the booking page for the last step, and Calendly will not book without a code.
So the last step is a link and a tap. The person who taps is demonstrably the person in the conversation; their name, email and phone never pass through the assistant, because no tool accepts them; and a deposit, a house policy or a venue's own intake questions are all asked by the page that already knows how to ask them.
Times, and why they look like that
No tool ever returns a timezone, and no time comes back in a form a date library will parse. A model that sees an IANA zone beside a time converts it, and books hours wrong. Times come back as display text plus an opaque signed token, and every date you send is resolved against the venue's own today rather than yours, which are frequently different days.
A slot token is signed, expires in about thirty minutes, and carries the venue, the time, and what the slot was found for inside the signature. It cannot be edited, built by hand, moved between venues, or reused for a different service or party size. That is what stops a prompt injection redirecting a booking while the transcript still shows the right venue.
What to try first
find_venueswith a name or suburb, or take the slug from the venue's booking link, thenget_venuefor the profile and the venue's current time.find_table_timesfor a party of two, next week. Then the same call on a day the venue is shut, to see the reason rather than an empty list.start_table_bookingwith a token from that result, and open the link it returns.- The same call with a token from a different venue, or with a party size the token was not issued for. Both are refused, and the refusal says what to do instead.
Limits
Every business can be looked up with get_venue, on every plan. Live times and booking links are for businesses whose plan includes AI booking: Growth and Pro for appointments, Venue Growth and Venue Pro for table reservations. Below that, the two time searches and the two start_ tools answer with the venue's bookingPage link and liveTimes: false instead of times or a link at a time.
Searching by name or suburb is narrower than looking up by slug: find_venues lists only real businesses whose plan includes AI booking, and never a demo or test account. Any other business is still reachable with get_venue when the guest has its booking link, so an assistant that finds nothing should ask for the link rather than conclude the business cannot be booked.
The connector is rate limited per calling network address. An assistant platform's address is shared by everyone using it, so the budget is deliberately modest; a normal conversation is three calls.
There is no tool that reads or cancels an existing booking, and there is not going to be one by default. Both would need the private link that manages a booking, which is the one credential this design keeps away from assistants. A guest manages their booking from the link in their own confirmation email.
This server is for guests, and it stays public, read-only and sign-in free. A separate, signed-in server for businesses is planned: it will let a business connect its own assistant or agent to its Gaplessly account, read its bookings and data, and make changes, under permissions the business grants. It will be a different endpoint, so nothing private is ever reachable from this one.