G-Guest · developers

The booking API for AI agents

Most booking pages are drawn for eyes. The availability, the fields and the confirmation sit inside a window software cannot read, so an agent stops at the last step and books somewhere it can finish. G-Guest is the same reservation with a second door: real slots, a confirmed booking, and no human in the middle.

https://g-guest.app/api/mcpstreamable http · json-rpc 2.0 · no auth

Two calls, start to finish

Both of these work right now, against a demo venue, from your terminal. Nothing to sign up for.

1 · what is actually free

curl "https://g-guest.app/api/cal/v1/demo/availability?date=2026-09-12&party=2"

200 OK

{
  "business": "Marea Vivo (Demo)",
  "date": "2026-09-12",
  "timezone": "Europe/Lisbon",
  "service": { "id": 1, "name": "Dinner table", "durationMinutes": 90 },
  "party_size": 2,
  "slots": [
    { "time": "18:00", "start_utc": "2026-09-12T17:00:00.000Z", "available": true, "left": 4 },
    { "time": "18:30", "start_utc": "2026-09-12T17:30:00.000Z", "available": true, "left": 4 }
  ]
}

2 · book one of those slots

curl -X POST https://g-guest.app/api/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
        "name":"create_booking",
        "arguments":{
          "slug":"demo",
          "start":"2026-09-12T17:00:00.000Z",
          "party_size":2,
          "name":"Ana Ferreira",
          "email":"ana@example.com",
          "phone":"+351 912 000 000",
          "language":"nl",
          "idempotency_key":"your-own-unique-string"
        }}}'

the guest is confirmed, the venue already knows

{
  "status": "confirmed",
  "booking_id": "6d45fe35-dc7b-4305-9f88-8b2113ac096a",
  "when": "2026-09-12 18:00",
  "party_size": 2,
  "business": "Marea Vivo (Demo)",
  "manage_url": "https://g-guest.app/booking/6d45fe35…?token=…"
}

The booking is real: it appears in the venue’s panel, the guest gets a confirmation in the language you passed, and the manage link in the reply is what changes or cancels it. Please use the demo venue for testing, not a working restaurant.

Two ways in

If your client speaks MCP

Point it at the endpoint. It is a remote server, so there is nothing to install and nothing to keep updated.

{
  "mcpServers": {
    "g-guest": {
      "type": "streamable-http",
      "url": "https://g-guest.app/api/mcp"
    }
  }
}

If it does not

Every tool has a plain HTTP twin under /api/cal/v1/. A GET reads availability, a POST creates the booking, and a browsing agent with no tools at all can still read the venue page and hand the guest a working link.

GET  /api/cal/v1/{slug}
GET  /api/cal/v1/{slug}/availability?date=&party=
POST /api/cal/v1/{slug}/bookings
GET  /api/cal/v1/bookings/{id}?token=

Eight tools

The whole life of a reservation, plus the door a business uses to ask for one.

searchFind a venue by name or slug. Returns ids for everything below.
fetchOne venue in full: services, hours, timezone, how to book it.
get_businessThe same card when you already know the slug.
check_availabilityReal slots for a date and a party size. Offer only the ones marked available.
create_bookingA confirmed reservation, with the guest's own name, email and phone.
check_bookingOne booking, by its id and manage token. Never returns the guest's contact details.
cancel_bookingCancels an upcoming booking and releases the slot. Idempotent.
request_listingA business that is not on G-Guest yet asks to be. Nothing is published; a person reviews it.

Full schemas come from the server itself: tools/list, or read them in the repository. They are generated from the live endpoint, never hand-written, so the documentation cannot drift away from the product.

What holds

No key, no account, no CAPTCHA

An assistant acting for a stranger cannot obtain credentials, so we ask for none. The guest's own name, email and phone are the identity that matters, and they are collected at booking time.

Retries are safe

Pass an idempotency_key on create_booking and the same key always returns the same booking. A dropped connection costs a duplicate nowhere.

The guest owns their booking

create_booking returns a manage token. It is what check_booking and cancel_booking accept, and it is the only thing that reads or changes that booking. A wrong token is refused without revealing whether the booking exists.

No personal data comes back out

Look up a booking and you get the venue, the time, the party size and the status. Never the guest's name, email or phone, even with a valid token.

Eight guest languages

en · nl · de · fr · es · it · id · bg. Pass one on create_booking and the confirmation, both reminders and the page where the guest changes or cancels all arrive in it.

Rate limits you will not notice

Sixty calls a minute per connection, and a tighter budget on the write paths. Availability is cheap; hammer it if you need to.

Open, and listed

The server description, its tool schemas and the stdio wrapper are public under the MIT licence. Read them, fork them, run the wrapper yourself.

github.com/BlondeDevRules/g-guest-mcp /llms.txt /.well-known/g-guest.json

Published in the official MCP registry as app.g-guest/g-guest and listed on Glama. Every venue page also carries its own availability endpoint in the markup, so an agent that lands on one can act without reading this page first.

If you build websites for local businesses

One line, and their site takes bookings

The widget is a script tag. It takes the colours of the page it sits on, speaks the language of that page, and works cross-origin on any stack: WordPress, Webflow, Squarespace, a static site, something you wrote yourself.

<script src="https://g-guest.app/cal-widget.js"
        data-cal="your-client-slug" defer></script>

Your client keeps the website you built. We do not redesign it, we do not move their domain, and the guest list belongs to the venue and exports in one click. Details and the inline and button variants: the widget guide.

Partner programme

We pay you for every client you bring live

You already look after the sites of restaurants, salons and studios. Adding the booking layer takes you one line and takes them nothing: we set the venue up, build their page, and they get the first month free. When they stay, you get a share of what they pay us, every month, for as long as they stay with us.

Recurring, not one-off. The share is paid every month the client is with us, not once at signup.
The client stays yours. We are the booking layer under the site you built. No redesign, no migration, no marketplace between them and their guests.
Nothing to maintain. Setup, the venue page, the guest emails and the AI side are ours. You paste one line.
Try it on one client first. Pick the venue whose booking is worst today. We put them live for thirty days free, and you see what it does before you offer it to the rest.

Write to us about the partnership

Tell us how many local businesses you look after and where, and we will come back with the share and the terms in one email. A real person answers.

Something missing?

If a tool you need is not there, say so and we will look at it: this set grew from exactly that kind of message. Write to hello@g-lab.studio or open an issue in the repository.

Building the assistant side rather than the venue side? How a guest books through their own assistant.